《设计模式》-02-面向对象的设计原则（单一职责，开放、闭合原则，接口隔离原则，依赖倒置原则，liskov替换原则，代码缺陷）

1. 单一职责

1.1 概述

单一职责原则强调一个类或模块应仅有一个引起其变化的因素（职责）

诠释：
通俗地讲，一个类或模块应只承担一个（或一种类型的）业务职责，而不是将内聚度较弱的业务行为强行耦合。
因为，当类承担的业务职责较多时，该类中任何职责需求的变化都会引起静态实现的变化，导致其代码不稳定。

• 示例
  如将订单系统和用户系统分开等等

1.2 不良影响

• 设计类数量的增加
  如果一个庞大的业务系统的所有类都按单一职责设计，则有可能导致设计类数量的“爆炸（Explosion）”。此外，设计类数量的增加也会使设计方案的复杂度增大。
• 破坏类的封装特性
  由于数据域封装在目标（实体）类中，如果从目标类中将含有数据域访问逻辑的业务行为分离出去，则势必造成外部代码访问目标类私有域的问题，而最终破坏目标类的封装特性。

2. 开放、闭合原则

2.1 概述

开放/闭合原则：要求类或模块的代码“对扩展是开放的（Open for Extension），对修改是关闭的”（Close for Modification）。

诠释：
这意味着，当软件需求发生变化时，目标类或模块的代码可以通过代码扩展很容易地实现新的需求，而不是修改已有类。

• 示例：
  一个支付类 将某宝支付和某信支付分为两个子类，加入信用卡支付或修改某信支付时并不需全盘修改。

2.1 不良影响

• 代码可读性降低
  抽象代码层隐藏了具体的业务细节，大大降低了代码的可读性。

• 程序测试成本增加

3. 接口隔离原则

3.1 概述

如果某个接口的行为不是内聚的，就应该按照业务分组，并将分组后的业务行为通过隔离的接口单独定义。

3.2 不良影响

• 接口数量“爆炸”
• 代码抽象度高
  抽象度高的代码具有稳定性、可复用性等优点，面向抽象编程较为推崇这种代码设计思维。但也应指出，代码抽象度越高，代码实现越复杂；代码抽象度越高，代码可读性（或可理解度）越差。

4. 依赖倒置原则

4.1 概述

高层模块不应依赖于低层模块，二者都应该依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。

4.2 不良影响

增加了代码的复杂度。

5. liskov替换原则

5.1 概述

建议子类对象必须能够完全替换掉它们的父类对象，而不需要改变父类的任何属性。

5.2 违反liskov原则

5.2.1 违反的示例

• 如下图，画一个表格，有柱状图和线图两种，柱状图需要画图和填充，而折线图只需要绘图
  

说明：
客户端ChartDrawer类在绘制不同类型图表组件时，需要知道父类ChartComponent的子类，然后才能对该组件进行绘制操作，这违反了Liskov替换原则。
因为Liskov替换原则建议：对于客户端程序ChartDrawer来说drawChart（）绘制行为使用的父类ChartComponent定义的对象，是可以被其子类Bar或Line定义的对象完全替换，而不需要提供额外的子类信息。

• 解决
  使得绘图包含填充，则子类可替换父类而不需要输入额外的子类信息。

5.2.2 违反后的代码缺陷

• 可扩展性差
• 容易引入逻辑错误

5.3 不良影响

• 在继承关系中，父类与子类之间是强约束关联
  即子类只能实现（或继承）父类的定义（域或行为），而不能更改；父类定义（域或行为）的变化会迫使所有子类随之变化。
• 限制了子类重写父类行为的逻辑，降低了代码的灵活性

---