设计模式之六大原则

1. 单一职责 
   顾名思义，就是一个类只负责单一的职责。 
   反例：类有两个职责，其中一个职责变化很有可能会导致另一个职责的正常运行。 
   方案：上面的两个职责分别建立两个类。

2. 里氏替换 
   子类可以扩展父类的功能，但不能改变父类原有的功能。 
   方案：子类除添加新的方法完成新增功能外，尽量不要重写父类的方法，也尽量不要重载父类的方法。

3. 依赖倒置 
   高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 
   业务逻辑层相对于数据层是高层模块，尽量不要让业务逻辑层依赖数据层， 
   可以在数据层抽象出一个接口，让业务逻辑层依赖于这个抽象接口。 
   反例：子类依赖低层类 A，有一天需要修改成子类依赖低层类 B，这时候就要修改大量代码。 
   方案：低层类 A 抽象出一个接口。让子类去依赖这个接口。以后要依赖低层类 B，只要 B 实现这个接口即可满足。

4. 接口隔离 
   顾名思义，接口需要隔离，为什么需要隔离，因为我们要将臃肿的接口拆分成最小接口。 
   如果不是最小接口，就需要去实现他们不需要的接口。

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

6. 开闭原则 
   当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。