目录
- 一、开放封闭原则
- 二、里式替换原则
- 三、依赖倒置原则
- 四、接口隔离原则
- 五、单一职责原则
一、开放封闭原则
概念理解
开放封闭原则是指在进行面向对象设计中，设计类或者程序应该遵循两点：对扩展开放和对修改关闭。这样，一个模块在实现的过程中，就可以在不修改原来的模块(修改关闭)基础上，扩展器功能(扩展开放)。
- 扩展开放。指的是某个模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
- 修改关闭。指的是某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求模块是修改关闭的。
开闭原则的实现方法
为了满足开闭原则的对修改关闭，对扩展开放原则，应该对软件系统中的不变的部分加以抽象。
实现原则：
- 把不变的部分抽象成不变的接口，这些不变的接口可以应对未来的扩展。在python中可以使用abc模块来建立抽象类，以及对应的接口。
- 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展，不足的部分可以通过定义新的接口来实现。
- 模块之间的调用通过该抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
优点：
- 提高系统的可复用性。
- 提高系统的可维护性。
开闭原则的相对性
软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块之间的关系，都不会从一开始就非常清晰明了。所以构建100%满足开闭原则的软件系统是非常困难的，这就是开闭原则的相对性。
但是在设计过程中，通过对模块功能的抽象(接口定义)，模块之间的关系的抽象(通过接口调用)，抽象与实现的分离(面向接口的程序设计)等，可以尽量接近满足开闭原则。
二、里式替换原则
所有引用父类的地方必须能够透明地使用其子类的对象。
概念理解
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
满足条件：
- 不应该在代码中出现if/else之类对子类类型进行判断的条件(因为父类出现的地方，子类就可以出现，因此不需要判断)。
- 子类应当可以替换父类，并出现在父类能够出现的任何地方，代码也能正常工作。
体现原则：
- 类的继承原则。如果用子类替换掉父类之后，出现运行错误，那么该子类不应该继承父类。或者，应该重新设计它们之间的关系。
- 动作正确性保证。这样，从另一个方方面保证了凡是符合LSP原则设计的类的扩展，不会对已有的系统引入新的错误。
里式替换原则为我们是否应该使用继承提供了判断的依据，不再是简单地根据两者之间是否有相同之处来决定是否使用继承。
里式替换原则的引申意义：子类可以扩展父类的功能，但是不能改变父类原有的功能。
表现几点：
- 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。
- 子类可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件(即方法的返回值)要比父类更严格。
优点：
- 约束继承泛滥，是开闭原则的一种体现。
- 加强程序的健壮性，同时变更时也可以做到非常好地提高程序的维护性、扩展性。降低需求变更时引入的风险。
class User:
def show_name(self):
pass
classVIPUser(user):
def show_name(self):
pass
def show_user(u):
res = u.show_name()
VIPUser这个类继承了User，它重写了父类的show_name，这个时候就必须保证子类的show_name方法的参数和返回值。不然当使用show_user方法调用的时候会出现问题。
重构违反LCP的设计：
如果两个具体的类A,B的关系违反了LSP的设计，(假设是从B到A的继承关系)，那么根据具体的情况可以在下面的两种重构方案中选择一种：
- 创建一个新的抽象类C，作为两个具体类的父类。然后将A、B的共同行为移动到C中来解决问题。
- 从B到A的继承关系更改为关联关系。
在进行设计的时候，我们尽量从抽象类继承，而不是从具体类继承。
如果从继承等级树来看，所有叶子结点应该是具体类，而所有树枝节点应该是抽象类或者接口。当然这只是一个一般性的指导原则，使用的时候还要具体情况具体分析。
在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。
三、依赖倒置原则
高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
针对接口编程，不要针对实现编程。
概念理解
依赖：在程序设计中，如果一个模块a调用了另一个模块b，我们称模块a依赖模块b。
高层模块和底层模块：在一个应用程序中，我们有一些低层次的类，这些类实现了一些基本的或者初级的操作，我们称之为底层模块，另外有一些高层次的类，这些类封装了某些复杂的逻辑，并且依赖于低层次的类，这些类我们称之为高层模块。
依赖倒置：面向对象程序设计相对于面向过程程序设计而言，依赖关系被倒置了。因为传统的结构化程序设计中，高层模块总是依赖于底层模块。
问题提出：
Robert C. Martin在书中给出了Bad Design的几个特征：
- 系统很难改变，因为每个改变都会影响其他很多部分。
- 当你对某个地方做一个修改的时候，系统的看似无关的其他部分都不工作了。
- 系统很难被另外一个应用重用，因为很难将要重用的部分从系统中分离出来。
这其中导致Bad Design的一个很大的原因是高层模块过分依赖底层模块。
但是一个良好的设计应该是系统的每个部分都是可替换的。如果高层模块过分依赖底层模块，一方面一旦底层模块需要替换或者修改，高层模块将受到影响，另外一方面，高层模块很难可以重用。
问题的解决：
Robert C. Martin提出了Dependency Inversion Principle (DIP) 原则。
DIP给出了一个解决方案：在高层模块与底层模块之间，引入一个抽象接口层。
High Level Classes(高层模块) --> Abstraction Layer(抽象接口层) --> Low Level Classes(低层模块)。
抽象接口是对底层模块的抽象，低层模块继承或者实现该抽象接口。
这样高层模块不直接依赖低层模块，而是依赖抽象接口层。抽象接口也不依赖低层模块的实现细节，而是低层模块依赖(继承或实现)抽象接口。
类与类之间都是通过抽象接口层来建立关系的。
怎么使用依赖倒置原则
1、依赖于抽象
- 任何变量都不应该持有一个指向具体类的指针或引用。
- 任何类都不应该从具体类派生。
2、设计接口而非设计实现
- 使用继承避免对类的直接绑定。
- 抽象类/接口：倾向于较少的变化，抽象是关键点，它易于修改和扩展，不要强制修改那些抽象接口/类。
例外：
有些类不可能变化，在可以直接使用具体类的情况下，不需要插入抽象层，如字符串。
3、避免传递依赖
- 避免高层依赖底层。
- 使用基层和抽象类来有效消除传递依赖。
优点：
- 减少类之间的耦合性
- 提高系统的稳定性
- 提高代码可读性和可维护性
- 降低修改程序所造成的风险
四、接口隔离原则
不能强迫用户依赖那些它们不适用的接口。
概念理解
换句话说，使用多个专门的接口比使用单一的总接口要好。
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法放在同一个接口里。如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。
- 接口的依赖(继承)原则：如果一个接口a继承另外一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后接口a也应该遵循上述原则：不应该包含用户不使用的方法。反之，则说明接口a被b给污染了，应该重新设计它们的关系。
接口隔离原则指导我们：
- 一个类对一个类的依赖应该建立在最小的接口上
- 建立单一接口，不要建立庞大臃肿的接口。
- 尽量细化接口，接口中的方法尽量少。
下面我们举例说明怎么设计接口或类之间的关系，使其不违反ISP原则。
假如有一个Door，有lock，unlock功能，另外，可以在Door上安装一个Alarm而使其具有报警功能。用户可以选择一般的Door，也可以选择具有报警功能的Door。
ISP原则的违反例一：在Door接口里定义所有的方法。
但这样一来，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。
ISP原则的违反例二：在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法，Door接口继承Alarm接口。
跟方法一一样，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。
遵循ISP原则的例一：通过多重继承实现
在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法。接口之间无继承关系。CommonDoor实现Door接口，AlarmDoor有2种实现方案：
1）同时实现Door和Alarm接口。
2）继承CommonDoor，并实现Alarm接口。
第2）种方案更具有实用性。
这样的设计遵循了ISP设计原则。
遵循ISP原则的例二：通过关联(或者叫做组合)实现
在这种方法里，AlarmDoor实现了Alarm接口，同时把功能lock和unlock委让给CommonDoor对象完成。
这种设计遵循了ISP设计原则。
接口分隔原则的优点和适度原则
- 接口分隔原则从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准：在为系统设计接口的时候，使用多个专门的接口代替单一的胖接口。
- 符合高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。
- 注意适度原则，接口分隔要适度，避免产生大量的细小接口。
五、单一职责原则
如果一个类需要改变，改变它的理由永远只有一个。如果存在多个改变它的理由，就需要重新设计该类。也就一个类只做一件事。
只能让一个类/接口/方法有且仅有一个职责。
如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）：
- 一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
- 另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。
这违反了设计的开闭原则，也不是我们所期望的。