广泛的对象组合

我有一个Django模型，有很多方法（并且将来会继续有更多），因为它是应用程序的核心。这是一个自定义用户模型，与旧数据库进行交互。有一些方法可以检查用户对不同区域的访问权限，以及不同类型的成本等。广泛的对象组合

由于存在相互关联的方法组，因此将它们拆分为不同的类并使用对象组合。然而，我的问题是如何让最终开发者看起来如此。他们是否应该使用对象链，例如user.access.has_normal_access()，或者User对象上的方法是否应该简单地传递给底层对象？

对象链接似乎不鼓励在Python中，但创建传递方法的替代方法似乎与目的不一致，即减少主类中方法的数量。

想法？

来源

2011-04-24 exupero

如果您想要将同一基础数据库模型上的方法拆分为不同的相关方法集，则可能应使用proxy models。

将使用相同的底层数据库，但将是不同的不同的类。

虽然我在谈论User类，但我不确定这是否是最佳解决方案。您没有给出足够的详细信息让我肯定地说，但您肯定可以使用builtin permissions来实现您的目标？

来源

2011-04-24 17:46:15

代理模式是有价值的，但也有很多的所有用户都需要有方法，如检查权限知道某些导航元素是否应该出现在页面上。此外，我们没有使用Django'User'模型，而是编写了一个与旧数据库表接口的模型。 – exupero 2011-04-24 21:09:49

我假设非django，使用装饰器的纯python解决方案对你来说可以。

请考虑下面的代码

def check1(): print "check1" 
def check2(): print "check2" 

def dev_api(f): 
    def fd(*args, **kw): 
     check1() 
     check2() 
     f(*args, **kw) 
     # optionally, perform some post check 
     print "post check" 
    return fd 

@dev_api 
def business(a, b, *args, **kw): 
    print 'business', a, b, args, kw 

business(1, 2, 'a', 'b', 'c', x='x', y='y')

CHECK1，CHECK2你persmission，不同的成本函数等
dev_api是你的 “检查” 功能分组功能
业务是业务逻辑函数，其执行需要受到“检查”功能的限制

现在，你可以公开如上所述装饰的业务逻辑函数，或暴露装饰器本身以供最终开发者使用。

还有一点要学习装饰（即装饰参数）。请随时申请更多示例，如果需要的话。

以上代码的输出

 
check1 
check2 
business 1 2 ('a', 'b', 'c') {'y': 'y', 'x': 'x'} 
post check

来源

2011-04-24 18:26:49 wrobell

装饰器可以用于视图功能，但模板和其他区域也需要相同的检查。尽管你可能会用装饰器来装饰东西：是否有类装饰器解决方案来探索？ – exupero 2011-04-24 21:13:34

不幸的是，我不熟悉Django足以说，如果装饰器是使用Django的每个方面的解决方案，但是imho函数/方法和类装饰器可能值得探索。 – wrobell 2011-04-25 11:54:52

广泛的对象组合

回答

相关问题