设计模式的分类与功能

根据目的来分

根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。

  1. 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
  2. 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。

  3. 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

    根据作用范围来分

    根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。

  4. 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。

  5. 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。 | 范围\目的 | 创建型模式 | 结构型模式 | 行为型模式 | | —- | —- | —- | —- | | 类模式 | 工厂方法 | (类）适配器 | 模板方法、解释器 | | 对象模式 | 单例、 原型、 抽象工厂 、建造者 | 代理 (对象）、适配器、 桥接、 装饰、 外观、 享元、 组合 | 策略、 命令、 职责链、 状态、 观察者、 中介者、 迭代器、 访问者、 备忘录 |

原则

总的原则目标是开闭原则;其他原则都是围绕它展开、或者是实现手段；
其中分复用、独立；
扩展（复用）：里氏替换、组合/聚合原则、依赖倒置
关闭（独立高内聚、低耦合）：单一职责、接口隔离、迪米特原则

开闭原则

当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。 对内修改关闭，对外扩展功能开放； 通过“抽象约束，封装变化”实现；

作用

  1. 对软件测试的影响

软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。

  1. 可以提高代码的可复用性

粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。

  1. 可以提高软件的可维护性

遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

里氏替换

里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。 子类可以扩展父类的功能，但不能改变父类原有的功能。

作用

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

    组合/聚合复用原则

    又称组合/聚合复用原则； 它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

继承

  1. 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
  2. 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。

  3. 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

    组合聚合

  4. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。

  5. 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
  6. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

    依赖倒置

    高层模块不应该依赖低层模块，两者都应该依赖其抽象； 抽象不应该依赖细节，细节应该依赖抽象; 依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。

控制反转

这里的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架。

依赖注入（DI）

不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。

作用

  1. 可以降低类间的耦合性。
  2. 可以提高系统的稳定性。
  3. 可以减少并行开发引起的风险。
  4. 可以提高代码的可读性和可维护性。

    单一职责

    职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分; 对象不应该承担太多职责，如果一个对象承担了太多的职责;

作用

  1. 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
  2. 提高类的可读性。复杂性降低，自然其可读性会提高。
  3. 提高系统的可维护性。可读性提高，那自然更容易维护了。
  4. 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

    接口隔离

    要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

作用

  1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
  2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
  3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
  4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
  5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代

    迪米特原则

    又称最少知识原则；如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。 其目的是降低类之间的耦合度，提高模块的相对独立性。

作用

  1. 降低了类之间的耦合度，提高了模块的相对独立性。
  2. 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。

总结

创建型（5种）

它的主要特点是“将对象的创建与使用分离”。根据定义可分

  1. 原型模式、建造者模式:使用对象
  2. 工厂模式、抽象工厂: 使用接口定义
  3. 单例模式:创建单个实例
  4. 建造模式

    结构型（7种）

    何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。 由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。

它的主要特点是。根据定义可分

  • 针对对象｜类操作，职责、功能、复用
    • 代理（Proxy）模式：从而限制、增强或修改
    • 装饰（Decorator）模式(传入需要装饰的对象)：动态增加功能｜职责
    • 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用
  • 统一访问对象
    • 适配器（Adapter）模式：使得原本由于接口不兼容而不能一起工作的那些类能一起工作
    • 外观（Facade）模：为多个复杂的子系统提供一个一致的接口
    • 组合（Composite）模式：对象组合成树状层次结构；用户对单个对象和组合对象具有一致
  • 抽象与实现
    • 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化

      行为型(11种)

      用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。

它的主要特点是。根据定义可分

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

      从封装变化角度对设计模式的分类

      组件协作

      “框架与应用程序划分”，组合协作是通过晚绑定，来实现框架与应用之间的松耦合

  1. 模版方法
  2. 策略模式

  3. 观察者模式

    单一职责

    如果职责划分的不清晰，使用继承得到的结果往往是随着需求变化，子类急剧膨胀，同时充次着重复代码，这个时候需要划清职责

  4. 装饰模式

  5. 桥模式

    对象创建

    通过“对象创建”绕开new，来避免对象（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。

  6. 工厂模式

  7. 抽象工厂模式
  8. 原型模式

  9. 建造模式

    对象性能

    面向对象很好解决了“抽象”问题，但会需要付出一定的代价，通常情况下可以，忽略不急，但在某些情况下，面向对象所带来的成本是必须谨慎处理。

  10. 单例模式

  11. 享元模式

    接口隔离

    在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题，甚至根本无法实现。 采用添加一层间接接口，来隔离本来紧密关联的接口，是常见的解决方案。

  12. 门面模式

  13. 代理模式
  14. 适配器模式

  15. 中介模式

    状态变化

    在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时有维持高层模块的稳定？“状态变化”为这一类问题，提供解决方案。

  16. 状态模式

  17. 备忘模式

    行为变化

    组件构建过程中，组件行为的变化经常导致组件本身剧烈的变化，“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦变化。

  18. 命令模式

  19. 访问器模式

    数据结构

    有些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大破坏组件的复用性。这个时候，将这特定数据结构封装在内部，在外部提供统一接口，来实现与特定数据结构无关的访问，是一种解决方案。

  20. 组合模式

  21. 迭代模式

  22. 职责模式

    领域问题

    在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。在这个时候，结合特定领域，将问题抽象为语法规则，从而出该领域下的一般解决方案。

  23. 解析器模式

    重构关键技巧

  24. 静态到动态

  25. 早绑定到晚绑定
  26. 继承到组合
  27. 编译依赖到运行依赖
  28. 紧耦合到松耦合

    思考

    从以上设计模式；可以看出都是对类、函数的使用方式；
    总的来看，一个函数可以传参数，也可以在函数体中包含其他函数的调用；
    两个函数可以相互引用，互相调用，并且设置属性值 ；
    https://refactoringguru.cn/design-patterns/catalog

https://www.itjc8.com/forum.php?mod=viewthread&tid=3258&highlight=%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F