系统设计原则

一、单一职责原则（SRP）

      每个类应当只负责单一内聚的职责，每一个职责都是变化的一个轴线，当需求变化时，该变化会反映为类的职责的变化。一个类应当仅有一个引起它变化的原因，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个，等于把这些职责耦合在了一起。违反SRP的设计通常可以采用门面模式或代理模式进行重构，分离业务的职责。

二、开闭原则（OCP）

      软件实体（类、包、模块等）应该是可以扩展的，但是不可修改的，即对于扩展是开放的，对于修改是封闭的，对实体的行为扩展时，无需改动源代码或二进制代码，即开闭原则（The Open－Closed Principle）。开闭原则的关键是抽象设计，对于完全的OCP是不可能的，应当对最有可能、最经常的变化进行抽象，遵循开闭原则，拒绝不成熟的抽象和抽象本身一样重要。

三、Liskov替换原则（LSP）

      子类型必须能够完全替换掉它们的基类型。满足Liskov原则的类型满足如下性质：若对每个类型S的对象O1，都存在一个类型T的对象O2，使得在所有针对T编写的程序中，用O1替换掉O2后，程序的行为功能不变，则S是T的子类型。OOD中IS－A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序所依赖的。模型的有效性只能通过它的客户程序来体现。一些违反了LSP的继承设计可以用提取公共部分的方法代替继承。

四、依赖倒置原则（DIP）

      1、高层模块不应该依赖于低层模块，二者都应该依赖于抽象；

      每个较高层次都为它所需要的服务声明一个抽象接口，较低的层次实现这些抽象接口，每个高层类都通过该抽象接口使用下一层，这样高层就不依赖于低层，低层反而依赖于高层声明的抽象服务接口。

      2、抽象不应该依赖于细节，细节应该依赖于抽象；

      程序中所有的依赖关系都应该终止于抽象类或者接口，即：
      任何变量都不应该持有一个指向具体类的指针或引用；

      任何类都不应该从具体类派生；

      任何方法都不应该覆写它的任何基类中已经实现的方法；

      如果一个具体类不太会改变，并且也不会创建其他类似的派生类，那么依赖于它不会造成损害。例如：java.lang.String。

五、接口隔离原则（ISP）

      不应该强迫客户依赖于它们不用的方法。

      胖接口会导致他们的客户程序产生不正常并且有害的耦合关系，当一个客户程序要求该胖接口进行一个改动时，会影响到其他的客户程序，因此，客户程序应当仅仅依赖于他们实际调用的方法，通过把胖接口分离为多个特定的客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的客户程序需要调用的方法，实现类实现所有特定于客户程序的接口，解除这些耦合关系，使客户程序之间互不依赖。

      分离接口的常用方式包括使用委托分离和使用多重继承分离。分离接口的关键在于对于接口的客户进行分组。