在什么抽象级别上，单一职责原则 (SRP) 不再有意义？
我收到了一位同事对设计的反对，我想知道在这种情况下谁对 SRP 的应用是正确的，是否存在共识。
我认为 SRP 主要与较低级别的设计细节相关，例如类责任。当您在抽象级别上提升时，我相信 SRP 仍然相关，但单一职责的定义也必然会向更高的抽象级别迈进。
在我的具体情况下，在我看来，“处理 foo、存储其结果并提供对这些结果的访问”的服务具有“foo 处理子系统”的单一职责，但是一位同事不同意，并将其视为 2-3 个独立的部分责任。我的情况是，如果你总是将单一职责分解为微小的细节，那么拥有一家“银行”就违反了SRP，因为它“持有资金、维护账户、出售抵押贷款……”。
I'm getting push back on a design from a colleague, and am wondering if there's consensus as to who is correct on application of SRP in this case.
I see SRP as relating mostly to the lower-level details of design, such as class responsibility. As you move up in levels of abstraction I believe SRP is still relevant but that the definition of what a single responsibility necessarily also moves toward a higher level of abstraction.
In my specific case, a service that "processes foos, stores their results, and provides access to those results" in my mind has the single responsibility of a "foo handling subsystem", however a colleague disagrees and sees this as 2-3 separate responsibilities. My case is that if you always break down single responsibilities to minute detail then having a "bank" is a violation of SRP since it "holds money, maintains accounts, sells mortgages, ...".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
与软件设计的许多原则一样，在我看来，这是非常主观的，但人们经常争论，好像事实并非如此。 “单一责任”的定义不明确，取决于您认为责任是什么。有时，一段代码显然做了太多的事情，有一个钩子来挂起这个问题是有帮助的，但假装它总是一个固定的评估是愚蠢的。
Like many principles of software design, this seems to me to be enormously subjective, but often argued about as if it were not. "Single Responsibility" is poorly defined, and depends on what you consider a responsibility. There are times when a single piece of code clearly is doing too much, and it's helpful to have a hook on which to hang that concern, but to pretend that it's always a cut-and-dried assessment is silly.
我认为你可能是对的，但不能用这个原则来解决你的争议。罗伯特·马丁将责任定义为“改变的理由”。如果 foo 的结构发生变化（例如，添加了一个字段），您可能希望这些变化反映在此类中。按照您同事的方法，所有类都必须更改。这是必须在应用程序层的上下文中应用该原则的地方，因为它也会更改显示代码，这显然不应该在同一个类中。如果存储机制发生变化（例如，使用不同的数据库驱动程序），我希望这可以通过持久性配置在外部处理，因此只需将其他更改原因保留在类之外，每个人都会感到高兴。
I think you are probably right, but can't use this principle to solve your dispute. Robert Martin defines responsibility as "reason to change". If the structure of foo changes (e.g., a field is added) you would want the changes to be reflected in this class. In your colleague's approach, all of the classes would have to change. This is where the principle must be applied within the context of an application layer, because it would change display code as well, which obviously shouldn't be in the same class. If the storage mechanism changes (e.g., using a different database driver) I would expect this to be handled externally, via persistence configuration, so just keep other reasons to change out of your class, and everyone can be happy.
在这种情况下，我同意你同事的观点。存储和处理应该分开，因为两者都有不同的“改变原因”。
至于您给出的银行示例，我认为银行不出售抵押贷款。贷款部门（或其他部门）出售抵押贷款，银行也有贷款部门。将“银行”视为单个对象相当于一个人经营整个银行。
I would agree with your colleague in this case. Storage and processing should be separated because both have different "reasons to change."
As for the bank example you gave, I would argue that a bank doesn't sell mortgages. The loans department (or whatever) sells mortgages, and the bank has a loans department. Treating "the bank" as a single object is the equivalent of one person running an entire bank.
我不同意你同事的观点。
单一职责的粒度应该与您建模的级别相匹配。随着抽象级别的上升，职责的粒度也应该向更高的抽象级别发展。
以银行为例，其唯一职责是提供金融服务。
这个概念就像工作分解结构一样。当您下降并“看到”一系列部门时，他们将承担自己的单一责任。这样，责任也可以被分解。重要的是细分是一致的。
I disagree with your colleague.
The granularity of the single responsibility should match the level in which you are modeling. As you move up in levels of abstraction the granularity of responsibilities also should move toward a higher level of abstraction.
As for the bank example, its single responsibility would be delivering financial service.
This concept works like a work breakdown structure. As you descend and "see" a collection of departments, they will have their own single responsibility. Thus, the responsibility can also break down. Important thing is that the breakdown is aligned.