设计的五大原则-SOLID

1.背景

最近在读《架构整洁之道》这一本书，这本书的确写得不错，最近也没有更新文章，一方面再忙工作，另一方面也再啃一些书。当然文章还是得更新，《架构整洁之道》里面有些有意思的内容我会提取出来外加自己的思考。在这本书里面的第三章介绍了设计原则，这部分我觉得对于大家的平时工作都比较有用。

2. 设计原则

想必大家在学习面向对象的时候,都学习过下面几大原则:

• SRP 单一职责:该设计原则是基于康威定律的推论，每个软件模块有且只有一个被更改的理由。

• OCP 开闭原则:对扩展开放，对修改关闭。

• LSP 里氏替换原则:任何基类可以出现的地方，子类一定可以出现。

• ISP 接口隔离原则:在设计中需要避免不需要的依赖。

• DIP 依赖反转原则:高层策略性代码不应该依赖底层细节的代码，而应该是底层细节代码依赖高层策略。

这五个原则也被称为，SOLID原则取的是他们的首字母。这个也是我们做一个好设计的基础，接下来会依次对其进行解释。

3.SRP:单一职责

SRP很容易被大家从字面意思无界，并不是每个模块只做一个事，而是每个模块的变化原因只有一个。在书中对于SRP最后的解释是:

任何一个软件模块都应该只对某一类行为者(有共同需求的人)负责。

这里的软件模块指的就是一个源代码文件或者一组紧密相关的函数和数据结构。SRP原则应该是大家运用得最多的原则之一。在书中举了一个例子，有一个Employee类其中有三个函数:

• calculatePay():计算工资，由财务部门制定，需要向CFO汇报。

• reportHours():计算工时，人力资源制定，向COO汇报

• save():由DBA制定，向CTO汇报。

这里三个函数都放在了Employee类中，其实也就是把三个行为者的行为都耦合在了一起。一般来说计算工资，会获取正常工时，而计算工时也会获取工时，这两个函数都依赖了一个获取工时的方法，如果财务部门计算工资时，想修改逻辑，看大家辛苦了1个小时当1.1个小时发工资，这个时候修改了这个获取工时的方法，但是HR部门并不需要这个修改，这个时候就会导致reportHours()这个方法出现数据错误。所以这个时候就需要将不同行为者的代码就行拆分。

3.1