深入理解设计原则之单一职责原则(SRP)【软件架构设计】

系列文章目录

C++高性能优化编程系列
深入理解软件架构设计系列
深入理解设计模式系列
高级C++并发线程编程

命运是弱者失败的借口，是强者乐此不疲的必修课。
Destiny is the weak's excuse for failure, is required for all the strong enthusiasm.

1、单一职责原则的定义和解读

单一职责原则(Single Responsibility Principle, SRP)的描述：一个类或模块只负责完成一个职责(或功能)。

注意单一职责原则描述的对象有两个：类(Class)和模块(Module)。关于这两个概念我们有两种理解方式。

• 一种理解方式把模块看作比类更抽象的概念，把类看作一种模块。
• 另一种理解方式把模块看作更粗粒度的代码块，多个类组成一个模块。

无论哪种理解方式，单一职责原则在应用这两个描述对象时，原理是相通的。粒度小，功能单一。

2、单一职责原则案例解读

2.1、违背单一职责原则反面案例

• 反面案例1: 重复的假象
  某个工资管理程序中的Employee类有三个函数caculatePay()、reportHourse()和save()。

这三个类的函数分别对应的是三类非常不同的行为者，违反了SRP设计原则。

caculatePay()函数是由财务部门制定的，他们负责向CFO汇报。
reportHourse()函数是由人力资源部制定并使用的，他们负责向COO汇报。
save()函数是由DBA制定的，他们负责向CTO汇报。

这三个函数被放在同一个源代码文件，即同一个Employee类中，程序员这样做实际就等于使三个类行为耦合在了一起。这有可能会导致CFO团队的命令影响到COO团队所依赖的功能。

例如，caculatePay()函数和reportHourse()函数使用同样的逻辑来计算工作时数。程序员为了避免重复编码，通常会将该算法单独实现一个名为的reportHourse()函数。

接下来，假设CFO团队需要修改正常工作时数的计算方法，而COO带领的HR团队不需要这个修改，因为他们对数据的用法是不同的。
这时候，负责这项修改的程序员会注意到函数调用了函数，但可能不会注意到该函数会同时被调用。

于是，该程序员就这样按照要求进行了修改，同时CFO团队的成员验证了新算法工作正常。这项修改最终被成功部署上线。

但是，COO团队显然完全不知道这些事的发生，HR仍然在使用产生的报表，随后就发现他们的数据出错了！最终这个问题让COO十分愤怒，因为这些错误的数据给给公司造成了几百万的损失。
与此类的事情我们多多少少都经历过。这类问题发生的根源就是因为我们将不同的行为所依赖的代码强凑到一起。对此，SRP强调这类代码一定要分开。

• 反面案例2: 代码合并
  一个拥有很多函数的源代码文件必然经历很多次代码合并，该文件中的这些函数分别服务不同行为者的情况就更加常见了。

例如，CTO团队的DBA决定要对Emploee数据表结构进行简单修改。与此同时，COO团队的HR需要修改工作时数据报表的格式。

这样一来，就很可能出现两个来自不同团队的程序员分别对Emploee进行修改的情况。不出意外的话，他们各自的修改一定会互相冲突，这就必要进行代码合并。

在这个例子中，这次代码合并不仅可能让CTO和COO要求的功能出错，甚至连CFO原本正常的功能也可能收到影响。

事实上，这样的案例还有很多，我们就不一一例举了。他们的一个共同点是，多人为了一个不同的目的修改了一份源代码，这很容造成问题的产生。

而避免这种问题产生的方法就是将服务不同行为者的代码进行切分。

2.2、违背单一职责原则反面案例 - 解决方案

我们有很多方法可以用来解决上面的问题，每一种方法都需要将相关的函数划分到不同的类。

其中，最简单直接办法是将数据与函数分离，设计三个类共同使用一个不包括函数的、十分简单的EmployeeData类，每个类只包含与之前相关函数的代码，互相不可见，这样就不存在相互依赖的情况了。

这种解决方案的坏处在于：程序员现在需要在程序里处理三个类。另一种方法是使用Facade(外观)设计模式。

这样一来，EmployeeFacade类所需要的代码量就很少了，他仅仅包含了初始化和调用三个类的函数。

当然，也有程序员更倾向于把重要的业务逻辑与数据放在一起，那么我们也可以选择将最重要的函数保留在Emploee类中，同时用这个类调其他没那么重要的函数。

读者也许会反对上面这些解决方案，因为看上去这里的每个类中都只有一个函数，事实上并非如此，因为无论是计算工资、生成报表还是保存数据都是一个很复杂的过程，每个类都可能包含了许多私有函数。

总而言之，上面的每一类都分别容纳了一组作用于相同作用域函数，而在作用域之外，它们各自的私有函数是互相不可见的。

3、类的职责是否越细化越好

在面向对象编程中，类的职责不应该过多、过于复杂，而应该越细越好，这是因为：

类的单一职责原则（Single Responsibility Principle）：每个类都应该只有一个职责，这样可以保证类的代码简洁明了、易于维护和扩展。

高内聚低耦合原则（High Cohesion Low Coupling）：将一个类拆分成多个单一职责的类，可以使得各类之间的耦合度降低，提高代码的灵活性和可复用性。

然而，同时过度细化职责也有其负面影响：

增加代码复杂度和维护成本：当类被拆分成过多微小的类时，会增加代码的数量和复杂度，导致维护成本的增加。

过度抽象将导致代码的不透明性和可读性降低：在面向对象编程中，过度抽象会导致代码难以阅读和理解。

因此，类的职责是否越细化越好，需要根据具体情况进行权衡。在实际编程中，需要保持类的职责尽量单一、明确，但不要过度细化，避免代码的冗余和不必要的复杂性。同时也要注意把握好封装的程度，保证类的内部实现不会对外部造成影响。

4、如何判断类的职责是否单一

要判断一个类的职责是否单一，可以使用以下方法：

1. 查看类的名称和文档：类的名称和文档应该准确地描述它的职责。如果名称或文档涵盖了多个职责，那么这个类可能不够单一。
2. 分析类中的方法：观察类中的方法是否都涉及同一个领域或者问题域。如果这些方法处理不同的领域或问题域，那么这个类可能不够单一。
3. 查看类的属性：观察类中的属性是否都与类的职责相关。如果属性与类的职责无关或者有多个职责，那么这个类可能不够单一。
4. 观察类的依赖关系：观察类是否依赖其他类或模块，如果这些依赖与类的职责无关或者有多个职责，那么这个类可能不够单一。
5. 观察代码的复杂度：观察类的代码是否过于复杂，如果代码过于复杂，可能说明这个类的职责不够单一。

综上所述，以上方法可以帮助你判断一个类的职责是否单一。如果你发现一个类的职责过于复杂或者不够单一，那么就需要考虑对这个类进行重构，将其拆分成多个单一职责的类。

5、小结

单一职责原则主要讨论的是函数和类之间的关系 - 但是它在两个讨论层面上会以不同的形式出现。在组件层面上，我们可以将其称为共同闭包原则，在软件架构层面，它则是用于奠定架构边界的变更轴心。