设计模式六大原则

1. 单一职责原则：对于一个类，应该仅有一个引起它变化的原因。

问题由来：一个类有两个不同的职责P1 P2.当由于P1需求改变发生变化时，可能导致P2出现功能故障。

解决方案，分别建立两个类T1 T2实现P1 P2 的职责

所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

优点：

    1. 降低类的复杂度

    2. 提高类的可读性，提高系统的可维护性

    3. 变更引起的风险降低

2. 里氏替换原则

定义：引用基类的地方必须能透明的使用其子类对象。

解决方案：在季恒是，类B继承类A，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

3. 依赖倒置原则

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

问题由来：类A直接依赖类B，现在要把A改为依赖类C，由于A为上层代码，直接修改类A会带来一定风险

解决方案：将B，C抽象为接口I，A依赖于接口Ｉ的实现。

核心思想：面向接口编程

4. 接口隔离原则

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

问题的由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类AB来说不是最小接口，则B和C需要实现他们不需要的方法

解决方案：将臃肿的接口Ｉ拆分为独立的几个接口

5. 迪米特法则

定义：一个对象应该和其他对象保持最少的了解

问题由来：类和类之间的耦合性越大，当一个类改变时，对另一个类的影响也就越大。

解决方案：降低类与类之间的耦合

6. 开放-封闭原则：软件实体（类、模块、函数）应该可以扩展，但是不可更改

定义：软件实体如类、模块和函数应该对扩展开放、对修改关闭

问题由来：在代码维护过程中对原有代码的修改可能会引入错误，这种时候需要对所有代码进行测试

解决方案：需求变化的时候通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化