设计模式的七大原则

七大原则都是为了更好的代码重用性，可读性，可靠性，可维护性，可扩展性

1. 单一职责原则
   一个类应该只负责一项职责，降低类的复杂度。各个插件模块就是一种单一职责。

2. 开闭原则
   一个软件实体，比如类，模块和函数应该对扩展开放，对修改关闭。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化

3. 迪米特原则（最少知道）
   一个对象应该对其他对象保持最少的了解。类与类关系越密切，耦合度越大。即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不泄露任何信息。

4. 接口隔离原则
   客户端不应该依赖它不再需要的接口，一个类对另一个类的依赖应该建立在最小的接口上面。插件所提供的接口是精简和必要的最小单元。

5. 依赖倒转原则
   高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。依赖倒置原则经济与这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定。
   在插件机制的实现上，插件提供的接口可以看作是一种高层模式，不依赖于底层实现细节。

6. 里氏替换原则
   所有引用父类的地方能透明地使用子类的对象，子类对象能够替换父类对象，而程序逻辑不变。
   子类可以扩展父类的功能，但不能改变父类原有的功能。

7. 合成复用原则
   复用类通过“集成”和“合成”两种方式来实现。最大的缺点是增加了类之间的依赖，当父类发生改变时，其子类也会被动发生改变。
   介于继承存在的这些缺点，我们在复用类时，要优先考虑“合成”进行复用。合成复用原则的核心思想是：在编写代码时如果需要使用其他类，那么两个类最好使用合成/聚合的方式，而不是使用继承。
   我们可以通过类之间的“合成”来达到“复用”代码的诉求。