【程序设计】设计模式

概述

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

分类

按照使用场景可以分为三大类

创建型模式（Creational Patterns）

对象实例化的模式，创建型模式用于解耦对象的实例化过程。
对对象的实例化过程进行抽象，这使得一个系统可以不用关心这些对象是如何创建、组合及呈现的，对类创建模式来说，通过使用继承改变实例化的类，对对象创建模式来说，通过使用代理来实例化所需要的对象。

• 工厂模式（Factory Pattern）
  封装了对象的创建过程，调用者使用具体的工厂方法时根据参数就可获取对应的对象。
  • 使用场景
    • 在不同条件下创建不同实例，用于统一管理Bean。
    • 在不同条件下调用不同的工厂方法获取不同场景下的Bean。
• 原型模式（Prototype Pattern）
  相比单例设计模式，原型模式是每次创建一个对象。
• 构建者模式（建造者模式）（Builder Pattern）
  将一个复制对象的创建屏蔽到接口内部，用户使用时只需传递固定的参数，内部就会在执行复杂逻辑后返回用户需要的对象，用户不需要知道创建的细节。
  • 使用场景
    • 当一个对象比较复杂并容易出错时，可考虑此模式去屏蔽创造细节。
• 单例模式（Singleton Pattern）
  提供一个创建对象的接口，但多次调用该接口返回的是同一个实例的引用，目的是为了保证只有一个实例并提供一个访问这个实例的统一接口。
  • 优点：该类在系统内存中只存在一个对象，节省了系统资源，对一些需要频繁创建销毁的对象使用单例模式可提高系统性能。
  • 缺点：当想实例化一个单例类时，必须要使用相应的获取对象的方法而不是使用new，可能会给其他开发人员造成困扰，特别是在看不到源码时。
  • 适用场合
    • 需要频繁地进行创建和销毁的对象。
    • 创建对象时耗时过多或耗费资源过多但又经常用到的对象。
    • 工具类对象。
    • 频繁访问数据库或文件的对象。
  • 使用场景
    • 同一个JVM应用的不同模块需要使用同一个对象实例进行信息共享。
    • 需要同一个实例来生成全局统一的序列号。

结构型模式（Structural Patterns）

把类或对象结合在一起形成一个更大的结构。
通过对多个类和对象进行组合得到复杂结构的类，一般使用继承继承或成员变量引用形式来实现。

• 适配器模式（Adapter Pattern）
  它为两个不同接口之间互通提供了一种手段。
  • 使用场景
    • 两个系统交互时，由于接口参数不一样而没法直接对接，则可以搞个适配器接口做参数转换。
    • 适配器模式经常是在一个系统或设计已经定型时用的，而不是在初始设计时，一般是为了在不影响现在业务情况下通过适配方式统一接口。
• 桥接模式
• 过滤器模式
• 组合模式
• 装饰者模式（Decorator Pattern）
  它作用是对对象已有功能进行增强，但是不改变原有对象结构。这避免了通过继承方式进行功能扩充导致的类体系臃肿。
  • 使用场景
    • 在不改变原有类结构基础上新增或限制或改造功能时。
• 门面模式（Facade Pattern）
  它通过新增一个门面类对外暴露系统提供的一部分功能或屏蔽内部系统的复杂性，对外部仅仅暴露一个简单的接口或通过调用不同的服务对外提供统一的接口让使用者对这些内部服务透明化。
  • 使用场景
    • 当需要对外屏蔽一个系统的复杂性时可考虑使用门面模式对外提供简单的可读性高的接口类。
    • 当需要对外部暴露系统一部分权限的接口时可考虑使用门面模式减少系统权限。
    • 当系统需要调用不同服务汇总后再对外提供服务时可考虑使用门面模式对外屏蔽细节，只暴露一个接口。
• 享元模式（蝇量模式）
• 代理模式

行为型模式（Behavioral Patterns）

类和对象如何交互及划分责任和算法。
不仅表达了对象和类，还表达了它们之间的交互，涉及到了对象和算法的分配。

• 责任链模式（Chain of Responsibility Pattern）
  是把多个对象串联起来形成一个链状结构，让每个对象都有机会对事件发送者的请求进行处理。责任链模式的设计意图是为了使事件发送者和事件接受者之间解耦。
  • 使用场景
    • 当一个请求需要根据请求参数的不同由不同对象来处理时。
    • 当一个请求需要固定对象顺序处理并可扩展性地在固定顺序里插入新的对象进行处理时。
• 命令模式（Command Pattern）
  通过把命令封装为一个对象，命令发送者把命令对象发出后就不去管是谁来接受处理这个命令，命令接受者接受到命令对象后进行处理，也不用管命令是谁发出的，所以命令模式实现了发送者与接受者之间的解耦，而具体把命令发送给谁还需要一个控制器。
• 解释器模式
• 迭代器模式
• 中介者模式
• 备忘录模式
• 观察者模式（Observer Pattern）
  它定义了当一个对象的状态或属性发生变化时通知其他对这些状态感兴趣的对象。观察者模式也叫发布-订阅模式，也就是订阅了某一个主体时，若发布者改变了主体内容，那么所有订阅这个主体者都会收到通知。
  • 使用场景
    • 满足发布-订阅条件的，即当一个对象状态或属性变化时需要把这种变化通知到订阅者时。
• 状态模式
• 空对象模式
• 策略模式（Strategy Pattern）
  它定义一系列的算法对象，使用时可以令它们相互替换。
  • 使用场景
    • 运行时根据条件的不同而使用不同的策略处理一个事情，与责任链不同在于责任链是一个链条，一件事情可以被责任链里所有节点处理，而策略模式则是只有一个对象来处理。
• 模板方法模式（Template Pattern）
  它使用一个抽象类定义了一个模板，这个模板里定义了一系列的接口，子类则只需继承该抽象类并根据需要重写一部分接口。
  • 使用场景
    • 当多个子类具有共同的操作流程逻辑且其中某些流程节点操作需要自己定制化时。
• 访问者模式

各分类中的模式的关键点

• 创建型模式
  • 单例模式：某个类只能有一个实例，提供一个全局的访问点。
  • 简单工厂：一个工厂类根据传入的参量决定创建出哪一种产品类的实例。
  • 工厂方法：定义一个创建对象的接口，让子类决定实例化那个类。
  • 抽象工厂：创建相关或依赖对象的家族而无需明确指定具体类。
  • 建造者模式：封装一个复杂对象的构建过程并可按步骤构造。
  • 原型模式：通过复制现有的实例来创建新的实例。
• 结构型模式
  • 适配器模式：将一个类的方法接口转换成客户希望的另外一个接口。
  • 组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。
  • 装饰模式：动态地给对象添加新的功能。
  • 代理模式：为其他对象提供一个代理以便控制这个对象的访问。
  • 享元模式：通过共享技术来有效地支持大量细粒度的对象。
  • 外观模式：对外提供一个统一的方法来访问子系统中的一群接口。
  • 桥接模式：将抽象部分和它的实现部分分离，使它们都可以独立地变化。
• 行为型模式
  • 模板模式：定义一个算法结构来将一些步骤延迟到子类实现。
  • 解释器模式：给定一个语言，定义它的文法的一种表示并定义一个解释器。
  • 策略模式：定义一系列算法，把它们封装起来并使它们可以相互替换。
  • 状态模式：允许一个对象在其对象内部状态改变时改变它的行为。
  • 观察者模式：对象间的一对多的依赖关系。
  • 备忘录模式：在不破坏封装的前提下保持对象的内部状态。
  • 中介者模式：用一个中介对象来封装一系列的对象交互。
  • 命令模式：将命令请求封装为一个对象使得可用不同的请求来进行参数化。
  • 访问者模式：在不改变数据结构的前提下增加作用于一组对象元素的新功能。
  • 责任链模式：将请求的发送者和接收者解耦，使得多个对象都有处理这个请求的机会。
  • 迭代器模式：一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。

策略模式与状态模式

虽然状态模式和策略模式拥有相似的结构，它们都基于SOLID设计原则中的O（开闭原则），但它们的意图是完全不同的。

策略模式与简单工厂模式