单一职责原则是 OOP 的规则吗？[关闭]

Question

一个 回答 Stack Overflow 的一个问题指出，某个特定框架违反了简单明了的 OOP 规则：单一职责原则（SRP）。

是单一职责原则 真的 OOP 的规则？

我对面向对象编程定义的理解是“对象及其行为用于创建软件的范例”。这包括以下技术：封装、多态性和继承。

现在不要误会我的意思 - 我相信 SRP 是大多数优秀 OO 设计的关键，但我觉得在某些情况下可以而且应该打破这个原则（就像数据库规范化规则一样）。我积极宣传 SRP 的好处，并且我的大部分代码都遵循这一原则。

但是，这是一条规则吗？因此意味着它不应该被打破吗？

Answer 1

软件开发中很少有规则（如果有的话）是无例外的。有些人认为没有地方 去 但他们错了。

就 OOP 而言，面向对象没有单一的定义，因此根据您询问的对象，您将得到一组不同的硬性和软性原则、模式和实践。

OOP 的经典思想是，消息被发送到其他不透明的对象，对象根据其自身内部的知识来解释消息，然后执行某种功能。

SRP 是一种软件工程原理，可以应用于类、函数或模块的角色。它有助于事物的凝聚力，使其能够很好地组合在一起，而不会悬挂不相关的部分或具有使事物相互交织和复杂化的多个角色。

即使只有一个职责，其范围仍然可以从单个功能到一组松散相关的功能，这些功能是共同主题的一部分。只要你避免临时操纵一个元素来承担其最初设计目的之外的某些责任，或者做一些其他临时的事情来淡化对象的简单性，那么就违反了你想要的任何原则。

但我发现正确的 SRP 比做一些同样稳健的更复杂的事情更容易。

Answer 2

这些规则都不是法律。它们是更多的指导方针和最佳实践。有时遵守“规则”是没有意义的，您需要做最适合您情况的事情。

不要害怕做你认为正确的事情。您实际上可能会想出更新更好的规则。

Answer 3

引用巴博萨船长的话：

“..其次，你必须是海盗才能适用海盗代码，但你不是。第三，代码更像是你所说的“指南”而不是实际规则……”

引用杰克·斯派洛和吉布斯的话。“我认为您应该保留代码。”先生。吉布斯：“我们认为它们是更实际的指导方针。”

显然，海盗们非常了解这一点。

“规则”可以通过模式运动理解为“力量”

所以有一股力量试图让类拥有单一的责任。（凝聚）

但也有一股力量试图降低与其他类的耦合。

与所有设计（不仅仅是代码）一样，答案是视情况而定。

Answer 4

啊，我想这与我给出的答案有关。:)

与大多数规则和法律一样，这些规则都有相关的潜在动机——如果潜在动机不存在或不适用于您的情况，那么您可以根据自己的需要自由地改变/破坏规则。

话虽如此，SRP 本身并不是 OOP 的规则，但被认为是创建易于扩展和可单元测试的 OOP 应用程序的最佳实践。

我认为这两个特征在企业应用程序开发中最为重要，在企业应用程序开发中，现有应用程序的维护比新开发占用更多的时间。

Answer 5

正如许多其他发帖者所说，所有规则都是为了被打破的。
话虽如此，我确实认为 SRP 是编写优秀代码的更重要规则之一。它不是面向对象编程所特有的，但如果类没有单一职责，OOP 的“封装”部分就很难做好。

毕竟，如何正确、简单地封装一个具有多种职责的类呢？通常答案是多个接口和多种语言，这可以提供很大帮助，但它仍然让类的用户感到困惑，因为它在不同情况下可能以完全不同的方式应用。

Answer 6

SRP 只是 ISP 的另一种表达方式:-)。

“P”的意思是“原则”，而不是“规则”：D