七大原则
一、单一职责原则
一个类应该只负责一项职责。如果A类需要负责职责1，职责2，则应将A类拆分成A1，A2两类。如果代码足够简单，可以只在方法级别满足单一职责原则。（尽量避免使用分支结构（if……else））
作用：
1）降低复杂度；2）提高可读性；3）降低变更引起的风险（降低耦合度）
二、接口隔离原则
如果客户端通过一个接口依赖于另一个类，但是并未使用到这个接口的全部方法（如图图片来源：尚硅谷JAVA设计模式B站视频），这将被视作不满足接口隔离原则。
图片来源：尚硅谷JAVA设计模式B站视频【尚硅谷Java设计模式（图解+框架源码剖析）】 https://www.bilibili.com/video/BV1G4411c7N4/?p=10&share_source=copy_web&vd_source=d201972b0245c9267fedd48ea4a16172
应将接口拆开，使一个类对另一个类的依赖建立在最小接口上。
如图：
图片来源：尚硅谷JAVA设计模式B站视频【尚硅谷Java设计模式（图解+框架源码剖析）】 https://www.bilibili.com/video/BV1G4411c7N4/?p=10&share_source=copy_web&vd_source=d201972b0245c9267fedd48ea4a16172
通过拆分接口，A与C类的耦合度大大降低（例如若修改Interface2，C类将不会受到影响）。B类与D类也不用再实现不需要用到的功能，减少了代码冗余。
三、依赖倒置原则
通过抽象类/接口传递依赖关系，尽量不与低层（具体）的类产生关系。中心思想是面向接口编程。
1、低层（具体）类最好继承自抽象类，或拥有接口，方便其他类索取依赖关系。程序也将更加稳定。
2、尽量避免声明低层（具体）类对象，利用抽象对象和接口实现功能。利于程序扩展和优化
3、遵循里氏原则。
四、里氏替换原则
尽量避免重写父类方法，使程序在调用父类时，能透明地使用其子类的方法。如果不可避免地要使用其他方法，可以用组合，接口等进行替换。
换句话说，只有在概念上有父子关系的类才使用继承，避免不必要的重写。或者直接使用抽象父类，避免调用过程中的误导，降低代码可读性。功能性上的相似，可以利用组合传递其方法，而不是继承。
五、开闭原则（OCP原则）
特别重要
设计模式的终极原则：对扩展开放，对修改关闭。
经常使用与依赖倒置相同的方法改进代码。如用抽象父类作为一群相似对象与调用之间沟通的桥梁。只调用抽象方法，这样就可以将扩展作为抽象类的子类，而不用改变调用层的代码。
六、迪米特法则
迪米特法则也叫最少知道原则。一个对象应该对其他对象保持最少的了解，要求一个类对自己依赖的类知道的越少越好。
具体实现：只与直接朋友进行通信。
直接朋友：在类中直接调用或new一个其他类的对象，或是在方法中以参数或返回值调用哟个其他类的对象，那么这两个类被称作直接朋友。
简单来说，通过将一个类的逻辑无论多复杂都封装在这个类里，尽量避免在一个类的方法内部直接与某一陌生类产生通信。
七、合成复用原则
不是很重要
尽量使用合成/聚合的方法组织代码，而不是继承。将原本继承关系的两个类，可以通过在一个类中创建/传入另一个类的变量来实现通信。
设计模式原则总结：
1） 将可能发生变化的代码封装起来，不要与其他代码有较强的耦合性。
2）使用面向对象/面向接口的编程思维，而不是面向过程编程。
3）一切为了对象之间的松耦合而努力
