1.开放封闭原则

• 对扩展开放, 对修改关闭

当有新的需求的时候, 应该增加新的对象来实现, 而不是修改原来的代码

在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

2.单一职责原则

• 应该有且仅有一个原因引起类的变更。

当一个类因为需求而发生改变的时候, 只应该改变它自己, 而不是改变其他的类

单一职责的好处：

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高；
• 可维护性提高；
• 变更引起的风险降低。

变更是必不可少的，如果接口的的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

3.里氏替换原则(LSP Liskov Substitution Principle)

• 所有引用基类的地方必须能透明地使用其子类的对象。

只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本不需要知道是父类还是子类。但反之就不行了。

如果你的代码需要知道具体对象是哪个子类就要好好反思一下了
如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生 畸变，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

4.依赖倒置原则

• 针对接口编程, 依赖于抽象, 而不是具体的类

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

5.接口隔离原则

• 使用多个隔离的接口, 降低接口的耦合

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

这两句话可以概括为一句话：建立单一接口，不要建立臃肿庞大的接口。
更通俗的讲：接口尽量细化，同时接口中的方法尽量少。

接口隔离原则 vs. 单一职责原则:
二者的审视角度不同，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少，它要求”尽量使用多个专门的接口“。

6.最少知识原则(迪米特法则)

• 一个实体应当尽量少的与其他实体之间发生相互作用

Law of Demeter，简称LoD，也称为最少知识原则，Least Knowledge Principle，简称LKP，两个名字含义相同：一个对象应该对其他对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道得最少，只关注自己调用的public方法，其他的一概不关心。

类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

• 找出应用中可能需要变化的地方, 把他们独立出来, 不要和那些不需要变化的代码混在一起

• 针对接口变成, 而不是针对实现变成

• 多用组合, 少用继承