设计原则

分类：

单一职责原则

理解

错误理解：

• 每个模块只做一件事，确保一个函数只完成一个功能。在将大型函数重构称小函数时经常会用到这个原则，但这只是一个面向底层实现细节的设计原则，并不是SRP的全部。

逐步递进的描述：

• 任何一个软件模块都应该有且仅有一个被修改的原因。
• 任何一个软件模块都应该只对一个用户（User）或系统利益相关者（Stakeholder）负责。
• 任何一个软件模块都应该只对某一类行为者（actor）负责。

反面案例

案例1：重复的假象

某工资管理系统中的Employee类有三个函数calculatePay()、reportHours()、save()。这三个函数分别对应三类不同的行为者，违反了SRP设计原则。

• calculatePay()：由财务部门制定，他们负责向CFO汇报。
• reportHours()：由人力资源部门制定，他们负责向COO汇报。
• save()：由DBA制定，他们负责向CTO汇报。

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

例如，为了避免代码重复，calculatePay()和reportHours()同时依赖于regularHours()，当CFO团队想要修改正常工时计算方法时，修改了regularHours()函数，这时就会影响COO部门对reportHours()的使用。

案例2：代码合并

一个拥有很多函数的源代码文件必然会经历很对代码合并，该文件中的这些函数分别服务不同行为的情况就更常见了。

• CTO团队的DBA决定要对Employee的表结构进行修改。
• COO团队的HR需要修改工作时数报表的格式。

此时，不同团队的程序员分别对Employee类进行修改，一定会冲突，就必须要进行代码合并。

解决方案

类互不可见：将数据与函数分离，设计是那个类共同使用一个不包含函数的EmployeeData类，每个类只包含与之相关的函数代码，互不可见，这样就不存在互相依赖的情况了。

Facade模式：EmployeeFacade类所需的代码量就很少了，仅仅包含了初始化和调用三个具体实现类的函数。

重要程度区分：把重要的业务逻辑与数据放在一起，将重要的函数保留在Employee类中，用这个类来调用其他没那么重要的函数。

开闭原则

开闭原则（OCP）：设计良好的计算机软件应该易于扩展，同时抗拒修改。也就是，一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩张。