【设计模式七大原则】

七个原则

核心思想：

• 找出应用中可能需要变化之处，把它独立出来，不要和那些不需要变化的代码混在一起
• 针对接口编程，而不是针对实现编程
• 为了交互对象之间的松耦合设计而努力

单一职责原则

一个类只负责一个功能

接口隔离原则

客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。即类不应该实现自己不需要的方法。

依赖倒置原则

细节依赖抽象，可以表现为具体的类依赖某一个接口。
注意：
1.低层的类尽量都需要有抽象类或者接口，这样稳定性更好。
2.变量的声明尽量是抽象类或者接口（易扩展）
3.继承时遵循里氏替换原则

依赖关系的三种传递方式：
1）接口传递
2）构造器传递
3）setter传递-初始化后需要调用set方法讲依赖注入

里氏替换原则

如何正确使用继承？
A——>B B重写了A的某个方法，不符合里氏替换原则，增加了耦合
Base——>A、B 讲相同的方法抽出来成为一个新类Base，AB同时继承

• 组合
  如果A需要使用到B中的方法，可以使用组合

class A extend Base{
private B b = new B();
}

• 聚合

class A extend Base{
	private B b;
	public A(B b){
		this.b = b;
	}
	public void set(B b){
		this.b = b;
	}
}

开闭原则OCP（设计模式核心）

扩展开放，修改关闭！
用抽象构建框架，用实现扩展细节

• 使用方依赖于抽象的类，通过对应抽象类的不同实现类的增加实现功能的扩展，而不是修改使用方的代码。

迪米特法则（最少知道原则）

只和直接的朋友通信

直接朋友：出现在成员变量、方法参数、方法返回值中的类
陌生类不要作为局部变量，把方法实现写在你依赖的类中，不要自己实现，而是直接调用他的方法。即对自己依赖的类知道的越少越好。

合成复用原则

尽量使用合成、聚合的方式，而不是使用继承