目录
1.开闭原则
开放封闭原则，是说软件实体（类、模块、函数等）可以扩展，不可以修改。
**核心思想：**对于扩展是开放的，对于修改是封闭的。
应该怎么做？
当需求变化 的时候，将程序中频繁变化的部分 拿出来做抽象。
**优点：**易维护、易扩展、可复用、灵活性好。
2.里氏代换原则
里氏代换原则，子类型必须能够替换它们的父类型
核心思想：在软件里，将父类替换为子类，程序的行为没有变化。
优点：
1.提高代码复用性；
2.提高可扩展性。
缺点：
1.降低灵活性，子类会受父类约束；
2.增强了耦合性，当父类发生变化，需要修改时，需要考虑子类。
3.单一职责原则
单一职责原则，是说就一个类而言，应该仅有一个能引起它变化的原因。
核心思想：如果一个类承担的职责过多，就等于把过多的职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。所以当变化发生的时候，设计会遭受到意想不到的破坏。
应该怎么做？
发现职责并将职责间相互分离，如果该类承担大于一个职责，那么这个类就应该考虑职责分离。
**优点：**复杂性低、可读性高、易维护、易扩展。
4.依赖倒置原则
抽象不应该依赖细节，细节应该依赖于抽象。
核心思想：
1.高层模块不应该依赖低层模块，两个都应该依赖于抽象；
2.抽象不应该依赖细节，细节应该依赖于抽象。
软件的实现一般是高层模块调用低层实现，但是如果低层实现有多重需求，那么高层模块就无法进行复用，所以，不管是高层还是底层，都需要抽象出一个接口。
应该怎么做？
在进行软件设计的时候，将所有的依赖关系都引入到抽象类或者接口，针对抽象编程。
优点：
1.减少类的耦合性
2.提高代码的可读性和可维护性
3.提高系统稳定性
5.迪米特法则
又称最少直到原则，一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三个类调用。
核心思想：
在类的结构设计上，每一个类都应该尽量降低成员的访问权限，强调的是类之间的松耦合。类之间的耦合越弱，越有利于复用。
应该怎么做？
如果本类新增一个方法，既不会增加类间关系，也不会产生其他影响，就应在本类中增加该方法。
6.接口隔离原则
类间的依赖关系应该建立在最小的接口上。
核心思想：
1.接口要小，但也要注意小的分寸；
不出现臃肿的接口
2.减少对外交互
在接口中尽量少防止public方法