常用设计模式

设计模式（Design Patterns）是软件工程中一种被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式不是一种工具或产品，而是一种描述在特定环境下，解决一般设计问题的类和相互通信的对象的组织方式。

设计模式主要分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）和行为型模式（Behavioral Patterns）。每种类型下都包含多种具体的设计模式，这些模式在软件开发中被广泛应用，以解决特定的问题或实现特定的功能。以下是对每种类型及其包含的具体设计模式的简要介绍：

一、创建型模式

创建型模式主要用于对象的创建过程，旨在通过某种方式控制对象的创建，以实现对象的创建与使用相分离，增加系统的灵活性和可维护性。

• 1. 单例模式（Singleton Pattern）： 确保一个类只有一个实例，并提供一个全局访问点。适用于需要控制资源访问数量，如数据库连接、线程池等场景。

  • 优点：
    • 节约系统资源，提高系统性能，因为内存中只存在一个实例。
    • 避免对资源的多重占用。
    • 提供全局访问点，优化和共享资源的访问。
  • 缺点：
    • 不易扩展，如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
    • 在并发测试中，不利于代码调试，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
    • 功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

• 2. 工厂方法模式（Factory Method Pattern）： 定义一个用于创建对象的接口，让子类决定实例化哪一个类。将对象的创建延迟到子类进行。

  • 优点：
    • 遵循了开闭原则，扩展性极强。增加新的产品类时，只需增加相应的工厂类即可，不需要修改原有代码。
    • 将对象的创建和使用分离，客户端不需要知道具体的产品类。
  • 缺点：
    • 增加了类的数量，当产品类型较多时，需要定义多个工厂类。

• 3. 抽象工厂模式（Abstract Factory Pattern）： 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。常用于创建一组相互依赖的对象。

  • 优点：
    • 封装性和解耦性，客户端代码不需要关心具体的产品类。
    • 产品族一致性，确保一组相关或依赖的产品能够协同工作。
    • 易于替换和扩展，通过添加新的具体工厂类和产品类，可以轻松扩展系统。
    • 提高系统灵活性，允许在运行时切换不同的具体工厂。
  • 缺点：
    • 复杂性增加，引入了多个抽象类和接口，以及多个具体工厂和产品类。
    • 不易于新增产品，如果需要新增一种产品，需要同时修改抽象工厂接口和所有具体工厂类。
    • 不支持单一产品的变化，如果只有一个产品发生变化，整个工厂都需要进行修改。

• 4. 建造者模式（Builder Pattern）： 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。适用于构建复杂对象的过程需要精细控制的情况。

  • 优点：
    • 封装性好，创建和使用分离。
    • 扩展性好，建造类之间相互独立，在一定程度上解耦。
      缺点：
    • 增加类数量，产生多余的Builder对象。
    • 如果产品内部发生变化，建造者也要相应修改。

• 5. 原型模式（Prototype Pattern）： 用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。适用于创建对象成本较大或需要频繁创建相同或相似对象的情况。

  • 优点：
    • 性能高，使用原型模式复用的方式创建实例对象，比使用构造函数重新创建对象性能要高。
    • 流程简单，可以直接修改现有的对象实例的值，达到复用的目的。
  • 缺点：
    • 实现复杂，需要重写对象的clone方法，并且要注意深拷贝与浅拷贝的风险。

二、结构型模式

结构型模式主要用于处理类或对象的组合关系，以形成更大的结构，使得系统更加灵活和易于管理。

• 1. 适配器模式（Adapter Pattern）： 将一个类的接口转换成客户希望的另一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

  • 优点：
    • 复用且不修改类，提高类的复用性。
    • 降低耦合，目标类和现有类解除耦合，易于扩展维护。
    • 符合开闭原则，用户调用适配器接口，只与适配器类进行交互。
  • 缺点：
    • 增加复杂性，编写适配器类时需要考虑全面。
    • 降低可读性，系统代码可读性降低，可维护性降低。

• 2. 桥接模式（Bridge Pattern）： 将抽象部分与它的实现部分分离，使它们都可以独立地变化。适用于抽象与实现需要独立变化的情况。

  • 优点：
    • 减少耦合，将抽象部分与实现部分分离。
    • 提高系统的可扩展性，抽象部分和实现部分可以独立变化。
  • 缺点：
    • 增加系统的理解与设计难度，需要引入抽象层。

• 3. 装饰器模式（Decorator Pattern）： 动态地给一个对象添加一些额外的职责。就扩展功能而言，它比生成子类方式更为灵活。

  • 优点：
    • 透明性：客户端可以透明地使用装饰后的对象，而不需要知道具体的装饰细节。
    • 灵活性：可以动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式比生成子类更为灵活。
    • 符合开闭原则：通过扩展来适应新的变化，而不是修改。
  • 缺点：
    • 产生过多的小对象：如果过度使用装饰器模式，可能会产生过多的对象实例，影响性能。
    • 增加系统复杂性：理解和使用装饰器模式可能需要一定的学习成本。

• 4. 组合模式（Composite Pattern）： 将对象组合成树形结构以表示“部分-整体”的层次结构。使得客户对单个对象和复合对象的使用具有一致性。

  • 优点：
    • 一致地使用组合结构和单个对象，用户可以忽略组合对象与单个对象的不同。
    • 使得客户端代码可以统一地处理单个对象和组合对象。
  • 缺点：
    • 建含有特定对象的类难以实现，需要设计复杂的类层次结构。

• 5. 外观模式（Facade Pattern）： 为子系统中的一组接口提供一个一致的界面。简化了子系统与客户端之间的交互。

  • 优点：
    • 降低系统复杂性：通过为复杂的子系统提供一个简单的接口，降低了客户端与子系统之间的耦合度。
    • 提高开发效率：客户端只需要与外观对象交互，而不需要了解子系统的内部细节，从而提高了开发效率。
    • 灵活性：可以在不修改客户端代码的情况下，通过修改外观类来添加或删除子系统的功能。
  • 缺点：
    • 不符合开闭原则：如果需要修改子系统的功能，可能需要修改外观类，这可能会违反开闭原则。
    • 隐藏子系统细节：虽然降低了客户端与子系统的耦合度，但也隐藏了子系统的细节，可能会使得系统的维护变得困难。

• 6. 享元模式（Flyweight Pattern）： 运用共享技术有效地支持大量细粒度的对象。适用于对象数量庞大且部分对象可以共享的场景。

  • 优点：

    • 减少内存占用：通过共享对象实例来减少内存占用，提高了系统的性能。
    • 提高复用性：通过共享细粒度对象，提高了对象的复用性。

  • 缺点：

    • 增加复杂度：需要维护一个存储共享实例的容器，增加了系统的复杂度。
    • 线程安全问题：在多线程环境下，需要确保共享对象的状态是线程安全的。

• 7. 代理模式（Proxy Pattern）： 为其他对象提供一种代理以控制对这个对象的访问。常用于实现远程调用、懒加载等功能。

  • 优点：
    • 控制访问：通过代理对象控制对真实对象的访问，可以实现对真实对象的访问控制。
    • 增强功能：可以在代理对象中添加额外的功能，如缓存、日志记录等。
    • 隐藏实现细节：客户端只需要与代理对象交互，而不需要了解真实对象的实现细节。
  • 缺点：
    • 增加性能开销：由于客户端需要通过代理对象来访问真实对象，因此可能会增加一些性能开销。
    • 设计复杂：需要设计代理对象与真实对象之间的交互逻辑，增加了系统的复杂度。

三、行为型模式

行为型模式主要用于描述类或对象之间的交互和职责分配，以实现更加灵活和动态的软件系统。

• 1. 模板方法模式（Template Method Pattern）： 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。允许子类在不改变算法结构的情况下，重新定义算法的某些特定步骤。

  • 优点：
    • 代码复用：在父类中定义一个算法框架，由子类来实现细节处理，实现代码复用。
    • 灵活性：子类可以在不改变算法结构的前提下，重新定义算法的某些特定步骤。
  • 缺点：
    • 设计复杂性：如果父类中可变的基本方法太多，会导致系统更加庞大，增加设计复杂性。
    • 限制子类：子类必须遵循父类定义的算法框架，可能会限制子类的灵活性。

• 2. 命令模式（Command Pattern）： 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化。常用于实现撤销/重做、日志记录等功能。

  • 优点：
    • 降低耦合度：请求者和接收者之间完全解耦，请求者不需要知道接收者的具体实现。
    • 增加灵活性：增加新的具体命令类不会影响其他类，易于扩展。
      支持撤销和重做：可以方便地实现命令的撤销和重做功能。
  • 缺点：
    • 命令类过多：针对每一个请求接收者的调用操作都需要设计一个具体命令类，可能会导致系统中命令类过多。
    • 复杂性：增加了系统的复杂性，需要管理命令对象和接收者之间的映射关系。

• 3. 迭代器模式（Iterator Pattern）： 提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。简化了集合的遍历操作。

  • 优点
    • 分离遍历行为：迭代器模式将集合对象的遍历行为分离出来，由迭代器类负责，这使得集合类更加专注于其存储数据的职责，符合单一职责原则。
    • 简化遍历：通过迭代器，客户端可以透明地访问集合内部的数据，而无需了解集合的内部结构，从而简化了遍历操作。这对于复杂的数据结构（如树、图等）尤为有用。
    • 支持多种遍历方式：迭代器模式允许为集合提供多种遍历方式（如正序、倒序等），只需实现不同的迭代器类即可，无需修改集合类本身。
    • 良好的封装性：迭代器模式封装了遍历算法，使得集合的遍历细节对客户端透明，客户端只需要通过迭代器接口访问集合元素，无需关心遍历的具体实现。
    • 统一接口：为遍历不同的聚合结构提供了一个统一的接口，使得客户端可以以相同的方式遍历不同的集合类型。
    • 提高系统扩展性：当需要为集合添加新的遍历方式时，只需添加新的迭代器类即可，无需修改原有代码，这符合开闭原则（对扩展开放，对修改关闭）。
  • 缺点
    • 类的个数成对增加：由于迭代器模式将存储数据和遍历数据的职责分离，因此每增加一个集合类，通常都需要对应地增加一个迭代器类，这在一定程度上增加了系统的复杂性。
    • 可能不适用于简单遍历：对于简单的遍历操作（如遍历数组或有序列表），使用迭代器模式可能会显得较为繁琐，因为需要创建迭代器对象并调用其方法来遍历集合。在这种情况下，直接使用循环遍历可能更为直接和高效。
    • 性能考虑：虽然迭代器模式在大多数情况下不会引入显著的性能开销，但在某些对性能要求极高的场景下（如实时系统、高频交易系统等），额外的迭代器对象和方法调用可能会成为性能瓶颈。因此，在设计系统时需要权衡迭代器模式带来的便利性和可能的性能开销。

• 4. 观察者模式（Observer Pattern）： 定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。常用于实现事件监听、状态同步等功能。

  • 优点：
    • 降低耦合度：在观察目标和观察者之间建立一个抽象的耦合，降低系统各组件之间的依赖关系。
    • 支持广播通信：当一个对象状态发生变化时，可以自动通知所有依赖的对象。
    • 易于扩展：增加新的观察者时，不需要修改原有系统代码。
  • 缺点：
    • 性能问题：如果观察目标对象有很多直接和间接观察者，通知所有观察者可能会花费很多时间。
    • 循环依赖：如果观察者和观察目标之间存在循环依赖，会导致循环调用，可能导致系统崩溃。

• 5. 中介者模式（Mediator Pattern）： 用一个中介对象来封装一系列的对象交互。减少了对象之间的直接依赖，使得系统更加灵活和易于维护。

  • 优点
    • 降低耦合度：中介者模式通过引入中介者对象，将原本多个对象之间的相互依赖关系转变为它们与中介者对象之间的依赖关系，从而降低了系统各对象之间的耦合度。
    • 提高可维护性：由于中介者封装了对象之间的交互细节，当交互逻辑发生变化时，只需要修改中介者对象即可，而不需要修改每个对象，这提高了系统的可维护性。
    • 易于扩展：当系统需要增加新的对象或新的交互行为时，只需要增加新的中介者子类或修改中介者对象即可，而不需要修改现有的对象，这使得系统更加易于扩展。
    • 集中控制交互：中介者模式允许将多个对象的交互逻辑集中在一个中介者对象中处理，这使得交互逻辑更加清晰，也便于管理和维护。
  • 缺点
    • 中介者对象可能过于复杂：如果系统中对象之间的交互非常频繁和复杂，那么中介者对象可能会变得非常庞大和复杂，这会增加系统的复杂性和维护难度。
    • 增加中介者类：对于每一个新的系统或子系统，可能需要定义一个新的中介者类，这在一定程度上增加了类的数量，也增加了系统的复杂度。
    • 可能产生中介者依赖：虽然中介者模式降低了对象之间的直接依赖，但对象对中介者产生了新的依赖。如果中介者对象出现问题，可能会影响到多个对象的正常工作。
    • 不易于调试：由于对象之间的交互都通过中介者进行，因此在调试时可能需要跟踪中介者对象的状态和行为，这可能会增加调试的难度。

• 6. 备忘录模式（Memento Pattern）： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。以便以后可以将该对象恢复到保存的状态。

  • 优点
    • 封装性：备忘录模式可以把复杂的发起人内部信息对其他的对象屏蔽起来，从而可以恰当地保持封装的边界。
    • 简化发起人：发起人不再需要管理和保存其内部状态的一个个版本，客户端可以自行管理他们所需的这些状态的版本。
    • 状态恢复：当发起人角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。
  • 缺点
    • 资源消耗：如果发起人角色的状态需要完整地存储到备忘录对象中，那么在资源消耗上面备忘录对象会很昂贵。
    • 存储空间未知：当负责人角色将一个备忘录存储起来的时候，负责人可能并不知道这个状态会占用多大的存储空间，从而无法提醒用户一个操作是否很昂贵。
    • 状态协议问题：当发起人角色的状态改变的时候，有可能这个协议无效。如果状态改变的成功率不高的话，不如采取其他模式。

• 7. 解释器模式（Interpreter Pattern）： 给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。常用于实现编程语言解释器、规则引擎等功能。

  • 优点
    扩展性：语法由很多类表示，容易改变及扩展“语言”。
    灵活性：易于实现文法或简单语言的解释执行，并易于在解释执行器中增加新的解释表达式。
  • 缺点
    复杂性：如果语法规则数目太多，会增加系统复杂度。
    类数量多：每个规则都要与之对应一个类，如果规则太多，则需要创建很多类。
    使用频率低：解释器模式在实际业务中，是使用频率很低的设计模式。

• 8. 状态模式（State Pattern）： 允许一个对象在其内部状态改变时改变它的行为。使得对象的行为与其状态紧密相关。

  • 优点：
    • 封装状态转换：封装了状态的转换规则，可以对状态转换代码进行集中管理。
    • 行为随状态变化：允许一个对象在其内部状态改变时改变它的行为。
  • 缺点：
    增加类和对象：使用状态模式会增加系统中类和对象的数量，导致系统运行开销增大。
    复杂性：状态模式的结构和实现都较为复杂，如果使用不当可能导致程序结构和代码的混乱。

• 9. 策略模式（Strategy Pattern）： 定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。使得算法的变化独立于使用算法的客户。

  • 优点：

    • 扩展性提高：可以灵活地扩展行为，而不会违背开闭原则（对扩展开放，对修改关闭）。
    • 算法可互换：策略可互相替换，避免了使用多重条件选择语句。
    • 提高保密性和安全性：如果不希望客户端知道复杂的、与算法相关的数据结构，可以在具体策略类中封装算法与相关的数据结构，提高算法的保密性与安全性。

  • 缺点：

    • 策略类过多：任何微小的变化都可能增加一个新的策略类，导致系统中策略类过多。
    • 客户端限制：客户端每次只能使用一个策略类，不支持同时使用多个策略类完成复杂功能。
    • 算法选择：客户端必须知道所有的策略类，并自行决定使用哪一个，这要求客户端理解不同算法的区别。

• 10. 职责链模式（Chain of Responsibility Pattern）： 为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

  • 优点：
    • 降低耦合度：对象不需要知道是哪一个对象处理它的请求，只需要知道请求会被处理。
    • 增加灵活性：可以动态地改变处理请求的链中的对象。
  • 缺点：
    • 请求可能不被处理：如果请求没有明确的接收者，或者职责链建立不合理，请求可能不会被处理。
    • 性能问题：对于较长的职责链，可能涉及到多个处理对象，影响系统性能。
    • 循环调用：如果职责链建立不合理，可能会造成循环调用，导致系统陷入死循环。

• 11. 访问者模式（Visitor Pattern）： 表示一个作用于某对象结构中的各元素的操作。它可以在不改变各元素的类的前提下

  • 优点
    • 扩展性好：方便添加新的访问者，增加新的操作就意味着增加一个新的访问者类。
    • 复用性好：可以通过访问者来定义整个对象结构通用的功能，从而提高系统的复用程度。
    • 灵活性好：访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可相对自由地演化而不影响系统的数据结构。
    • 符合单一职责原则：访问者模式把相关的行为封装在一起，构成一个访问者，使每一个访问者的功能都比较单一。
  • 缺点
    • 破坏封装：访问者模式中具体元素对访问者公布细节，这破坏了对象的封装性。
    • 违反依赖倒置原则：访问者模式依赖了具体类，而没有依赖抽象类。
    • 具体访问者元素变更困难：在访问者模式中，如果具体元素类需要变更，可能会影响到所有的访问者类，因为访问者类是通过接受一个具体元素作为参数来对其进行操作的。