OOP设计原则
单一职责原则（SRP Single Responsibility Principle）
定义：
不能存在多于一个导致功能变更的原因。
不遵守导致的问题：
指责扩散，指责扩散就是某种原因，职责A被分化为粒度更细的职责A1和职责A2。
平时开发中的代码策略：
1.对不同的功能严格遵守SRP，创建单一职责的Class。
2.一个Class中的针对不同的功能添加单一职责的方法。
为何使用SRP：
1.降低Class的复杂度，逻辑比较简单
2.提高Class的可读性，提高系统的可维护性
3.变更引起的风险降低，减少对其他功能的印象
里氏替换原则（LSP Substitution Principle）
定义1：
在一个Progress中有O1:T1，O2:T2。如果替换所有的O1为O2时，程序行为没有发生变化，那么类型T2就是T1的子类型。
定义2：
所有引用基类的地方必须能透明使用子类的对象。
问题：如图所示，可能导致的问题，B完成P2的功能之后，可能会影响原本P1的正常功能。
解决方案：当使用继承时，遵循里氏替换原则，T2 extend T1，除了新添加的P2功能外，尽量不要重写基类的A方法，也尽量不要重载基类的任意方法。
里氏替换原则想表达的什么含义？
基类中凡是已经实现好的方法（相对于抽象方法而言，有别于抽象方法），实际上是在设定一系列规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但如果子类对这些非抽象方法任意修改，就会对整个继承系统造成破坏。
日常开发如何规避：
1.使用依赖，借口，聚合，组合的方式替换
2.把原来基类和子类都继承一个更佳通俗的基类，原本的继承关系被去掉
依赖倒置原则（DIP Dependence Inversion Principle）
A. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).
B. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
问题：类A某个功能依赖类B，现在该功能需要改为依赖C，则需要修改A的业务代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I。
依赖倒置的原则基于什么事实？
相对于细节的多变性，抽象的东西要稳定的多，面向接口编程连接各个层级。
接口隔离原则（Interface Segregation princple）
定义：一个Class不应该依赖它不需要的接口；
接口隔离原则的含义？
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。
也就是说，我们要为各个类建立专用的接口，而不是试图去创建一个庞大的接口提供给所有依赖它的类去调用。
ISP 和 SRP 的区分
- SRP注重职责，ISP注重对接口的依赖
- SRP主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节。ISP主要约束接口依赖，主要针对抽象，整体架构的构建
迪米特法则（LoD Law of Demeter）
定义：一个对象应该对其他对象保持最少的了解
Lod又称为最少知道原则，通俗讲，一个类对自己依赖的类知道越少越好。
开闭原则（OCP Open Close Principle）
定义：一个实体乳类、模块、函数应该对拓展开放，对修改关闭。
OCP想表达这样一层意思：
用抽象构建架构，用实现拓展细节。
