我从一位同事那里得到了一个设计的回击，我想知道在这种情况下谁是正确的 SRP 应用是否存在共识。
我认为 SRP 主要与较低级别的设计细节有关，例如类责任。随着抽象级别的提高，我相信 SRP 仍然是相关的，但单一职责的定义也必然会向更高级别的抽象移动。
在我的具体情况下，在我看来“处理 foo、存储其结果并提供对这些结果的访问”的服务具有“foo 处理子系统”的单一责任，但是同事不同意并将其视为 2-3责任。我的情况是，如果您总是将单一职责分解为微小的细节，那么拥有“银行”就违反了 SRP，因为它“持有资金、维护账户、出售抵押贷款……”。
就像软件设计的许多原则一样，这在我看来是非常主观的，但经常争论得好像不是这样。“单一职责”定义不明确，取决于您认为的职责。有时候，一段代码显然做得太多了，有一个钩子可以挂起这个问题是有帮助的，但是假装它总是一个简单的评估是愚蠢的。
我认为你可能是对的，但不能用这个原则来解决你的争议。罗伯特马丁将责任定义为“改变的理由”。如果 foo 的结构发生变化（例如，添加了一个字段），您可能希望这些变化反映在此类中。在你同事的方法中，所有的课程都必须改变。这是必须在应用层的上下文中应用该原则的地方，因为它也会更改显示代码，这显然不应该在同一个类中。如果存储机制发生变化（例如，使用不同的数据库驱动程序），我希望这将通过持久性配置在外部进行处理，因此只需将其他原因保留在您的类之外，每个人都会很高兴。
我不同意你同事的观点。
单一职责的粒度应该与您建模的级别相匹配。随着抽象级别的提高，职责的粒度也应该向更高的抽象级别移动。
至于银行的例子，它的唯一职责就是提供金融服务。
这个概念就像一个工作分解结构。当您下降并“看到”一系列部门时，他们将有自己的单一职责。因此，责任也可以分解。重要的是分解是对齐的。
在这种情况下，我同意你的同事的看法。存储和处理应该分开，因为两者都有不同的“改变理由”。
至于您给出的银行示例，我认为银行不出售抵押贷款。贷款部门（或其他部门）出售抵押贷款，银行设有贷款部门。将“银行”视为一个单一的对象，就相当于一个人经营着整个银行。