设计模式总结

[TOC]

设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。设计模式（Design pattern）代表了最佳的实践

1. 设计模式七大原则

1.1 单一职责原则

单一职责原则（Single Responsibility Principle，SRP）。单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分

There should never be more than one reason for a class to change

• 优点
  单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。具有以下优点
  • 降低类的复杂度。一个类只负责一项职责
  • 提高类的可读性。
  • 降低变更引起的风险。如果遵守单一职责原则，当修改一个功能时，可以显著降低对其他功能的影响。
• 实现方式
  单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中

1.2 依赖倒置原则

依赖倒置 (Dependency Inversion Principle)。 定义为：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象
• 抽象不应该依赖细节，细节应该依赖抽象

High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions

其核心思想是：要面向接口编程，不要面向实现编程。依赖于抽象而不依赖于具体, 因为接口更加稳定。

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

• 优点

  • 降低类间的耦合性。
  • 提高系统的稳定性。
  • 提高代码的可读性和可维护性。

• 实现方式

  • 每个类尽量提供接口或抽象类，或者两者都具备。
  • 变量的声明类型尽量是接口或者是抽象类。
  • 任何类都不应该从具体类派生。
  • 使用继承时尽量遵循里氏替换原则。

1.3 接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP), 又称最小接口原则。尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

• 客户端不应该强制依赖他不使用的接口
• 一个类对另一个类的依赖应该建立在最小的接口上

Clients should not be forced to depend on methods they do not use
The dependency of one class to another one should depend on the smallest possible interface

这个原则的意思是：使用多个隔离的小接口，比使用单个大接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

• 优点

  • 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性
  • 接口的粒度大小定义合理，能够保证系统的稳定性
  • 使用多个专门的接口还能够体现对象的层次

• 实现方式

  • 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
  • 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
  • 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情

1.4 里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）。一个程序，如果将基类全部替换为子类，程序的行为不变，那么就说符合里氏替换原则。

Inheritance should ensure that any property proved about supertype objects also holds for subtype objects

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

• 优点

  • 里氏替换原则是实现开闭原则的重要方式之一
  • 它克服了继承中重写父类造成的可复用性变差的缺点
  • 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性

• 实现方式
  里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法（只重写抽象方法）。

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

1.5 开闭原则

开闭原则 (Open Closure Principle)。软件实体应当对扩展开放，对修改关闭.

Software entities should be open for extension，but closed for modification

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

• 优点
  开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性

  • 遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了
  • 可以提高代码的可复用性
  • 遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

• 实现方式
  可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
  因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

1.6 迪米特法则

迪米特法则（Demeter Principle)，又称最少知道原则

最少知道原则是指：一个类依赖于另一个类，应当尽量少知道该的细节。

一个类依赖其他类的情形：

• 成员变量
• 方法参数
• 方法返回值
• 成员方法中的局部变量 （违背了迪米特法则，建议封装消除该细节）

1.7 优先组合原则

合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

• 实现方式
  合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

7种设计原则总结对比

设计原则	一句话归纳	目的
开闭原则	对扩展开放，对修改关闭	降低维护带来的新风险
依赖倒置原则	高层不应该依赖低层，要面向接口编程	更利于代码结构的升级扩展
单一职责原则	一个类只干一件事，实现类要单一	便于理解，提高代码的可读性
接口隔离原则	一个接口只干一件事，接口要精简单一	功能解耦，高聚合、低耦合
迪米特法则	不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度	只和朋友交流，不和陌生人说话，减少代码臃肿
里氏替换原则	不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义	防止继承泛滥
合成复用原则	尽量使用组合或者聚合关系实现代码复用，少使用继承	降低代码耦合

2. 23种设计模式

2.1 创建型模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成

创建型模式分为以下几种：

• 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
• 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
• 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
• 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
• 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。

2.2 结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。

结构型模式分为以下 7 种：

• 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
• 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
  如电源适配器、Usb网卡适配器等
• 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
  多个独立变化的维度，通过组合桥接，实现了多种组合
• 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
• 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
• 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
• 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

2.3 行为型模式

多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。

包含以下 11 种模式：

• 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
• 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
• 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
• 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
• 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
• 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
• 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
• 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
• 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
• 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
• 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

参考

Java设计模式：23种设计模式全面解析（超级详细）