设计模式的七大原则总述

软件开发过程中，程序员主要考虑的问题是：代码的耦合性，内聚性，可维护性，可扩展性，重用性，灵活性。设计模式就是对这些开发经验的总结与归纳。
1. 单一职责原则
对类来说，即一个类应该只负责一项职责，但不是说这个类只有一个方法，而是去做一件相关的事情。就比如说，你这个类是管理订单的，那么就不要出现管理员工的代码，而且如果订单比较复杂的话，也可以再拆分成不同职责的类。
这样做的好处是：
a. 降低类的复杂度，一个类只负责一项职责
b. 提高类的可读性，可维护性
c. 降低变更引起的风险
d. 通常情况下，应该遵守单一职责原则，只有逻辑足够简单，才可以在代码级别违反单一职责原则，只有类中的方法数量足够少，可以在方法级别保持单一职责原则。

2. 接口隔离原则
客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。比如一个接口中有五个方法需要实现，a1,a2,a3,a4,a5,而在业务A类中只用到a1,a2，在业务B中只用到a3.a4，这种情况下，应该拆分接口。业务中需要依赖自己需要的接口。（感觉在实际开发中，只能尽量往这个方向靠，如果完全按这个分解的话，就会变成，一个操作一个接口，用到哪个就依赖哪个了）

3. 依赖倒转原则
a. 高层模块不应该依赖低层模块，二者都应该依赖其抽象
b. 抽象不应该依赖细节，细节应该依赖抽象
c. 依赖倒转的中心思想是面向接口编程
d. 相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础的架构要稳定的多，在java中，抽象是指的接口或抽象类，细节就是具体的实现类。比如不应该给其它的模块直接提供使用Mapper的方法或dao的方法，而应该提供Service的方法。
e. 使用接口或抽象类的目的是为了制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖的传递方式有：1. 接口传递；2. 构造方法传递；3. setter方法传递。
依赖倒转原则一般要注意的是：
a. 低层模块尽量都要有抽象的类或接口，或者两者都有，稳定的稳定性更好。
b. 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序的扩展和优化。

4. 里氏替换原则
a. 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。
b. 继承实际上是让两个类耦合性增强了，在适当的情况下，可以通过聚合，组保依赖来解决问题。

5. 开闭原则
在类和方法应该对扩展开放，对修改关闭，用抽象构建框架，用实现扩展细节。
当软件发生变化时，尽量通过扩展软件的行为来实现变化，而不是通过修改已有的代码来实现变化。
这种原则要求我们在功能开发初期进行相关的代码设计，归纳总期需要实现的功能范围，对功能进行抽象处理，为后台的扩展留下清晰的方式，并且后面的扩展尽量不要影响旧的代码。可以参考这个案例：https://www.bilibili.com/video/BV1G4411c7N4?spm_id_from=333.788.videopod.episodes&vd_source=6fc8c9ff61efb6217b475498133ba3b3&p=17

6. 迪米法特原则，也叫最少知道原则
a. 一个对象应该对其它对象保持最少的了解
b. 类与类之间的关系越密码，耦合度就越大
耦合方式有很多，比如依赖，关联，组合，聚合，也就是常见的方法法参数，变量声明，方法返回。
对象只与直接交互的对象交互，比如A依赖了B，B依赖了C， 那么在A中最好不要直接调用C的方法，而是通过B去调用C的方法。

7. 合成复用原则
尽量使用合成或聚合的方式，而不是使用继承。优先考虑的是把复杂的业务详细划分成不同的模块，然后各个模块组合完成业务流程。

对于以上所述，如果开发经验比较少的人，感觉会比较抽象，不好懂，但是对于开发经验丰富，又想总结自己开发经验的人来说，可能比较有用。