设计模式

23 个设计模式

课程：https://b23.tv/Mxr9b6

课件：https://github.com/rhyspang/CPP-Design-Patterns

Android源码设计模式分析开源项目

Java 23种设计模式全归纳

23 个设计模式一、设计模式简介1.1如何解决复杂性1.1.1 分解1.1.2 抽象二、面对对象方法设计原则2.1 重新认识面对对象2.1.1 理解隔离变化2.1.2 各司其职2.2 面对对象原则2.2.1 依赖倒置原则（DIP）2.2.2 开放封闭原则（OCP）2.2.3 单一职责原则（SRP）2.2.4 里氏替换原则2.2.5 接口隔离原则2.2.6 优先使用对象组合，而不是类继承2.2.7 封装变化点2.2.8 针对接口编程，而不是针对实现编程2.3 重构设计模式2.4 从封装变化角度对模式分类2.4.1 “组件协作”模式：三、模板方法3.1 动机3.2 早绑定与晚绑定3.3 模式定义3.4 结构四、策略模式4.1 动机4.2 模式定义4.3 结构五、观察者模式5.1 动机5.2 模式定义5.3 结构5.4 要点总结六、装饰模式6.1 动机6.2 模式定义6.3 结构6.4 要点总结

一、设计模式简介

1.1如何解决复杂性

1.1.1 分解

人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。

1.1.2 抽象

更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。

个人理解分解即面向过程，抽象即面向对象

二、面对对象方法设计原则

2.1 重新认识面对对象

2.1.1 理解隔离变化

从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小

2.1.2 各司其职

1. 从微观层面来看，面向对象的方式更强调各个类的“责任”

2. 由于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责

2.2 面对对象原则

2.2.1 依赖倒置原则（DIP）

1. 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) 。

2. 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。

以上两点会在后续的各个设计模式中具体说明。

2.2.2 开放封闭原则（OCP）

1. 对扩展开放，对更改封闭。

2. 类模块应该是可扩展的，但是不可修改。

2.2.3 单一职责原则（SRP）

1. 一个类应该仅有一个引起它变化的原因。

2. 变化的方向隐含着类的责任。

2.2.4 里氏替换原则

1. 子类必须能够替换它们的基类(IS-A)。

2. 继承表达类型抽象。

2.2.5 接口隔离原则

1. 不应该强迫客户程序依赖它们不用的方法。

2. 接口应该小而完备。

2.2.6 优先使用对象组合，而不是类继承

1. 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。

2. 继承在某种程度上破坏了封装性，子类父类耦合度高。

3. 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

2.2.7 封装变化点

1. 使用封装来创建对象之间的分界层，让设计者可以在分界层的

   一侧进行修改，而不会对另一侧产生不良的影响，从而实现层

   次间的松耦合。

2.2.8 针对接口编程，而不是针对实现编程

1. 不将变量类型声明为某个特定的具体类，而是声明为某个接口。

2. 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。

3. 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。

2.3 重构设计模式

1. 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指是那些可以满足 “应对变化，提高复用”的设计 。

2. 现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。

3. 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计 模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

2.4 从封装变化角度对模式分类

2.4.1 “组件协作”模式：

• 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。

• 典型模式

  • Template Method

  • Observer / Event

  • Strategy

三、模板方法

3.1 动机

在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。

3.2 早绑定与晚绑定

image.png

早绑定是指不应由程序（Application）调用库（Library）中函数，而应该是库调用程序中变化的部分

3.3 模式定义

定义一个操作中的算法的骨架 (稳定)，而将一些步骤延迟(变化)到子类中。Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(override 重写)该算法的某些特定步骤。

个人理解有点像接口回调，比如点击事件的回调

3.4 结构

image.png

四、策略模式

4.1 动机

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。

4.2 模式定义

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。

4.3 结构

image.png

红色代表稳定，蓝色代表变化

五、观察者模式

5.1 动机

在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。

5.2 模式定义

定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

5.3 结构

image.png

5.4 要点总结

1. 使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。

2. 目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。

3. 观察者自己决定是否需要订阅通知，目标对象对此一无所知。

4. Observer模式是基于事件的UI框架中非常常用的设计模式，也是 MVC 模式的一个重要组成部分。

六、装饰模式

6.1 动机

在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。

6.2 模式定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）。

6.3 结构

image.png

6.4 要点总结

• 通过采用组合而非继承的手法， Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。

• Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-aComponent的组合关系，即Decorator类又使用了另外一个Component类。

• Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

七、桥模式

7.1 动机

由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。

7.1 模式定义

将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。

7.3 结构

image.png

7.4 总结

• Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
• Bridge模式有时候类似于多继承方案，但是多继承方案往往违背 单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
• Bridge模式的应用一般在“两个非常强的变化维度”，有时一个 类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

八、Factory Method 工厂方法

8.1 动机

• 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。
• 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？

8.2 模式定义

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。

8.3 结构

image.png

8.4 要点总结

• Factory Method模式用于隔离类对象的使用者和具体类型之间的 耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导 致软件的脆弱。
• Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
• Factory Method模式解决“单个对象”的需求变化。缺点在于要 求创建方法/参数相同。

九、Abstract Factory 抽象工厂

9.1 动机

在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。

如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？

9.2 模式定义

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

9.3 结构

image.png

9.4 总结

• 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。
• “系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
• Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

“新对象”的需求变动 在本例中指的是 IDBFactory 中新增一个创建对象的方法

十、Builder 模式

10.1 动机

• 在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。

• 如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

10.2 模式定义

将一个复杂对象的构建与其表示相分离，使得同样的构建过程(稳定)可以创建不同的表示(变化)。

10.3 结构

Builder 结构

10.4 要点总结

• Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。

• 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。

• 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别

十一、Singleton 单例模式

11.1 动机

在软件系统中，经常有这样的一些特殊类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性，以及良好的效率

11.2 模式定义

保证一个类仅有一个实例，并提供一个改实例的全局访问点

11.3 结构

Singleton 模式

11.4 要点总结

• Singleton 模式中的实例构造器可以设置为 protected 以允许子类派生

• Singleton 模式一般不要支持拷贝构造函数和 Clone 接口，因为这有可能导致多个对象实例，与 Singleton 模式的初衷违背

• 如果实现多线程环境下安全的 Singleton？注意对双检查锁的正确实现

十二、Flyweight 享元模式

12.1 动机

• 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价

• 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面对对象的方式进行操作

12.2 模式定义

运用共享技术有效地支持大量细粒度的对象

12.3 结构

Flyweight 模式

12.4 要点总结

• 面对对象很好的解决了抽象的问题，但是作为一个运行在机器中的程序实体，我们要考虑对象的代价问题，Flyweight 主要解决面对对象的代价问题，一般不触及面对对象的抽象性问题

• Flyweight 采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力，在具体实现方面，要注意对象状态的处理

• 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？我们要根据具体应用情况进行评估，而不能凭空臆断

十二、Facade 门面模式

系统间耦合的复杂度

Facade

12.1 动机

• 上述 A 方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战

• 如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化的依赖相互解耦？

12.2 模式定义

为子系统中的一组接口提供一个一致（稳定）的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）

12.3 结构

常见的比如数据库的访问，程序和数据库之前有了一个稳定的连接池，不管数据库之间怎么关联甚至从 oracle 换成了 mysql，都不影响程序

Facade 结构

12.4 要点总结

• 从客户程序的角度来看，Facade 模式简化了整个组件系统的接口，对于组件内部和外部客户程序来说，达到了一种“解耦”的效果——内部子系统的任何变化不会影响到 Facade 接口变化
• Facadde 设计模式更注重从架构的层次去看整个系统，而不是单个类的层次，Facade 很多时候更多是一种架构设计模式
• Facade 设计模式并发一个集装箱，可以任意的放进任何多个对象。Facade 模式中组件内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合

十三、Proxy 代理模式

13.1 动机

• 在面对对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦

• 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式

13.2 模式定义

为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问

13.3 结构

由于某些特殊的原因，不能直接访问 RealSubject，需要通过 Proxy 对象

Proxy 结构

13.4 要点总结

• “增加一层间接层” 是软件系统中对许多复杂问题的一种常见解决方法。在面对对象系统中，直接使用某些对象会带来很多问题，作为间接层的 proxy 对象便是解决这一问题的常用手段

• 具体 proxy 设计模式的实现方法，实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如 copy-on-write 技术，有些可能对组件模块提供抽象代理层，在架构层次对对象做 proxy

• Proxy 并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性也是可以接受的。

十四、适配器模式

14.1 动机

• 在软件系统中，由于应用环境的变化，常常需要将”一些现存的对象“放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。

• 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，又能满足新的应用环境所要求的接口？

14.2 模式定义

将一个类的接口转化成客户希望的另一个接口，Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

14.3 结构

在 Adapter 类中，将要实现 Target 接口，并在实现方法中利用 adaptee 成员变量调用 Adaptee 的方法，以适配 Target 接口方法的定义

Adapter

14.4 要点总结

• Adapter 模式主要应用于“希望复用一些现存的类，但接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用

• 一般有两种 Adpter 模式的实现结构，对象适配器和类适配器。但类适配器采用“多继承的实现方式”，一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神

本例采用的是对象适配器，在本例中，如果采用类适配器，那么 Adapter 将要同时实现 ITarget 并继承 OldClass；对象适配器的话，只需要实现 ITarget 接口，并定义一个 IAdaptee 成员变量

• Adapter 模式可以实现的非常灵活，不必拘泥于定义中的结构。例如，完全可以将 Adapter 模式中的“现存现象”作为新的接口方法参数，来达到适配的目前

十五、Mediator 中介者模式

15.1 动机

• 在软件构建过程中，经常出现多个对象相互关联交互的情况，对象之前常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化

比如在一个控件点击的时候，需要更新一些数据，同时更新了数据的时候，又希望反过来更新界面，那么两者之间就存在以下交叉关联的情况

• 在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互的对象之前的紧耦合引用关系，从而更改的抵御变化

15.2 模式定义

用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各个对象不需要显式的相互引用依赖（编译依赖->运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互

比如下图左边的各个模块都相互依赖，中介者模式改写后就是右图的形式，它和代理模式主要的区别是：代理模式是不同系统间，中介者模式是系统内部调用

关系图

15.3 结构

Colleague 内部有个指针指向了 Mediator，而 ConcreateMediator 内部又有指针指向了具体的 Colleague，最核心的是本来 ConcreateColleague1 和 ConcreateColleague2 之间应该有依赖，但现在是没有依赖的

Mediator

15.4 要点总结

• 将多个对象间复杂的关联关系解耦, Mediator模式将多个对象间的控制逻辑进行集中管理,变“多个对象互相关联”为“多个对象和一个中介者关联”, 简化了系统的维护，抵御了可能的变化。

• 随着控制逻辑的复杂化, Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。

• Facade模式是解耦系统间(单向)的对象关联关系; Mediator模式是解耦系统内各个对象之间(双向)的关联关系。

十六、State 状态模式

16.1 动机

在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。

如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?

16.2 模式定义

允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

16.3 结构

state

16.4 要点总结

• State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中,在对象状态切换时,切换相应的对象;但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。

• 为不同的状态引入不同的对象使得状态转换变得更加明确,而且可以保证不会出现状态不一致的情况，因为转换是原子性的一即要么彻底转换过来,要么不转换。

• 如果State对象没有实例变量,那么各个上下文可以共享同一个State对象,从而节省对象开销。

十六、Memetno 备忘录模式

16.1 动机

• 在软件构建过程中,某些对象的状态在转换过程中，可能由于某种需要,要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态, 便会暴露对象的细节实现。

• 如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏
  对象本身的封装性。

16.2 模式定义

在不破坏封装性的前提下,捕获- -个对象的内部状态,并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。

16.3 结构

Memetno

16.4 要点总结

• 备忘录( Memento )存储原发器( Originator )对象的内部状态,在需要时恢复原发器状态。

• Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将状态保持到外界( Memento )。

• 由于现代语言运行时(如C#、Java等 )都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现Memento模式。

十七、Composite 组合模式

17.1 动机

• 在软件在某些情况下,客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化,带来了代码的维护性、扩展性等弊端。

• 如何将"客户代码与复杂的对象容器结构”解耦?让对象容器自己来实现自身的复杂结构,从而使得客户代码就像处理简单对象一样来处理复杂的对象容器?

17.2 模式定义

将对象组合成树形结构以表示“部分整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性(稳定)。

17.3 结构

Composite

17.4 要点总结

• Composite模式采用树形结构来实现普遍存在的对象容器,从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地(复用)处理对象和对象容器,无需关心处理的是单个的对象，还是组合的对象容器。

从而将“一对多”的关系转化为“一对一”的关系，这句话的意思是如果不利于多态，那么外部程序在处理的时候就要判断是否是叶子节点，还是根节点，就会出现一对多的关系，利用了多态，那么就没有这个问题

• 将"客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接抠，-而非对象容器的内部实现结构二发生依赖 ,从而更能“应对变化”

• Composite模式在具体实现中，可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

十八、迭代器模式

18.1 动机

• 在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种" 透明遍历”也为“同一种算法在多种集合对象上进行操作"提供了可能。

• 使用面向对象技术将这种遍历机制抽象为"迭代器对象” 为"应对变化中的集合对象”提供了-种优雅的方式。

18.2 模式定义

提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露(稳定)该对象的内部表示。

18.3 结构

Iterator

18.4 要点总结

• 迭代抽象:访问- -个聚合对象的内容而无需暴露它的内部表示。

• 迭代多态:为遍历不同的集合结构提供一个统一-的接口 ,从而支持同样的算法在不同的集合结构上进行操作。

• 迭代器的健壮性考虑:遍历的同时更改迭代器所在的集合结构,会导致问题。

十九、职责链

19.1 动机

• 在软件构建过程中, -个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显式指定,将必不可少地带来请求发送者与接受者的紧耦合。

• 如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。

19.2 模式定义

使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。

19.3 结构

Chain of Responsibility

19.4 要点总结

• Chain of Responsibility模式的应用场合在于"一个请求可能有，多个接受者,但是最后真正的接受者只有一个”, 这时候请求发送者与接受者的耦合有可能出现”变化脆弱”的症状,职责链的目的就是将二者解耦,从而更好地应对变化。

• 应用了Chain of Responsibility模式后,对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。

• 如果请求传递到职责链的末尾仍得不到处理,应该有一个合理的，缺省机制。这也是每个接受对象的责任 ,而不是发出请 求的对象的责任。

二十、命令模式

20.1 动机

• 在软件构建过程中，“行为请求者” 与“行为实现者”通常呈现一种“紧耦合”。但在某些场合一比如需要对行为进行 “记录、撤销/重(undo/redo)、事务”等处理，这种无法抵御变化的紧耦合是不合适的。

• 在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象，可以实现二者之间的松耦合。

20.2 模式定义

将一个请求(行为)封装为一一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。

20.3 结构

Command

20.4 要点总结

• Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦,在面向对象语言中,常见的实现手段是“将行为抽象为对象”。

• 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可
  能会保存一-些额外的状态信息。 通过使用Composite模式,可以将多个“命令”封装为一个"复合命令" MacroCommand.

• Command模式与C+ +中的函数对象有些类似。但两者定义行为接口的规范有所区别: Command以面向对象中的“ 接口-实现”来定义行为接口规范，更严格,但有性能损失; C+ +函数对象以函数签名来定义行为接口规范，更灵活，性能更高。

二十一、访问器

21.1 动机

• 在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法) , 如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担，甚至破坏原有设计。

• 如何在不更改类层次结构的前提下，在运行时根据需 要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题?

21.2模式定义

表示一个作用于某对象结构中的各元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这.些元素的新操作(变化)。

21.3 结构

Visitor 最大的缺点是要求 Element 的子类稳定，因为要保证 Visitor 中的函数稳定

Visitor

21.4 要点总结

• Visitor 模式通过所谓的双重分发(double dispatch)来实现在不更改，(不添加新的操作-编译时)Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作(支持变化)

• 所谓的双重分发即Visitor模式中间包括了两个多态分发(注意其中的态机制机制)：第一个为accept方法的多态辨析;第二个为visitElementX方法的多态辨析。

• Visitor 模式最大的缺点在于扩展类层次结构（添加行的 Element 子类），会导致 Visitor 类的改变，因此 Vistior 适用于** Element 类层次结构稳定，而其中的操作经常面临频发改动**

二十二、解析器

22.1 动机

• 在软件构建过程中,如果某一特定领域的问题比较复杂 ,类似的结构不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。

• 在这种情况下,将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子 ,从而达到解决问题的目的。

比如a+b-c+d可以表示为下图中树形结构，a、b 是一个变量表达式，a、b 的结果有可以构成一个新的变量表达式

image.png

22.2 模式定义

给定一个语言, 定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。

22.3 结构

Interpreter

22.4 要点总结

• Interpreter模式的应用场合是Interpreter模式应用中的难点,只有满足.“业务规则频繁变化,且类似的结构不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。

• 使用Interpreter模式来表示文法规则,从而可以使用面向对象技巧来方便地“扩展”文法。

• Interpreter模式比较适合简单的文法表示,对于复杂的文法表示，Interperter模式会产生比较大的类层次结构,需要求助于语法分析生成器这样的标准工具。

二十三、总结

23.1 一个目标

管理变化、提高复用

23.2 两种手段

分解 vs 抽象

23.3 八大原则

• 依赖倒置原则( DIP )
• 开放封闭原则( OCP )
• 单一职责原则( SRP )
• Liskov替换原则( LSP )
• 接口隔离原则( ISP )
• 对象组合优于类继承
• 封装变化点
• 面向接口编程

23.4 重构技巧

• 静态→动态
• 早绑定→晚绑定
• 继承→组合
• 编译时依赖→运行时依赖
• 紧耦合→松耦合

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

分类

23.6 c++ 对象模型

所有的设计模式，都会演化为第三种，以组合的形式呈现

对象模型

23.7 什么时候不用设计模式

• 代码可读性很差时
• 需求理解还很浅时
• 变化没有显现时
• 不是系统的关键依赖点
• 项目没有复用价值时
• 项目将要发布时

23.8 经验之谈

• 不要为模式而模式
• 关注抽象类&接口
• 理清变化点和稳定点
• 审视依赖关系
• 要有Framework和Application的区隔思维
• 良好的设计是演化的结果