确保每个班级只有一个责任，为什么？

根据Microsoft文档，有关Wikipedia SOLID原则的文章或大多数IT架构师，我们必须确保每个班级仅负一个责任。我想知道为什么，因为如果每个人似乎都同意这条规则，那么似乎没人会同意这条规则的原因。

一些人引用了更好的维护，有人说它提供了简单的测试，或者使类更加健壮或安全。什么是正确的，实际上是什么意思？为什么它可以使维护更好，测试更容易或代码更健壮？

模块化。任何体面的语言都会为您提供将代码段粘合在一起的方法，但是没有程序员在源头上不做手术的一般方法，就无法解开大段代码。通过将许多任务卡在一个代码结构中，您会失去自己和其他人机会，以其他方式组合其各个部分，并引入不必要的依赖关系，这些不必要的依赖关系可能导致对一个部分的更改影响其他部分。

SRP适用于函数，也适用于类，但是主流的OOP语言在将函数粘合在一起方面相对较差。

更好的维护，轻松的测试，更快的错误修复是（非常愉快）应用SRP的结果。主要原因（如Robert C. Matin所说）是：

一堂课应该只有一个改变的理由。

换句话说，SRP提出了变更地点。

SRP还促进DRY代码。只要我们的班级只负责一项工作，我们就可以选择在需要的任何地方使用它们。如果我们的班级有两个职责，但我们只需要其中一个职责，而第二个职责就是干预，那么我们有两个选择：

1. 将班级复制粘贴到另一个班级，甚至可能创建另一个多责任突变体（稍微增加技术债务）。
2. 首先对类进行划分并按原样进行设置，由于原始类的广泛使用可能会非常昂贵。

创建代码来解决特定问题很容易。创建更正该问题的代码，同时允许以后进行安全更改的代码更加复杂。SOLID提供了一组使代码更好的实践。

关于哪一个是正确的：全部三个。这些都是使用单一职责的好处，也是您应该使用它的原因。

关于它们的含义：

• 更好的维护意味着更容易更改，而且不会经常更改。因为代码更少，并且该代码专注于特定的内容，所以如果您需要更改与该类无关的内容，则无需更改该类。此外，当您需要更改类时，只要不需要更改公共接口，就只需要担心该类，而无需担心。
• 简单的测试意味着更少的测试，更少的设置。类别上没有那么多活动部件，因此类别上可能发生的故障数量更少，因此需要测试的案例更少。将会设置更少的私人领域/成员。
• 由于上述两个原因，您获得了一个变化少，失败少的类，因此更加健壮。

请尝试遵循该原理一段时间来创建代码，然后稍后重新访问该代码以进行一些更改。您将看到它提供的巨大优势。

您对每个班级都做同样的事情，最后得到更多班级，所有班级都符合SRP。从连接的角度来看，它使结构更加复杂，但是每个类的简单性证明了这一点。

我认为，以下论点支持“单一责任原则”是一种良好做法的主张。我还提供了指向更多文献的链接，在这些文献中您可以阅读甚至更详细的论据-并且比我的论断更雄辩：

• 更好的维护：理想情况下，每当必须更改系统功能时，都将只有一个类需要更改。类和职责之间的明确映射意味着项目中涉及的任何开发人员都可以识别出这是哪个类。（如@MaciejChałapuk所指出的，请参见Robert C. Martin，“清洁代码”。）

• 更简单的测试：理想情况下，类应具有尽可能少的公共接口，并且测试应仅针对该公共接口。如果由于类的许多部分是私有的而无法进行清晰的测试，则这明确表明您的类承担了太多的责任，因此您应该将其拆分为较小的子类。请注意，这也适用于没有“公共”或“私人”班级成员的语言；具有小的公共接口意味着对于客户端代码而言，很清楚应该使用该类的哪一部分。（有关更多详细信息，请参见Kent Beck，“测试驱动开发”。）

• 健壮的代码：您的代码不会因为编写得当而经常失败。但是，作为所有代码，其最终目标不是与机器通信，而是与其他开发人员通信（请参见Kent Beck，“实现模式”，第1章。）清晰的代码库更易于推论，因此将引入更少的错误。 ，在发现错误和修复错误之间将花费更少的时间。

原因有很多，但是我喜欢的一个原因是许多早期UNIX程序使用的方法：做好一件事。一件事情很难做到，而尝试做更多的事情就变得越来越困难。

另一个原因是限制和控制副作用。我喜欢组合式咖啡壶开门器。不幸的是，当我有访客时，咖啡通常会溢出。前几天煮咖啡后，我忘了关门，有人偷了。

从心理角度来看，您一次只能跟踪几件事。一般估计是七个正负两个。如果一个班级做了很多事情，您需要一次跟踪所有这些。这会降低您跟踪自己正在做的事情的能力。如果一个班级要做三件事，而您只想要其中的三件事，那么您可能会在实际对班级做任何事情之前就用尽能力来跟踪事情。

进行多项操作会增加代码的复杂性。除了最简单的代码，复杂性的增加还增加了发生错误的可能性。从这个角度出发，您希望类尽可能简单。

测试一个做一件事的类要简单得多。您不必验证每次测试该类所做的第二件事是否发生。您也不必修复损坏的条件并在其中一项测试失败时重新测试。

因为软件是有机的。需求不断变化，因此您必须尽可能少地操作组件。通过不遵循SOLID原则，您可能最终得到了具体设置的代码库。

想象一栋带有承重混凝土墙的房屋。如果您在没有任何支持的情况下拆除隔离墙，会发生什么？房子可能会倒塌。在软件中，我们不需要这样做，因此我们以一种方式来构造应用程序，以便您可以轻松移动/替换/修改组件而不会造成很多损坏。

我遵循以下想法：1 Class = 1 Job。

使用生理学类比：运动（神经系统），呼吸（肺），消化（胃），嗅觉（观察）等。这些控制器中的每一个都有一个子集，但无论它们是否要管理，它们都只有一个职责它们各自子系统的工作方式或它们是否是端点子系统并且仅执行一项任务，例如抬起手指或生长毛囊。

不要混淆它可能充当经理而不是工人的事实。当一些工人执行的工作变得过于复杂以至于一个流程无法自行处理时，他们最终会被提升为经理。

我经历过的最复杂的部分是，知道何时指定一个班级为操作员，主管或经理程序。无论如何，您需要观察并表示其功能以承担1种责任（操作员，主管或经理）。

当一个类/对象执行多个上述类型角色时，您会发现整个过程将开始出现性能问题或过程瓶颈。

我个人尤其希望采用“单一责任”这一重要原则，而人们采纳这一原则有很多原因。

其中一些原因可能是：

• 维护-SRP确保一类职责的改变不会影响其他职责，从而使维护工作变得更加简单。这是因为，如果每个类别只有一个职责，则对一个职责所做的更改与其他职责是隔离的。
• 测试-如果一个班级有一个责任，那么就很容易弄清楚如何测试这一责任。如果班级有多个职责，则必须确保您正在测试正确的职责，并且该测试不受班级所承担的其他职责的影响。

另请注意，SRP附带了SOLID原理包。遵守SRP而忽略其余部分与不进行SRP一样糟糕。因此，您不应单独评估SRP，而应在所有SOLID原则的背景下进行评估。

理解这些原则的重要性的最好方法是有需要。

当我还是一名新手程序员时，我并没有对设计进行太多思考，实际上，我什至不知道设计模式是否存在。随着我的程序的发展，改变一件事意味着改变许多其他事情。很难发现错误，代码庞大且重复。没有太多的对象层次结构，到处都是东西。 添加新的东西或删除旧的东西会在程序的其他部分带来错误。去搞清楚。

在小型项目中，这可能并不重要，但是在大型项目中，情况可能会非常糟糕。后来，当我遇到设计模式的概念时，我对自己说：“哦，是的，这样做会使事情变得容易得多”。

在需求出现之前，您真的无法理解设计模式的重要性。我尊重这些模式，因为根据经验我可以说它们使代码维护变得容易并且代码健壮。

但是，就像您一样，我仍然对“简单测试”不确定，因为我还不需要进行单元测试。

答案是，正如其他人指出的那样，它们全部都是正确的，而且它们相互融合，易于测试，使维护更容易，使代码更健壮，使维护更容易，等等。

所有这些都归结为一个关键的主体-代码应该尽可能的小，并尽可能少地完成工作。这不仅适用于功能，还适用于应用程序，文件或类。一段代码做的事情越多，就越难理解，维护，扩展或测试。

我认为可以用一个词来概括：范围。密切注意工件的范围，在应用程序中任何特定点范围内的事物越少越好。

扩展的范围=更多的复杂性=出错的更多方法。

如果一个班级太大，将很难维护，测试和理解，其他答案已经涵盖了这个意愿。

一个班级可能有多个责任而没有问题，但是很快您就会遇到过于复杂的班级的问题。

但是，只要有一个简单的规则“仅一个责任”，就可以更轻松地知道何时需要一门新课。

但是，定义“责任”很困难，并不意味着“按照应用程序规范的要求做所有事情”，真正的技能是知道如何将问题分解为“责任”的小单位。