2009-12-09 50 views
1

我正在推迟一位同事的设计,并且想知道在这种情况下谁的SRP应用是正确的。单一责任原则(SRP)在何种抽象层次上不再有意义?

我看到SRP主要与较低层次的设计细节有关,例如阶级责任。随着抽象层次的提升,我认为SRP仍然是相关的,但是单一责任的定义必然也会向更高的抽象层次发展。

在我的具体情况中,“处理foos,存储结果并提供对这些结果的访问权限”的服务具有“foo处理子系统”的单一责任,但是一位同事不同意并将其视为2-3个独立的职责。我的情况是,如果你总是将单一责任分解为细节,那么拥有“银行”是SRP的违规行为,因为它“持有资金,维护账户,出售抵押贷款......”。

+0

看到这个问题,它的答案是:http://stackoverflow.com/questions/2455705/how-do-you-determine-how-coarse-or-fine-grained-a-responsibility-should-be-when – User 2011-07-23 00:18:55

回答

2

像许多软件设计原理一样,这在我看来似乎是非常主观的,但经常争辩说它好像不是。 “单一责任”定义不明确,取决于您认为的责任。有时候,一段代码显然做得太多了,而且有一个钩子来挂起这个问题是有帮助的,但是假装它总是一个剪切干的评估是愚蠢的。

1

我认为你可能是对的,但不能用这个原则来解决你的争议。罗伯特马丁把责任定义为“改变的理由”。如果foo的结构发生变化(例如,添加了一个字段),您希望更改反映在该类中。在你的同事的方法中,所有的课程都必须改变。这是原则必须在应用层的上下文中应用的原因,因为它也会改变显示代码,显然它们不应该在同一个类中。如果存储机制发生变化(例如,使用不同的数据库驱动程序),我希望通过持久性配置对其进行外部处理,所以只需保留其他原因以便改变课程外,所有人都可以很开心。

+0

在这种情况下,不存在涉及表示层(不在此子系统之外),但它确实结合了来自处理的数据处理和元数​​据存储。我的观点是,我认为这是关于上下文/参考框架的。在这个子系统内的较低层次当然应用了SRP,但是SRP似乎倾向于荒谬的是当这些组件在整个系统的上层到达之前从未被连成一个更高层次的内聚单元。 – archie 2009-12-09 19:43:07

+0

我不确定这是一个很好的比喻,但在大脑中,我发现个体脑细胞有单一的责任,并且相邻的细胞群被组合成更高层次的单位,而这些单位具有其他单一但更高层次的责任,并且这个低层次的单位会一直持续到你有一个完整的大脑。我现在感觉的SRP-absordium会有一个扁平的大脑结构,它将数十亿个细胞连接在一块意大利面条上。也许这就是SRP变得太过分了......意大利面条业务逻辑......? – archie 2009-12-09 19:43:46

0

我会同意你的同事在这种情况下。存储和处理应该分开,因为两者有不同的“改变原因”。

至于你给的银行例子,我会争辩说银行不卖卖出抵押贷款。贷款部门(或其他)出售抵押贷款,银行有一个贷款部门。将“银行”视为一个单一对象相当于一个人经营整个银行。

0

我不同意你的同事。

单个责任的粒度应该与您正在建模的级别相匹配。随着抽象层次的提升,责任的粒度也应该向更高的抽象层次发展。

至于银行的例子,其单一职责将提供金融服务。

这个概念就像一个工作分解结构。当你下降并“看”一系列部门时,他们将有自己的单一责任。因此,责任也可以分解。重要的是,细分是一致的。