软件开发中很少有规则（如果有的话）是无一例外的。有些人认为goto没有位置，但他们错了。
就 OOP 而言，面向对象并没有单一的定义，因此取决于你问谁，你会得到一套不同的硬性和软性原则、模式和实践。
OOP 的经典思想是消息被发送到原本不透明的对象，对象根据自己的内部知识解释消息，然后执行某种功能。
SRP 是一种软件工程原理，可以应用于类、函数或模块的角色。它有助于某种事物的凝聚力，因此它可以很好地组合在一起，而不会出现无关的部分，或者具有使事物交织和复杂化的多个角色。
即使只有一个职责，范围仍然可以从单个功能到一组松散相关的功能，这些功能是共同主题的一部分。只要你避免陪审团操纵一个元素来承担它主要不是为它设计的东西的责任，或者做一些其他临时的事情来淡化对象的简单性，那么就违反了你想要的任何原则。
但我发现更容易让 SRP 正确，然后做一些更复杂的事情，同样强大。
这些规则都不是法律。它们是更多的指导方针和最佳实践。有时遵循“规则”是没有意义的，你需要做最适合你情况的事情。
不要害怕做你认为正确的事。实际上，您可能会想出更新更好的规则。
引用巴博萨船长的话：
“..其次，您必须是盗版者才能应用盗版代码，而您不是。第三，代码更像是您所谓的“指南”而不是实际规则......”
引用 Jack Sparrow & Gibbs 的话。“我以为你应该遵守代码。” 吉布斯先生：“我们认为它们是更实际的指导方针。”
很明显，海盗非常了解这一点。
“规则”可以通过模式运动理解为“力量”
所以有一种力量试图让这个类有一个单一的责任。（凝聚）
但也有一股力量试图降低与其他类的耦合。
与所有设计（不仅仅是代码）一样，答案是视情况而定。
啊，我想这与我给出的答案有关。:)
与大多数规则和法律一样，这些规则存在相关的潜在动机 - 如果潜在动机不存在或不适用于您的案例，那么您可以根据自己的需要自由地改变/破坏规则。
话虽如此，SRP 本身并不是 OOP 的规则，但被认为是创建易于扩展和单元测试的 OOP 应用程序的最佳实践。
两者都是我认为在企业应用程序开发中最重要的特征，其中维护现有应用程序比新开发占用更多时间。
正如许多其他海报所说，所有规则都是为了打破。
话虽如此，我确实认为 SRP 是编写好代码的更重要的规则之一。它不是特定于面向对象编程的，但是如果类没有单一的职责，那么 OOP 的“封装”部分就很难做好。
毕竟，如何正确简单地封装一个具有多种职责的类？通常答案是多个接口和多种语言可以提供相当多的帮助，但是对于你的类的用户来说，它可能会在不同的情况下以完全不同的方式应用，这仍然让你感到困惑。
SRP 只是 ISP 的另一种表达方式 :-) 。
而“P”的意思是“原则”，而不是“规则”：D