七大原则
设计模式目的
设计模式的目的是为了提高代码重用性、可读性、可扩展性、可靠性，使得程序呈现出高内聚、低耦合的特性。
- 代码重用性：相同功能的代码无需多次重复编写
- 可读性：编程按照一定规范，便于其他程序员的阅读和理解
- 可扩展性：当我们可以非常方便简单地增加新功能
- 可靠性：我们增加或删除部分功能时，对原有系统其他功能没有影响
- 高内聚、低耦合：
设计模式七大原则
设计模式原则，其实就是程序员编程时应当遵守的原则，也是各种设计模式的基础（即为什么设计模式要这么设计的依据）。
- 单一职责原则
- 接口隔离原则
- 依赖倒转原则
- 里氏替换原则
- 开闭原则
- 迪米特法则
- 合成复用原则
1、单一职责原则
对于类来说，就是一个类应该只负责一项职责，如果类A负责了职责1和职责2，当职责1的需求发生改变时，可能对职责2的执行造成影响，因此需要将类A分解为类A1和类A2。
单一职责原则小结：
- 为了降低类的复杂度，做到一个类只负责一项职责；
- 可以提高类的可读性和可维护性，降低变更引起的风险；
- 通常情况下，我们应当逻辑单一职责原则，只有逻辑足够简单才能在代码上违反单一职责原则，只有类中方法数量很少，才可以只在方法级别上遵守单一职责原则。
2、接口隔离原则
客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。
为什么会有接口隔离？考虑这么一种情况，现有一个接口包含了三个方法，有类A和类B实现了该接口，而类C和类D依赖于该接口。（这里依赖的意思，类C和D中有方法的参数是接口，而我们可以将实现了接口的类A和B作为C和D方法的参数）。
3、依赖倒转原则
-
高层模块不应该依赖底层模块，二者都应该依赖于抽象
-
抽象不应该依赖于细节，细节要依赖于抽象
-
抽象在Java中就是指接口或抽象类，细节就是具体的实现类
-
依赖倒转的中心思想就是面向接口编程
-
使用接口或抽象类的目的是为了制定好规范，而不涉及任何具体的作用，把展现细节的任务交给它们的实现类。
依赖倒转小结：
- 底层模块尽量都要有抽象类或接口，这样程序稳定性更好！
- 变量的声明类型尽量都是抽象类或接口，这样我们的变量引用和实际对象间就有一个缓冲，利于程序扩展和优化。
- 继承时遵循里氏替换。
4、里氏替换原则
-
所有引用基类的地方，必须能透明的使用其子类。
-
因此，在继承时，子类尽量不要重写父类的方法。
-
继承会让两个类的耦合性增强，因此适当情况下，可以通过聚合、组合、依赖来解决问题。（假如A继承于B，我们可以抽取其公共部分为Base类，然后使用组合，在A类中创建B的对象）
5、开闭原则
- 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
- 一个软件实体，例如类、模块、函数应该对扩展开发（针对开发方），对修改关闭（针对使用方）。用抽象构建框架，用实现扩展细节。
- 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有代码来实现变化。
- 编程中遵循的其他原则，以及使用设计模式的目的就是遵守开闭原则。
6、迪米特法则
- 一个对象应该对其他对象保持最少的了解
- 类与类关系越密切，耦合度越大
- 迪米特法则也叫最少知道原则，即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法外，不要泄露任何信息。
- 迪米特法则还有个更简单的定义：只与直接朋友通信。
- 直接朋友：只要两个对象间有耦合关系，那么它们就是朋友。耦合包括依赖、关联、组合、聚合等等。其中，我们将成员变量、方法参数、方法返回值中的类称为直接朋友，而出现在局部变量中的类（例如class A的一个方法里有class B对象）不是直接朋友。换句话说，陌生的类最好不要以局部变量的形式出现在类的内部。
注意：迪米特法则的核心只要求降低类之间的耦合，并不是完全没有依赖。
7、合成复用原则
尽量使用合成/聚合的方式，而不是使用继承。下面四种方式都可以让B使用A的方法，但继承的方式耦合度太高。
