设计模式之六大原则

一、Single Responsibility Principle(简称SRP):单一职责原则

 定义：  就一个类而言， 应该仅有一个引起它变化的原因

       单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。单一职责原则是实现高内聚、低耦合的指导方针。我们在设计的时候，尽量单一，然后对于其实现类就要多方面的考虑。不能死套单一职责原则，否则会增加很多类，给维护带来不便。

二、Liskov Substitution Principle（简称LSP）里氏代换原则

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

      里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性。 里氏替换原则简单易懂一点的定义就是只要父类出现的地方子类就可以出现，且替换成子类也不会出现任何错误或者异常。(但是反过来，有子类出现的地方，父类不一定可以适用)。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

三、Dependence Inversion Principle （简称DIP）依赖倒转原则

定义： 要针对接口编程，而不是针对实现编程。模块间的依赖关系通过接口和抽象类产生，实体类之间不直接发生依赖关系。

 依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

四、Interface Segregation Principle（简称ISP）接口隔离原则

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情，为依赖接口的类定制服务。只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

五、Law of  Demeter（简称LoD）迪米特法则

定义：一个软件实体应当尽可能少地与其他实体发生相互作用

当我们对某一个模块发生修改时，就应尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。

六、Open Close Principle （简称OCP）开闭原则

定义：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展，开闭原则也是其他五个原则的基石。

当软件系统需要面对新的需求时，我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。

总得来说，我们在设计代码的时候尽量要做到面向接口编程，设计的接口要精简单一，高类聚，低耦合，能扩展，禁修改。