【设计模式】六大原则

 

使用设计模式的根本原因是适应变化，提高代码复用率，使软件更具有可维护性和可扩展性。并且，在进行设计的时候，也需要遵循以下几个原则：单一职责原则、开放封闭原则、里氏代替原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。在面向对象设计模式中存在的是五大原则和一个法则。下面就分别介绍了每种设计原则。

单一职责原则

（Single Responsibility Principle）

就一个类而言，应该只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，也会影响复用性。

事实上很多程序员爱写大类超多成员或爱用静态成员，都是对内聚性的一种破坏——所以这些人很难想起来还有一个单一职责的原则！慢慢的这个原则就是被忘记了！

开放封闭原则

（Open Close Principle）    

开闭原则即OCP（Open-Closed Principle缩写）原则，该原则强调的是：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。

符合开闭原则的最好方式是提供一个固有的接口，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互。

在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。

里氏替换原则

（Liskov Substitution Principle）

 指的是子类必须替换掉它们的父类型。也就是说，在软件开发过程中，子类替换父类后，程序的行为是一样的。只有当子类替换掉父类后，此时软件的功能不受影响时，父类才能真正地被复用，而子类也可以在父类的基础上添加新的行为。

里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而父类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

依赖倒置原则

（Dependence Inversion Principle）

指的是抽象不应该依赖于细节，细节应该依赖于抽象，也就是提出的 “面向接口编程，而不是面向实现编程”。具体内容：针对接口编程，依赖于抽象，而不依赖于具体。

这样可以降低客户与具体实现的耦合。

这个原则是开闭原则的基础。

接口隔离原则

（Interface Segregation Principle）

指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。

过于臃肿的接口是对接口的一种污染。

合成复用原则

（Composite Reuse Principle）

在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。

要使用好合成复用原则，首先需要区分"Has—A"和“Is—A”的关系。

 “Is—A”是指一个类是另一个类的“一种”，是属于的关系，而“Has—A”则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.

实际上，雇员、经历、学生描述的是一种角色，比如一个人是“经理”必然是“雇员”。在上面的设计中，一个人无法同时拥有多个角色，是“雇员”就不能再是“学生”了，这显然不合理，因为现在很多在职研究生，即使雇员也是学生。

上面的设计的错误源于把“角色”的等级结构与“人”的等级结构混淆起来了，误把“Has—A”当作"Is—A"。具体的解决方法就是抽象出一个角色类：

 

迪米特法则

（Demeter Principle）

迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。

关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。

外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。