0 引言
单一职责原则：类应该只有一个改变的理由；
开放-封闭原则：类应该对扩展开放，对修改关闭；
迪米特原则：只和朋友交谈；
里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能；
接口隔离原则：不能强迫用户去依赖那些他们不使用的接口；
依赖倒转原则：针对接口编程，不针对实现编程；
组合/聚合复用原则：多用组合，少用继承。
1 单一职责原则（SRP）
它的准确解释是，就一个类而言，应该仅有一个引起它变化的原因[ASD]。即永远不要让一个类存在多个改变的理由。
如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，而这种变化将影响到该类不同职责的使用者（不同用户）：
一方面，如果一个职责使用了外部类库，则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
另一方面，某个用户由于某个原因需要修改其中一个职责，另外一个职责的用户也将受到影响，他将不得不重新编译和配置。这违反了设计的开闭原则，也不是我们所期望的。
如果你能想到一个类存在多个使其改变的原因，那么这个类就存在多个职责。
2 开放-封闭原则（OCP）
开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。[ASD]
扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求模块是修改关闭的。
原因：稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。
扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。
开闭原则的实现方法
为了满足开闭原则的对修改关闭原则以及扩展开放原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，
- 可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；
- 接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；不足的部分可以通过定义新的接口来实现；
- 模块之间的调用通过抽象接口进行，这样即使实现层发生变化，也无需修改调用方的代码。
接口可以被复用，但接口的实现却不一定能被复用。
接口是稳定的，关闭的，但接口的实现是可变的，开放的。
可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔性扩展。
3 迪米特原则（最少知道原则)LoP
迪米特法则（LoD），如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。[J&DP]
迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块相互独立，相互之间不存在依赖关系。
应用迪米特法则有可能造成的一个后果就是，系统中存在的大量的中介类，这些类只所以存在完全是为了传递类之间的相互调用关系—这在一定程度上增加系统的复杂度。
4 里氏替换原则(LSP)
所有引用基类的地方必须能透明地使用其派生类的对象。里氏替换原则是对开闭原则的扩展，它表明我们在创建基类的新的子类时，不应该改变基类的行为。
也就是说，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：
- 不应该在代码中出现if/else之类对派生类类型进行判断的条件。
- 派生类应当可以替换基类并出现在基类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的派生类所代替，代码还能正常工作。
里式替换原则的引申意义：子类可以扩展父类的功能，但不能改变父类原有的功能。
具体来说：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的方法时（重载/重写或实现抽象方法）的后置条件（即方法的输出/返回值）要比父类更严格或相等。
5 接口隔离原则（ISP）
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
它包含了2层意思：
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。
- 接口的依赖（继承）原则：如果一个接口a继承另一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包含用户不使用的方法。 反之，则说明接口a被b给污染了，应该重新设计它们的关系。
如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。这显然违反了开闭原则，也不是我们所期望的。
总而言之，接口分隔原则指导我们：
- 一个类对一个类的依赖应该建立在最小的接口上
- 建立单一接口，不要建立庞大臃肿的接口
- 尽量细化接口，接口中的方法尽量少
6 依赖倒转原则(DIP)
赖倒转原则，原话解释是抽象不应该依赖细节，细节应该依赖于抽象，这话绕口，说白了，就是要针对接口编程，不要对实现编程。
A. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
B. 抽象不应该依赖于细节，细节应该依赖于抽象
C.针对接口编程，不要针对实现编程。
在高层模块与低层模块之间，引入一个抽象接口层。
High Level Classes（高层模块） --> Abstraction Layer（抽象接口层） --> Low Level Classes（低层模块）
抽象接口是对低层模块的抽象，低层模块继承或实现该抽象接口。
这样，高层模块不直接依赖低层模块，而是依赖抽象接口层。抽象接口也不依赖低层模块的实现细节，而是低层模块依赖（继承或实现）抽象接口。
7 组合/聚合复用原则即组合优于继承
尽量使用组合/聚合，不要使用类继承。
聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。
只有当以下的条件全部被满足时，才应当使用继承关系：
1）派生类是基类的一个特殊种类，而不是基类的一个角色，也就是区分"Has-A"和"Is-A"。只有"Is-A"关系才符合继承关系，"Has-A"关系应当用聚合来描述。
2）永远不会出现需要将派生类换成另外一个类的派生类的情况。如果不能肯定将来是否会变成另外一个派生类的话，就不要使用继承。
3）派生类具有扩展基类的责任，而不是具有置换掉（override）或注销掉（Nullify）基类的责任。如果一个派生类需要大量的置换掉基类的行为，那么这个类就不应该是这个基类的派生类。
4）只有在分类学角度上有意义时，才可以使用继承。
参考：面向对象设计的七大设计原则详解_面向对象的八大设计原则-CSDN博客
