分类
- 开闭原则 (最重要的原则，所有原则的基础)
- 依赖倒置原则
- 单一职责原则
- 接口隔离原则
- 迪米特法则(最少知道)
- 里氏替换原则
- 合成/复用原则(组合复用原则)
开闭原则
定义
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
用抽象构建框架，用实现扩展细节
优点：提高软件系统的可复用性和可维护性
例
service 中有A、B、C三种方法
类class1实现service,并有自己的属性a,b,c，对应针对方法A、B、C返回
若后续有要求增加方法D，对class1中的a属性做基本修改然后返回：
此时，不应该直接在service中做修改增加方法D，而是应该写一个class2继承class1，并且新增属性d,方法D，而后获取D的时候用class2去获取。
依赖倒置原则
定义
高层模块不应该依赖底层模块，二者都应该依赖其抽象
抽象不依赖细节，细节依赖抽象
针对接口编程，不针对实现编程
优点：减少类间的耦合性，提高系统稳定性，提高代码可读性和可维护性，降低修改程序的风险
例
现在有一个支付流程，支付建单独创了一个类，里面有两个方法，微信支付、支付宝支付。然后控制层里面，根据业务逻辑调用微信支付或者支付宝支付，此时，控制层相对于支付类来说，是高层，若现在有了一个银行卡支付的需求，那么就需要支付的类新加了银行卡支付的方法，控制层才能使用，这就成了高层依赖于底层模块了，这样是不对的。修改：
新增抽象类或接口 里面有一个专门的支付的方法 pay(),而后新建三个实现类，分别为微信、支付宝、银行卡支付。再新建一个支付类，支付类里面也有一个pay(接口类型)方法，此时根据接口类型去判断是哪一个支付流程。那么在控制层类，就可以创建相应的支付类型，然后传入支付类里面直接调用了。
单一职责原则
定义
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障 不要存在多于一个导致类变更的原因
一个类/接口/方法只负责一项职责
优点：降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。
例
就是一个接口的功能要相对单一，比如一个订单，有新建、支付、审批等流程。这些都会影响到类功能的变更，所以应该分开类/接口/方法写。
对于方法和类来说，是一样的
接口隔离原则
定义
用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口
一个类对一个类的依赖应该建立在最小的接口上
尽量细化接口，接口中方法尽量少
优点：复合常说的高类聚低耦合的设计思想。
迪米特原则
定义
一个对象应该对其他对象保持最少的了解。又叫最少知道原则
即对外开发的应该做到该开放的开放，不开放的不开放，多运用包权限管理。对外部引入的类越少越好，降低类之间的耦合