设计模式的六大法则

开闭原则（Open Closed Principle）

开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。对于扩展是开放的，对于修改是关闭的，这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。

开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

举个例子:在一个图片的加载类中，有内存缓存，磁盘缓存，还有双缓存三种缓存方式，一开始在加载类中会引入三个缓存类，但是当我们需要添加第四种缓存类的时候，就必须对加载类进行代码的修改了，这就违反了开闭原则，为什么增加缓存类会影响加载类的代码？遵循开闭原则，我们可以对缓存类的方法进行抽象成接口，加载类中引用的只是缓存的抽象接口，然后内存缓存，磁盘缓存，还有双缓存类分别实现该接口，以后添加第四种缓存类的时候我们只需要增加第四个实现缓存接口的缓存类就可以了，无需改动缓存类的实现代码。

单一职责原则(Single Responsibility Principle, SRP)

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。单一职责原则强调的是类功能实现上。

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

举个例子：

public class ForumService{

addThread(Thread thread);

addReplyMessage(Message message);

}

在上面论坛服务接口有两个方法，分别是增加一个主题addThread和增加一个回帖addReplyMessage，这是代表两个功能，那么这两个功能是否属于同一种职责呢？这需要从论坛这个模型结构考虑，如下：

Forum ---->Thread ------>Message

一个论坛Forum中有多个Thread，一个Thread包含一个根贴和多个回帖。

根据这种层次结构，增加回帖addReplyMessage的职责应该属于Thread，放入Forum中有点管得太宽了。

里氏替换原则(Liskov Substitution Principle，LSP)

里氏替换原则（LSP，Liskov Substitution Principle）是关于继承机制的原则，是实现开放封闭原则的具体规范，违反了里氏替换原则必然违反了开放封闭原则。里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。里氏替换原则强调的是类继承实现以及参数调用以及返回上。

定义：

  • 严格的定义：如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
  • 通俗的定义：所有引用基类的地方必须能透明地使用其子类的对象。
  • 更通俗的定义：子类可以扩展父类的功能，但不能改变父类原有的功能。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

  • 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
  • 子类中可以增加自己特有的方法。
  • 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
  • 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

依赖倒置原则（Dependence Inversion Principle，DIP）

依赖倒置原则强调的是类之间的关系，是指高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象，什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化。

接口隔离原则(InterfaceSegregation Principles，ISP)

接口隔离原则是指客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则要求建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用，否则会导致实现接口的类实现一些非必须的接口。接口隔离原则强调的是接口的设计实现上，要求接口细分。

举个例子：

这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。

以上的图就是遵循接口隔离原则的接口设计。

迪米特原则(Law of Demeter，LOD)，也称为最少知识原则（Least Knowledge Principle，LKP）

迪米特原则是指一个对象应该对其他对象有最少的了解。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。迪米特原则强调的是类之间的引用关系，降低类与类之间的偶和关系。

举个例子：

例如，购房者要购买楼盘A、B、C中的楼，他不必直接到楼盘去买楼，而是可以通过一个售楼处去了解情况，这样就减少了购房者与楼盘之间的耦合。

总结

说到这里，再回想一下前面说的5项原则，恰恰是告诉我们用抽象构建框架，用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。

results matching ""

    No results matching ""