详解23种设计模式

在了解设计模式之前首先应该先立靶,即何为优秀的设计

面向对象

对象: 属性(数据) + 方法(操作) + 对象ID

封装: 隐藏对象的属性和实现细节,仅对外公开接口(信息隐藏技术)

类(实体类/控制类/边界类)

• 实体类的对象表示现实世界中真实的实体，如人、物等。
• 接口类（边界类）的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其
  中人的接口可以是显示屏、窗口、Web窗体、对话框、菜单、列表框、其他显示控制、条
  形码、二维码或者用户与系统交互的其他方法。系統接口涉及到把数据发送到其他系统，或
  者从其他系统接收数据。
• 控制类的对象用来控制活动流，充当协调者。

接口: 一种特殊的类,他只有方法定义而没有实现

在面向对象的系统中，对象是运行时实体，其组成部分不包括（A）；一个类定义了一组大体相似的对象，这些对象共享（D）
A. 消息 B. 行为（操作） C. 对象名 D. 状态
A. 属性和状态 B. 对象名和状态
C. 行为和多重度 D. 属性和行为 ✅:最合适

在面向对象方法中，将逻辑上相关的数据以及行为绑定在一起，使信息对使用者隐蔽称为（C）。当类中的属性或方法被设计为private时，（B）可以对其进行访问。
A. 抽象 B. 继承 C. 封装 D. 多态
A. 应用程序中所有方法 B. 只有此类中定义的方法
C. 只有此类中定义的public方法 D. 同一个包中的类中定义的方法

在某销售系统中，客户采用扫描二维码进行支付。若采用面向对象方法开
发该销售系统，则客户类属于（B）类，二维码类属于（A）类。
A. 接口 B. 实体 C. 控制 D. 状态
A. 接口 B. 实体 C. 控制 D. 状态

继承与泛化

本质是一种复用机制

泛化: 找出共通点,抽象出父类

• 继承是子类 =继承(特殊化)=> 父类
• 泛化是子类 =泛化出=> 父类

在面向对象方法中，（B）是父类和子类之间共享数据和方法的机制。子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现称为（C）。
A. 封装 B. 继承 C. 覆盖 D. 多态
A. 封裝 B. 继承 C. 覆盖 D. 多态

在面向对象方法中，继承用于（A）。
A. 在已存在的类的基础上创建新类
B. 在已存在的类中添加新的方法
C. 在已存在的类中添加新的属性
D. 在已存在的状态中添加新的状态

多态与动态绑定

多态: 不同对象收到同样的消息(过程调用)产生不同的结果

过载多态: 同一个名字在不同的上下文中所代表的含义不同 (只考到这种多态)

其他多态可以参考一下:

• 参数多态：应用广泛、最纯的多态。
• 包含多态：同样的操作可用于一个类型及其子类型。包含多态一般需要进行运行时的类型检查
• 强制多态：编译程序通过语义操作，把操作对象的类型强行加以变换，以符合函数或操作符的要求
• 过载多态：同一个名（操作符、函数名）在不同的上下文中有所代表的含义不同

动态绑定: 根据接收对象的具体情况将请求的 操作与实现的方法进行连接(运行时绑定)

消息和消息通信: 对象之间进行通信的一种构造叫做消息,消息是异步通信的(消息传递: 接收到消息的对象经过解释,然后予以响应)

考察较多

在面向对象方法中，不同对象收到同一消息可以产生完全不同的结果，这一现象称为（D）。在使用时，用户可以发送一个通用的消息，而实现的细节则由接收对象自行决定。
A. 接口 B. 继承 C. 覆盖 D. 多态

在下列机制中，（D）是指过程调用和响应调用所需执行的代码在运行时加
以结合；而（C）是过程调用和响应调用所需执行的代码在编译时加以结合。
A. 消息传递 B. 类型检查 C. 静态绑定 D. 动态绑定
A. 消息传递 B. 类型检查 C. 静态绑定 D. 动态绑定

（C）多态是指操作（方法）具有相同的名称、且在不同的上下文中所代表的含义不同。
A参数 B包含 C过载 D 强制

面向对象流程

只需了解

1. 面向对象分析
2. 面向对象设计
3. 面向对象程序设计
4. 面向对象测试

面向对象分析

• 认定对象(名词)
• 组织对象(抽象成类)
• 对象间的相互作用
• 基于对象的操作

面向对象分析的目的是为了获得对应用问题的理解，其主要活动不包括（C）。
A. 认定并组织对象 B. 描述对象间的相互作用
C. 面向对象程序设计 D. 确定基于对象的操作

面向对象设计

• 识别类及对象
• 定义属性
• 定义服务
• 识别关系
• 识别包

面向对象设计原则

面向对象程序设计

• 程序设计范式
• 选择一种OOPL

面向对象测试

• 算法层
• 类层
• 模板层
• 系统层

面向对象设计原则

[[开发项目管理#模块设计原则|模块设计原则]]: 高内聚低耦合

下面是面向对象设计中的重要原则，通常统称为“SOLID”原则。它们用于指导软件设计，以提高代码的可维护性、可扩展性和灵活性

面向对象七大原则

1. 单一职责原则（Single Responsibility Principle）：设计目的单一的类

2. 开放-封闭原则（Open-Closed Principle）：软件实体（类、模块、函数等）应该对扩展开放对修改关闭，可以通过扩展已有的代码来实现新功能，而不是修改已有的代码。

3. 里氏替换原则（Liskov Substitution Principle）：子类必须能够替换其父类而不影响程序的正确性，即子类应该能够完全替代父类。

4. 依赖倒置原则（Dependency Inversion Principle）：高层模块不应该依赖于低层模块，二者都应该依赖于抽象.

   模块间的依赖关系应该通过接口或抽象类来建立，而不是直接依赖于具体的实现类。这样可以降低模块间的耦合度，提高代码的灵活性和可维护性

5. 接口隔离原则（Interface Segregation Principle）：客户端不应该强制依赖它不需要的接口，应该将大接口拆分成多个小接口。 使用多个专门的接口比使用单一的总接口要好

6. 组合重用原则（Composition Reuse Principle）: 要尽量使用组合,而不是继承关系达到重用目的

7. 迪米特法则（Law of Demeter）：一个对象应该对其他对象有最少的了解，即一个对象应该尽可能少地与其他对象发生相互作用。 这些原则可以帮助设计出符合面向对象设计原则的软件系统，提高系统的灵活性、可维护性和可扩展性。

[[架构相关#软件开发设计哲学|完整可以参考软件开发设计哲学]]

进行面向对象设计时，就一个类而言，应该仅有一个引起它变化的原因，这属于（A） 设计原则。
A. 单一责任 B. 开放-封闭 C. 接口分离 D. 里氏替换

面向对象其他原则

• 重用发布等价原则（Reuse-Release Equivalence Principle）: 重用的粒度就是发布的粒度

  • 重用粒度：指的是在软件开发中，开发者将代码或功能模块进行重用的程度。粒度可以是细粒度（如单个函数、类）或粗粒度（如整个模块、库）。
  • 发布粒度：指的是将软件组件或模块发布到生产环境的单位。发布粒度同样可以是细粒度或粗粒度。

• 共同封闭原则（Common Closure Principle，简称 CCP）: 包中的所有类对于同一性质的变化应该是共同封闭的.一个变化若对一个包产生影响,则将对该包里的所有类产生影响,而对于其他的包不造成任何影响

• 共同重用原则（Common Reuse Principle，简称 CRP）: 一个包里的所有类应该是共同重用的,知道重用了包里的一个类,那么就要重用包中的所有类

  如果一个模块或类被设计为可以被多个其他模块或类重用，那么它应该包含那些被共同使用的功能和数据。换句话说，相关的功能应该被组织在一起，以便于被多个模块共享和重用

• 无环依赖原则（No Circular Dependency Principle）: 在包的依赖关系图中不允许存在环,即包之间的结构必须是一个直接的无环图形

• 稳定抽象原则（Stable Abstractions Principle）: 在设计软件系统时，抽象应该尽量保持稳定，而具体实现则可以变化

进行面向对象系统设计时，针对包中的所有类对于同-类性质的变化；一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。这属于（D）设计原则。
A. 共同重用 B. 开放-封闭 C. 接口分离 D. 共同封闭

组合优于继承原则

组合和继承都在尝试解决同样的问题:假如你有一段代码想复用

广为流传的“组合优于继承” 的说法是一种不严谨的翻译，其来源如下：（众多设计模式强调的两个个最核心原则《Design Patterns: Elements of Reusable Object-Oriented Software》）

1. Program to an interface, not an implementation. (面向接口编程，而不是具体的实现)
2. Favor object composition over class inheritance.（若某个场景的代码复用既可以通过类继承实现，也可以通过对象组合实现，尽量选择对象组合的方式）

对象组合与类继承的对比

面向对象设计的过程中，两个最常用的技巧就是类继承和对象组合，同一个场景下的代码复用，这两个技巧基本上都可以完成。 但是他们有如下的区别：

• 通过继承实现的代码复用常常是一种“白盒复用”， 这里的白盒指的是可见性： 对于继承来说，父类的内部实现对于子类来说是不透明的（实现一个子类时， 你需要了解父类的实现细节， 以此决定是否需要重写某个方法）
• 对象组合实现的代码复用则是一种“黑盒复用”: 对象的内部细节不可见，对象仅仅是以“黑盒”的方式出现（可以通过改变对象引用来改变其行为方式）

继承式

这里通过汽车的刹车逻辑进行说明， 对于汽车来说，存在多种不同的型号，我们会很自然的希望定义一个类Car来描述所有汽车通用的刹车行为brake()，然后通过某种方式（继承/组合）来为不同的型号的汽车提供不同的刹车行为。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

public abstract class Car
{
    // 也可以将该方法设置成抽象方法，强迫子类来实现该方法
    public virtual void Brake()
    {
        // 提供一个默认的刹车实现
    }
}

public class CarModelA : Car
{
    public override void Brake()
    {
        AStyleBrake(); // A 风格的刹车行为
    }

    private void AStyleBrake()
    {
        Console.WriteLine("A");
        // A 风格的刹车实现
    }
}

public class CarModelB : Car
{
    public override void Brake()
    {
        BStyleBrake(); // B 风格的刹车行为
    }

    private void BStyleBrake()
    {
        Console.WriteLine("b");
        // B 风格的刹车实现
    }
}

值得注意的是: 每一个型号的车的刹车行为是在编译时就确定好的,没有办法在运行时刻将CarModelB的刹车行为赋予CarModelA

组合式

通过引用组合各个组件

如果通过对象组合的实现方式，则需要为Car定义一个引用，该引用的类型是一个为刹车行为定义的抽象（可以是抽象类或接口类）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

// 定义刹车行为接口
public interface IBrakeBehavior
{
    void Brake(); // C# 中的接口方法不需要 public 关键字
}

// A 风格的刹车行为实现
public class AStyleBrake : IBrakeBehavior
{
    public void Brake()
    {
        AStyleBrakeMethod(); // A 风格的刹车行为
    }

    private void AStyleBrakeMethod()
    {
        // A 风格的刹车实现
    }
}

// B 风格的刹车行为实现
public class BStyleBrake : IBrakeBehavior
{
    public void Brake()
    {
        BStyleBrakeMethod(); // B 风格的刹车行为
    }

    private void BStyleBrakeMethod()
    {
        // B 风格的刹车实现
    }
}

// 汽车类
public class Car
{
    protected IBrakeBehavior brakeBehavior;

    public void Brake()
    {
        brakeBehavior.Brake(); // 调用当前的刹车行为
    }

    public void SetBrakeBehavior(IBrakeBehavior brakeType)
    {
        this.brakeBehavior = brakeType; // 设置新的刹车行为
    }
}

注意：上面的刹车行为不一定需要通过接口来实现，定义一个BrakeBehaviour的父类，然后再定义AStyleBrake，BStyleBrake来继承该类，实现不同的行为， 同样是组合方式的应用。所以不难发现， 当我们拿类继承和组合在一起进行对比时， 并不是以实现方式中是否有用到类继承来区分的。

我们真正关注的是行为的继承与行为的组合 ：需要变化的行为是通过继承后重写的方式实现，还是通过赋予不同的行为实例对象实现。

继承式优缺点

类继承优点：

• 类之间的继承关系时在编译时刻静态地定义好的，因此使用起来也非常直观，毕竟继承是被编程语言本身所支持的功能。
• 类继承也使得修改要复用的代码变得相对容易，因为可以仅仅重写要更改的父类方法。(如在Java集合标准库中，大量方法就是通过继承复用的，针对这些方法的维护、升级都相对简单)

类继承缺点:

• 第一个缺点是伴随第一个优点而生的：无法在运行时改变继承了父类的子类行为（这一点在之前汽车的例子中已经进行了说明）。
• 第二个缺点更严重：与父类耦合,通过继承实现的代码复用，本质上把父类的内部实现细节暴露给了子类，子类的实现会和父类的实现紧密的绑定在一起，结果是父类实现的改动，会导致子类也必须得改变。

以之前的例子进行说明，如果是通过继承的方式来实现不同型号汽车的刹车行为变化，假设现在我们基于Car这个父类实现了10种不同型号的汽车CarModel( A、B、C、D、E、F、G、H、I 、J)，其中前5个型号( A、B、C、D、E) 都没有重写父类的刹车方法，直接使用了父类Car提供的默认方法，后5个型号均提供了自己独特的brake实现 。

现假设，我们希望对Car中的brake方法进行升级改造，然而升级改造后的brake行为只适用于C，D，最早的两种型号A，B并不兼容升级后的刹车行为。这样，我们为了保证A，B依旧能正常工作，就不得不把旧的brake实现挪到A、B中，或者分别去升级C、D、E中的brake方法。(比如Java集合标准库中，后期对Stream的支持，直接改变了interface类最早的定义，在interface中加入了默认实现机制)

组合式优缺点

对象组合优点:

• 对象的组合是在运行时，通过对象之间所获取的引用关系决定的，所以对象组合要求不同的对象遵从对方所实现的接口来做引用传递，这样反过来会要求开发者更用心地设计接口，以此保证客户端在使用一个对象时，可以把它和很多其他的对象组合在一起使用而不会出现问题。
• 对象的组合由于是通过接口实现的，这样在复用的过程中不会打破其封装性。任意一个对象都可以在运行时被替换成另外一个实现了相同接口且类型相同的对象，更重要的是，由于一个对象的实现是针对接口而编写的，具体实现之间的依赖会更少。
• 对象组合的方式可以帮助你保持每个类的内聚性，让每个类专注实现一个任务。类的层次会保持的很小，不会增长到一种无法管理的恐怖数量。（这也是Java只支持单继承的原因）

总结而言:现代开发,组合才具备更强的灵活性而当继承面领改变的时候,因为子类与父类的耦合会带来更大的重构复杂度

根本原因也是因为,继承自然地要求捆绑所有公共元素到父类上,但一旦发现共性中的例外,这就需要很大的修改

继承遵守的契约是子类都有父类的结构,即父类共享了所有,而在组合式中,接口就是就是契约,他是最轻量最小化级的契约,更容易被附加到已经存在的类中.

说白了,组合是一种更加好用的抽象方式

现代项目开发中完全可以不使用继承,只使用组合会更好

组合所使用的引入接口的这种做法又叫依赖注入

组合缺点以及解决方案

• 因为需要初始化所有的内部类型,很多的实现会含有相同的重复代码

• 当需要从重用的代码中暴露信息时,需要创建许多包装方法(简单返回一个内部类型的调用)

  1 2 3 4

  void getName() { return user.getName(); }

总之,优势远大于劣势,减少未来修改付出的代价

依赖注入

Dependency Injection

本质就是有两段代码,其中一段代码中想要使用另一段代码,但是它不直接用,而是把它当成参数传进来(使用接口的方式传入,就好比依赖了这个接口),把要用的东西传进来就是”注入“

把被依赖的代码注入到要用它的代码 称之为 依赖注入

下面视频有利于直观感受依赖注入的好处

优势:修改简单,易于测试

一个思想:如果发现自己在想怎么测试private方法,或者需要设置一些内部变量才能进行测试,这个信号在提醒你需要把一些东西提出来,把他们分离出来并通过注入实现隔离

依赖倒置原则

依赖倒置原则（Dependency Inversion Principle, DIP）是 SOLID 设计原则之一，它的核心思想是：

1. 高层模块不应该依赖低层模块，两者都应该依赖抽象。
2. 抽象不应该依赖具体实现，具体实现应该依赖抽象。

通过依赖倒置原则，可以有效解决循环依赖问题，因为它将直接的依赖关系解耦为通过抽象（接口或抽象类）进行间接依赖

循环依赖是指两个或多个模块（类）之间直接或间接地相互依赖。例如：

• 类 A 依赖类 B。
• 类 B 同时依赖类 A。

这种情况下，代码会变得紧耦合，难以维护和测试，甚至可能导致编译或运行时错误。

一般都是通过引入抽象层和依赖注入,将循环依赖转换为对抽象的依赖,从而打破紧耦合关系,步骤如下:

• 定义接口。
• 让类实现接口并依赖接口。
• 在运行时动态注入具体实现。

概述

设计模式的重要性

马丁：设计模式给了我们瞄准的目标。我还会做一些预先设计。模式就是用来干这个的。模式还给了我们以重构的目标。我们得以知道我们改进的方向。了解模式还有助于我们找到设计美感，因为模式至少都是一些好的设计。你可以从它们身上学到很多。因此，我仍然认为模式起着重要的作用。

必考4分左右

23种设计模式

创建型模式（Creational Patterns）

它关注类产生对象的创建过程中的各种模式

1. 工厂模式（Factory Pattern）
2. 抽象工厂模式（Abstract Factory Pattern）
3. 单例模式（Singleton Pattern）
4. 建造者模式（Builder Pattern）
5. 原型模式（Prototype Pattern）

结构型模式（Structural Patterns）

它关注对象与对象之间的各种组合关系的各种模式

1. 适配器模式（Adapter Pattern）
2. 桥接模式（Bridge Pattern）
3. 组合模式（Composite Pattern）
4. 装饰器模式（Decorator Pattern）
5. 外观模式（Facade Pattern）
6. 享元模式（Flyweight Pattern）
7. 代理模式（Proxy Pattern）

行为型模式（Behavioral Patterns）

它关注对象各种不同的用处和场景的各种模式

1. 策略模式（Strategy Pattern）
2. 观察者模式（Observer Pattern）
3. 模板方法模式（Template Method Pattern）
4. 迭代器模式（Iterator Pattern）
5. 命令模式（Command Pattern）
6. 备忘录模式（Memento Pattern）
7. 状态模式（State Pattern）
8. 访问者模式（Visitor Pattern）
9. 中介者模式（Mediator Pattern）
10. 解释器模式（Interpreter Pattern）
11. 责任链模式（Chain of Responsibility Pattern）

设计模式之间的关系

上图中红色表示创建型的,绿色表示结构型的,蓝色表示行为型的,相连表示有相似性(容易混淆,连接线上的文字表示主要不同点)

图例讲解

为什么不使用UML图讲解?因为UML图带成员,不够简洁

下面所有设计模式结构图均参考这些图例来讲解(直观)

创建型模式

工厂模式

将对象的实例化交给工厂去做，你只需要告诉工厂你需要什么对象，我给你造出来就行了

目的：让使用者只需要关注自己需要的，而不需要关注这个东西是怎么创建的，能用就行。让实例创建和实例使用解耦

意图: 定义一个创建对象的接口,但由子类决定需要实例化哪一个类,使得延迟到子类来实例化

简单工厂模式

两种实现方式

1. 在类里写静态函数用于创建实例

   解决构造函数参数太多的问题，通过定义一个静态函数用于创建实例,来简化代码

   

2. 使用一个单独的类来创建实例

   

简单工厂:把对象的创建放到一个工厂类中,通过参数来创建不同的对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class Factory
{
public:
	Factory();
	~Factory();
	// 工厂函数
	// 创建RequestCodec对象
	// 创建RespondCodec对象
	// flag == 0 创建RequestCodec对象
	// flag == 1 创建RespondCodec对象
	Codec *createFactory(int flag)
	{
		switch (flag)
		{
		case 0:
			// 创建RequestCodec对象
			return new xxx;
		case 1:
			break;
		default:
			break;
		}
	}
}

• 缺点：每添一个对象，就需要对简单工厂进行修改（尽管不是删代码，仅仅是添一个switch case，但仍然违背了“不改代码”的原则, 尽量做到添加代码而不是修改原有代码）
• 优点：去除了与具体产品的依赖。

使用:

1
2
3
4
5
6

// 1. 创建工厂类
Factory* factory = new Factory();
// 2. 使用工厂函数创建对象, 返回父类指针
Codec*codec = factory->createFactory(0);
// 3. 编解码
codec->msgEncode();

抽象工厂模式

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

意图是: 提供一个接口,可以创建一系列相关或相互依赖的对象,而无需指定他们具体的类

好处:易于维护,易于扩充,且不用对原有的代码进行修改

1. 工厂方法：每种产品由一种工厂来创建, 不同工厂创建不同的对象
2. 创建一个工厂类 - 基类
3. 在基类的工厂类中添加工厂函数, 这是一个虚函数
4. 根据要创建的子对象添加子工厂类, 每个子对象的创建都对应一个子工厂类
5. 在子工厂类中实现父类的工厂函数, 完成创建对象的操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

// 创建的子对象
class RequestCodec
{
}
//
class RespondCodec
{
}
// 创建工厂类的父类
class Factory
{
public:
	Factory();
	~Factory();
	// 工厂函数
	// 创建RequestCodec对象
	// 创建RespondCodec对象
	// flag == 0 创建RequestCodec对象
	// flag == 1 创建RespondCodec对象
	virtual Codec *createFactory(){};
}
// 创建子工厂类
class RequestFactory : public Factory
{
public:
	RequestFactory()
	{
		flag = 0;
	}
	RequestFactory(RequestMsg *msg)
	{
		m_request = msg;
		flag = 1;
	}
	~RequestFactory();
	// 只创建RequestCodec对象
	Codec *createFactory()
	{
		if (flag)
			return new RequestCodec(&msg);
		else
			return new RequestCodec();
	}

private:
	RequestMsg *m_request;
	bool flag;
}
// 创建子工厂类
class RespondFactory : public Factory
{
public:
	RequestFactory();
	~RequestFactory();
	// 只创建RespondCodec对象
	Codec *createFactory()
	{
		return new RespondCodec();
	}
}

其实就是把switch的分支拆到了多态中

抽象工厂类的使用:

1
2
3
4
5
6
7

// 使用编解码RequestCodec
// 1. 创建工厂对象
Factory* f = new RequestFactory();
// 2. 创建编解码的类对象
Codec* codec = f->createFactory();
// 3. 编解码
codec->msgDecode();

实例

• BaseASN1 实现最基本的[[网络编程#ASN.1|ASN1编码]]逻辑

• SequenceASN1 ASN1编码的进一步封装

• Codec 对为了实现对不同结构体的ASN1编码而对SequenceASN1做的进一步封装的一个用于实现多态的基类

• RequestCodec和RespondCodec 用于具体实现Codec多态的[对请求数据进行ASN1编码的类型]以及[对回应数据进行ASN1编码的类型]

• FactoryCodec 生产各种工厂的抽象类,其生产工厂的函数返回的类型为Codec(多态对多态)

• RequestFactory和RespondFectory 具体的[生产请求数据的工厂的类]和[生产回应数据的工厂的类]

其使用方式为:

1
2
3
4
5
6
7

// 使用编解码RequestCodec
// 1. 创建工厂对象
FactoryCodec* f = new RequestFactory();
// 2. 创建编解码的类对象
Codec* codec = f->createCodec();   
// 3. 编解码
codec->msgDecode();

单例模式

通过持有自身实例实现

意图: 保证一个类只有一个实例,并提供一个访问它的全局访问点

类产生的实例是全局唯一的

• 饿汉式-单例模式

  在类创建的时候,就创建实例,并直接让这个产生出来的实例绑定到自己的某一个静态成员上,提供一个静态方法返回这个静态成员(实际上就是实例),通过这个getxxx静态方法就能拿到自身唯一的实例.这个过程中构造函数是私有的,防止了通过构造函数在外界创造实例

  

  缺点在于,程序刚开始运行的时候会比较卡,大量new被执行(懒汉式正是解决此问题)

• 懒汉式-单例模式

  解决的正是饿汉式的问题,让他在真正需要执行的时候再去运行这段代码

  在getxxx静态方法被调用的时候去检查静态属性,如果是null才创建实例

  

当创建实例的代价很大的时候,并且常用该实例用不到的情况可以使用这种懒汉式单例模式

原型模式

类中实现Clone方法,通过在实例中调用克隆函数用于克隆自身

适合于克隆自己比通过构造函数创建自身效率高的场景(实际使用场景较小)

意图: 用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象

构造器模式

也叫Builder模式(建造者模式),也叫生成器模式

在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

意图: 将一个复杂类的表示与其构造相分离,使得相同的构建过程(不同的组装)能够得出不同的表示

将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 ——《设计模式》GoF

大部分编程语言都支持可选参数,完全能更方便实现这样的功能,该模式在构造过程极其复杂的情况下有存在的意义

结构型模式

适配器模式

常用于解决旧系统或新旧接口之间的兼容问题

主要有两种

• 类-适配器
• 对象-适配器

类-适配器

通过继承实现

创建一个新类(适配器)继承新接口,同时继承老接口的实现类,在新类中新接口中的方法中调用老接口的方法同时做其他逻辑

实例

以java演示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// 旧的打印机接口
interface OldPrinter {
    void printString();
}

// 适配者类
class SpecificPrinter implements OldPrinter {
    @Override
    public void printString() {
        System.out.println("Print from SpecificPrinter");
    }
}

// 新的打印接口
interface NewPrinter {
    void print();
}

// 通过继承SpecificPrinter并实现NewPrinter接口来创建适配器类
class PrinterAdapter extends SpecificPrinter implements NewPrinter {
    @Override
    public void print() {
        // 调用适配者类SpecificPrinter的方法
        printString();
    }
}

//演示使用效果
public class ClassAdapterDemo {
    public static void main(String[] args) {
        NewPrinter newPrinter = new PrinterAdapter();//使用的时候这个是关键,用新接口引用适配器实例
        newPrinter.print(); // 将输出：Print from SpecificPrinter
      	//最终就实现了通过新接口来调用新接口的方法,通过适配器实际上调用的是老接口的方法
    }
}

UML类图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

classDiagram
    class OldPrinter {
        <<interface>>
        +printString()
    }

    class SpecificPrinter {
        +printString()
    }

    class NewPrinter {
        <<interface>>
        +print()
    }

    class PrinterAdapter {
        +print()
    }

    OldPrinter <|.. SpecificPrinter
    SpecificPrinter <|-- PrinterAdapter
    NewPrinter <|.. PrinterAdapter

对象-适配器

通过组合实现

实例

以java演示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// 旧的打印机接口
interface OldPrinter {
    void printString();
}

// 适配者类
class SpecificPrinter implements OldPrinter {
    @Override
    public void printString() {
        System.out.println("Print from SpecificPrinter");
    }
}

// 新的打印接口
interface NewPrinter {
    void print();
}

// 通过组合SpecificPrinter并实现NewPrinter接口来创建适配器类
class PrinterAdapter implements NewPrinter {
    private final OldPrinter oldPrinter;

    public PrinterAdapter(OldPrinter oldPrinter) {
        this.oldPrinter = oldPrinter;
    }

    @Override
    public void print() {
        // 调用适配者类SpecificPrinter的方法
        oldPrinter.printString();
    }
}

// 演示使用效果
public class ObjectAdapterDemo {
    public static void main(String[] args) {
        OldPrinter oldPrinter = new SpecificPrinter();
        NewPrinter newPrinter = new PrinterAdapter(oldPrinter); // 使用的时候这个是关键，用新接口引用适配器实例
        newPrinter.print(); // 将输出：Print from SpecificPrinter
        // 最终就实现了通过新接口来调用新接口的方法，通过适配器实际上调用的是老接口的方法
    }
}

UML类图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

classDiagram
    class OldPrinter {
        <<interface>>
        +printString()
    }

    class SpecificPrinter {
        +printString()
    }

    class NewPrinter {
        <<interface>>
        +print()
    }

    class PrinterAdapter {
        -oldPrinter : OldPrinter
        +PrinterAdapter(OldPrinter oldPrinter)
        +print()
    }

    OldPrinter <|.. SpecificPrinter
    NewPrinter <|.. PrinterAdapter
    PrinterAdapter --> OldPrinter

桥接模式

一言以蔽之:就是将多个接口及实现的体系可以通过一个类桥接到一起

桥接模式是一种结构型设计模式，用于将抽象部分与实现部分分离，使它们可以独立变化，互不影响。桥接模式的核心思想是通过将抽象部分和实现部分分离，使它们可以独立变化，从而提高系统的灵活性和可扩展性。

简单来说，桥接模式就像是一座桥，连接了抽象部分和实现部分，使它们可以分别变化而不相互影响。通过桥接模式，我们可以轻松地添加新的抽象部分或实现部分，而不需要修改原有的代码结构。

举个例子，假设我们要设计一个绘图软件，其中有不同的形状（圆形、矩形）和不同的颜色（红色、蓝色）。使用桥接模式，我们可以将形状和颜色分别作为抽象部分和实现部分，通过桥接将它们连接在一起。这样，我们可以轻松地组合不同的形状和颜色，而不需要修改原有的代码结构。

看似很复杂,实际上就是图中右上方的抽象类通过依赖注入的方式,传入武器,如果还有底座啥的,也同样利用依赖注入传进来,相当于桥接了武器和底座,可以随意桥接两两

实际上就是依赖注入多个组件的思想

组合模式

组合模式是一种结构型设计模式，它允许你将对象组合成树形结构以表示“部分-整体”的层次结构。这种模式使得客户端可以统一处理单个对象和对象组合，而不必区分它们之间的差异。在组合模式中，组合对象和叶子对象都实现相同的接口，这样客户端可以像处理单个对象一样处理对象组合。这种模式可以使得系统更加灵活和可扩展，同时简化了客户端的代码。

适用场景: 当希望以一致的方式处理单个对象和对象组合时使用

实例

以C#代码为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

using System;
using System.Collections.Generic;

// 武器接口
interface IWeapon
{
    void Attack();
}

// 具体武器类：剑
class Sword : IWeapon
{
    public void Attack()
    {
        Console.WriteLine("使用剑攻击！");
    }
}

// 具体武器类：枪
class Gun : IWeapon
{
    public void Attack()
    {
        Console.WriteLine("使用枪射击！");
    }
}

// 组合模式中的组件基类   
//继承IWeapon,这样在使用组合模式时，无论是叶子节点还是复合节点都可以统一地调用Attack()方法
abstract class WeaponComponent : IWeapon
{
    public abstract void Add(WeaponComponent component);
    public abstract void Remove(WeaponComponent component);
}

// 组合模式中的复合武器类
class CompositeWeapon : WeaponComponent
{
    private List<WeaponComponent> components = new List<WeaponComponent>();

    public override void Add(WeaponComponent component)
    {
        components.Add(component);
    }

    public override void Remove(WeaponComponent component)
    {
        components.Remove(component);
    }

    public void Attack()
    {
        foreach (WeaponComponent component in components)
        {
            component.Attack();
        }
    }
}

class Program
{
    static void Main()
    {
        Sword sword1 = new Sword();
        Sword sword2 = new Sword();
        Gun gun1 = new Gun();

        CompositeWeapon compositeWeapon = new CompositeWeapon();
        compositeWeapon.Add(sword1);
        compositeWeapon.Add(sword2);
        compositeWeapon.Add(gun1);

        compositeWeapon.Attack();
    }
}

UML类图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

classDiagram
    IWeapon <|.. Sword
    IWeapon <|.. Gun
    IWeapon <|.. WeaponComponent
    WeaponComponent <|-- CompositeWeapon
    
    class IWeapon {
        +Attack()
    }
    
    class Sword {
        +Attack()
    }
    
    class Gun {
        +Attack()
    }
    
    class WeaponComponent {
        +Add(WeaponComponent component)
        +Remove(WeaponComponent component)
    }

    class CompositeWeapon {
        -List~WeaponComponent~ components
        +Add(WeaponComponent component)
        +Remove(WeaponComponent component)
        +Attack()
    }
    
    class Program {
        +Main()
    }
    
    Program --> CompositeWeapon
    CompositeWeapon --> WeaponComponent
    CompositeWeapon --> IWeapon
    Sword --> IWeapon
    Gun --> IWeapon

装饰模式

装饰模式/装饰器/装饰者模式 (Decorator Mode)

动态地给一个对象增加新的功能,而不改变对象原本的结构 (非常有用!)

装饰器模式允许在不影响同一类其他对象行为的情况下，静态或动态地向单个对象添加行为。装饰器模式对于遵循单一职责原则特别有用，因为它允许将功能分离到不同的类中，每个类都有自己独特的关注点。

适用场景: 当希望在不修改原有代码情况下,动态地给对象添加新功能时,可以使用装饰器模式,装饰器模式可以帮助你以灵活和可拓展的方式组合对象的各种功能

给一个类或对象增加新的功能,有两种方式:(参考上图)

• 上方的机器人,更新功能左下角机器人,称之为继承机制:新类继承一个现有的类,在子类中进行拓展功能
• 上方的机器人,更新功能为右下角机器人,称之为关联机制:将一个类的对象套入到另一个类的对象中,相当于把机器人嵌入到箱子里来,套一个壳子来拓展功能,这个壳子就是装饰器

对于第一种方式来说:最大的问题在于继承是静态的,没办法在运行的过程中动态的改变一个类的行为.

第二种方法是动态的:
$$
动态地给一个对象添加一些额外的功能.就增加功能来说,装饰模式比生成子类更为灵活
$$
可以这么理解,经过处理就可以给类添加新功能

这也是和代理模式的区别:代理类里面是写死的，在编译的时候就确定了关系。而装饰器是在运行时来确定的

• 代理模式是直接编写代理对象
• 装饰模式是编写函数动态生成代理对象

装饰器模式关注于在一个对象上动态添加方法，而代理模式关注于控制对象的访问

大致的操作图如下:

紫色的圆是左边类的对象,通过构造传入右边类成员中,在新类的同名run中调用成员对象的原来的run,这里就可以在前后添加代码逻辑

使用场景

实现监听器功能,提供一个接口,让使用者自定义监听某个事件发生时的行为,在事件发生前后触发相应的操作:通过装饰器模式，可以动态地附加到想要监听的对象上,在执行目标函数的前后可以执行相应的函数(装饰器用来做监听器的场景非常多)

肉鸽游戏场景:

案例

根据这个图,给出c#的代码,以演示装饰者模式

然后就可以以如图的形式动态地(套壳)修改类的表现形式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

using System;
using System.Collections.Generic;

// 基础抽象类 Beverage 饮料类
abstract class Beverage
{
    public abstract string Description { get; }
    public abstract double Cost();
}

// 具体组件类 奶茶
class MilkTea : Beverage
{
    public override string Description => "Milk Tea";
    
    public override double Cost()
    {
        return 2.00;
    }
}

//具体组件类 水果茶
class FruitTea : Beverage
{
    public override string Description => "Fruit Tea";
    
    public override double Cost()
    {
        return 2.50;
    }
}

//具体组件类 酸奶
class Yogurt : Beverage
{
    public override string Description => "Yogurt";
    
    public override double Cost()
    {
        return 3.00;
    }
}

// 抽象装饰者类 
// 注意:要继承抽象饮料类,包含抽象饮料类的对象成员
abstract class ToppingDecorator : Beverage
{
    protected Beverage beverage;

    public ToppingDecorator(Beverage beverage)
    {
        this.beverage = beverage;
    }

    public override string Description => beverage.Description;

    public abstract override double Cost();
}

// 具体装饰者类 珍珠装饰器
class Boba : ToppingDecorator
{
    public Boba(Beverage beverage) : base(beverage) { }

    public override string Description => beverage.Description + ", Boba";
    
    public override double Cost()
    {
        return beverage.Cost() + 0.50;
    }
}

// 具体装饰者类 布丁装饰器
class Pudding : ToppingDecorator
{
    public Pudding(Beverage beverage) : base(beverage) { }

    public override string Description => beverage.Description + ", Pudding";
    
    public override double Cost()
    {
      	//注意这里的渐进式计算价格
        return beverage.Cost() + 0.60;
    }
}

// 具体装饰者类 草本果冻装饰器
class HerbalJelly : ToppingDecorator
{
    public HerbalJelly(Beverage beverage) : base(beverage) { }

    public override string Description => beverage.Description + ", Herbal Jelly";
    
    public override double Cost()
    {
        return beverage.Cost() + 0.70;
    }
}

// 测试
class Program
{
    static void Main()
    {
        Beverage beverage = new MilkTea();
        Console.WriteLine($"{beverage.Description} ${beverage.Cost()}");

        beverage = new Boba(beverage);
        Console.WriteLine($"{beverage.Description} ${beverage.Cost()}");

        beverage = new Pudding(beverage);
        Console.WriteLine($"{beverage.Description} ${beverage.Cost()}");

        beverage = new HerbalJelly(beverage);
        Console.WriteLine($"{beverage.Description} ${beverage.Cost()}");
    }
}
/*
Milk Tea $2
Milk Tea, Boba $2.5
Milk Tea, Boba, Pudding $3.1
Milk Tea, Boba, Pudding, Herbal Jelly $3.8
*/

当需要添加新的配料,只需要添加新的具体的配料装饰类;同样当需要添加新的饮料也只需要添加新的具体的饮料类

UML类图:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

classDiagram
    class Beverage {
        <<abstract>>
        +Description : string
        +Cost() : double
    }

    class MilkTea {
        +Description : string
        +Cost() : double
    }

    class FruitTea {
        +Description : string
        +Cost() : double
    }

    class Yogurt {
        +Description : string
        +Cost() : double
    }

    class ToppingDecorator {
        <<abstract>>
        -beverage : Beverage
        +ToppingDecorator(Beverage beverage)
        +Description : string
        +Cost() : double
    }

    class Boba {
        +Description : string
        +Cost() : double
    }

    class Pudding {
        +Description : string
        +Cost() : double
    }

    class HerbalJelly {
        +Description : string
        +Cost() : double
    }

    Beverage <|-- MilkTea
    Beverage <|-- FruitTea
    Beverage <|-- Yogurt
    Beverage <|-- ToppingDecorator
    ToppingDecorator <|-- Boba
    ToppingDecorator <|-- Pudding
    ToppingDecorator <|-- HerbalJelly

外观模式

外观模式/门面模式（Facade Pattern）

外观模式为子系统中的一组接口提供一个统一的接口,即定义了一个高层接口,使得这一子系统更加容易使用

通过提供一个统一的接口，来隐藏系统中多个子系统的复杂性

将多个高度耦合的多类结构,封装到一个类中,只提供统一接口,是一种封装的思想

适用场景: 当需要简化复杂系统的使用接口时,可使用外观模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class ResourceManagement:
    def manage_resources(self):
        print("管理资源.")

class TowerConstruction:
    def build_tower(self, location):
        print(f"{location}位置建造塔.")

class EnemySpawning:
    def spawn_enemies(self):
        print("生成敌人.")

class GameLoopControl:
    def start_game_loop(self):
        print("开始游戏循环.")

class GameFacade:
    def __init__(self):
        self.resource_management = ResourceManagement()
        self.tower_construction = TowerConstruction()
        self.enemy_spawning = EnemySpawning()
        self.game_loop_control = GameLoopControl()

    def start_game(self):
        self.resource_management.manage_resources()
        self.tower_construction.build_tower("中央位置")
        self.enemy_spawning.spawn_enemies()
        self.game_loop_control.start_game_loop()
        print("游戏开始!")

def main():
    game_facade = GameFacade()
    game_facade.start_game()

if __name__ == "__main__":
    main()

享元模式

享元模式（Flyweight Pattern）

享元的本质就是公用数据的抽象,全局变量就可以算是一种享元

通过共享技术来有效地支持大量细粒度对象的重用,节省不必要的属性空间,节省内存

将共同类型的属性放到享元类中

简单来说,享元模式通过共享对象来减少内存消耗,使用一个工厂来管理这些共享对象,并确保每个对象只被创建一次

适用场景: 当需要创建大量相似对象,并希望通过共享对象来减少内存消耗时,可以使用享元模式

享元模式通过共享相同的状态来减少内存占用和提高性能，同时通过动态传递非共享状态来实现个性化定制。享元工厂负责管理共享池，确保享元对象的唯一性和共享性

• 具体享元类包含了所有共享的状态：

  具体享元类是享元模式中的一种类别，它包含了所有可共享的状态或属性。这些状态是可以被多个对象共享的，从而节省内存和提高性能。具体享元类的实例通常是不可变的，它们包含了固定不变的共享状态。

• 非共享的状态则会在使用时动态传递：

  非共享的状态是指每个具体享元对象特有的状态或属性，这些状态不可共享。在使用具体享元对象时，这些非共享的状态会动态传递给享元对象，以便个性化地定制享元对象的行为。

• 享元工厂负责维护享元对象的共享池：

  享元工厂是负责创建和管理享元对象的工厂类。享元工厂维护一个共享池（Flyweight Pool），用于存储和管理已创建的享元对象。享元工厂确保相同的享元对象只被创建一次，并在需要时从共享池中获取已有的享元对象。

• 提供一个方法来获取享元对象：

  享元工厂提供一个方法（通常是工厂方法），用于获取享元对象。当客户端需要使用享元对象时，可以通过调用享元工厂的方法来获取相应的享元对象，并在其中传递非共享的状态参数。

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

using System;
using System.Collections.Generic;

// 抽象享元类
interface ITextStyle
{
    void ApplyStyle(string text);
}

// 具体享元类
class ConcreteTextStyle : ITextStyle
{
    private readonly string _font;
    private readonly int _size;
    private readonly string _color;

    public ConcreteTextStyle(string font, int size, string color)
    {
        _font = font;
        _size = size;
        _color = color;
    }

    public void ApplyStyle(string text)
    {
        Console.WriteLine($"Applying [{_font}, {_size}, {_color}] to \"{text}\"");
    }
}

// 享元工厂类
class TextStyleFactory
{
    private static readonly Dictionary<string, ITextStyle> Styles = new Dictionary<string, ITextStyle>();

    public static ITextStyle GetStyle(string font, int size, string color)
    {
        string key = font + size + color;
        if (!Styles.TryGetValue(key, out ITextStyle style))
        {
            style = new ConcreteTextStyle(font, size, color);
            Styles[key] = style;
        }
        return style;
    }
}

// 演示类
class FlyweightPatternDemo
{
    static void Main()
    {
        ITextStyle style1 = TextStyleFactory.GetStyle("Arial", 12, "Red");
        style1.ApplyStyle("Hello, World!");

        ITextStyle style2 = TextStyleFactory.GetStyle("Arial", 12, "Red");
        // style2 和 style1 是相同实例
        style2.ApplyStyle("Flyweight Pattern Demo");

        Console.ReadKey();
    }
}
/*
Applying [Arial, 12, Red] to "Hello, World!"
Applying [Arial, 12, Red] to "Flyweight Pattern Demo"
*/

抽象享元类 ITextStyle

• 定义了一个方法 ApplyStyle(string text)，用于应用样式。

具体享元类 ConcreteTextStyle

• 实现了 ITextStyle 接口。
• 包含三个只读属性：_font, _size, _color，分别表示字体、大小和颜色。
• 构造函数用于初始化这些属性。
• ApplyStyle 方法打印应用的样式和文本。

享元工厂类 TextStyleFactory

• 使用 Dictionary<string, ITextStyle> 存储已经创建的享元对象。
• GetStyle 方法根据 font, size, color 生成一个键，并检查是否已有对应的享元对象。
• 如果没有，则创建一个新的 ConcreteTextStyle 对象并存储到 Styles 中。
• 最后返回找到的或新创建的享元对象。

演示类 FlyweightPatternDemo

• Main 方法演示了享元模式的使用。
• 调用 TextStyleFactory.GetStyle 获取享元对象并应用样式。
• style1 和 style2 应用了相同的样式，因此 style2 会复用 style1 的实例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

classDiagram
    class ITextStyle {
        <<interface>>
        +ApplyStyle(string text)
    }

    class ConcreteTextStyle {
        -_font : string
        -_size : int
        -_color : string
        +ConcreteTextStyle(string font, int size, string color)
        +ApplyStyle(string text)
    }

    class TextStyleFactory {
        -Styles : Dictionary~string, ITextStyle~
        +GetStyle(string font, int size, string color) : ITextStyle
    }

    ITextStyle <|.. ConcreteTextStyle
    ConcreteTextStyle --> TextStyleFactory : uses

代理模式

代理模式通过代理类控制对真实对象的访问，并在需要时创建和使用真实对象

核心思想:代理模式为其他对象提供了一种代理以控制对这个对象的访问

代理，在其最广泛的形式中，是一个用作其他事物接口的类。代理是一个包装或代理对象，客户端通过它来访问后台的实际服务对象。使用代理可以简单地将请求转发到实际对象，或者提供额外的逻辑。在代理中可以提供额外的功能，例如，当对实际对象的操作资源消耗较大时进行缓存，或在调用实际对象的操作之前进行前置条件检查。

适用场景: 当需要在访问对象时增加额外的操作时,可以使用代理模式.例如,延迟加载,权限控制,日志记录等.代理模式可以帮助你在不修改现有代码的情况下,实现对对象访问的控制

代理类中持有[真正的类]对象,同样的函数名在其中调用[真正的类]的方法的时候还能执行一些新的动作,代理类的名字往往是真正的类+proxy

应用场景:劫持,过滤,安全检查

1. 远程代理（Remote Proxy）：用于在不同地址空间中代表对象。远程代理可以隐藏对象存在于不同地址空间的实现复杂性，使得客户端可以像调用本地对象一样调用远程对象。
2. 虚拟代理（Virtual Proxy）：用于延迟加载对象的开销昂贵的资源。虚拟代理会在需要时创建真实对象，而在不需要时充当占位符。
3. 保护代理（Protection Proxy）：用于控制对对象的访问权限。保护代理可以限制对对象的访问，确保只有特定权限的用户可以访问对象。
4. 缓存代理（Cache Proxy）：用于缓存对象，以提高系统性能。缓存代理会在访问对象前检查缓存，如果对象已经存在于缓存中，则直接返回缓存的对象，避免重复创建对象。
5. 日志记录代理（Logging Proxy）：用于记录对象的操作日志。日志记录代理可以在调用对象的方法前后记录日志信息，用于调试和跟踪操作。
6. 智能引用代理（Smart Reference Proxy）：用于在对象被引用时执行额外的操作。智能引用代理可以在对象被引用时执行计数、内存管理等操作，以确保对象的正确使用。
7. 延迟初始化（Lazy Initialization）：用于延迟对象的初始化。代理模式可以通过延迟初始化来避免在对象创建时的高开销，延迟到真正需要时再进行初始化。

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

using System;

// 图片接口
public interface IImage
{
    void Display();
}

// 具体图片类
public class Image : IImage
{
    private string _fileName;

    public Image(string fileName)
    {
        _fileName = fileName;
        LoadImageFromDisk();
    }

    private void LoadImageFromDisk()
    {
        Console.WriteLine("Loading image from disk: " + _fileName);
    }

    public void Display()
    {
        Console.WriteLine("Displaying image: " + _fileName);
    }
}

// 图片代理类
public class ImageProxy : IImage
{
    private readonly string _fileName;
    private Image _image;

    public ImageProxy(string fileName)
    {
        _fileName = fileName;
    }

    public void Display()
    {
        if (_image == null)
        {
            _image = new Image(_fileName);
        }
        _image.Display();
    }
}

// 图片加载器
public class ImageLoader
{
    private IImage _image;

    public ImageLoader(IImage image)
    {
        _image = image;
    }

    public void DisplayImage()
    {
        _image.Display();
    }
}

class Program
{
    static void Main(string[] args)
    {
        // 使用代理加载和显示图片
        IImage imageProxy = new ImageProxy("image.jpg");
        ImageLoader imageLoader = new ImageLoader(imageProxy);
      	Console.WriteLine("...");
        imageLoader.DisplayImage();//需要显示图片这里才真正加载图片
    }
}
/*
...
Loading image from disk: image.jpg
Displaying image: image.jpg
*/

类似单例懒汉模式,实现了使用代理模式延迟加载和显示图片

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

classDiagram
    direction LR

    class IImage {
        <<interface>>
        +Display()
    }

    class Image {
        -string _fileName
        +Image(string fileName)
        -LoadImageFromDisk()
        +Display()
    }

    class ImageProxy {
        -string _fileName
        -Image _image
        +ImageProxy(string fileName)
        +Display()
    }

    class ImageLoader {
        -IImage _image
        +ImageLoader(IImage image)
        +DisplayImage()
    }

    IImage <|.. Image
    IImage <|.. ImageProxy
    ImageLoader --> IImage
    ImageProxy --> Image

行为型模式

职责链模式

也叫责任链模式

让多个处理都有机会处理该请求,直到其中某个处理成功为止.责任链模式可以把多个处理串成链,然后让请求在链上传递,直到某一个处理处理成功为止

优点

• 将请求和处理分开,请求者不需要知道谁去处理,处理者也不需要知道请求的全貌

  将请求的接收者和发送者解耦

• 新增一个处理到整个链条中的代价是非常小的

缺点:

• 采取类似于递归的方式,不易于调试

职责链设计模式通过将请求的处理责任分摊到多个对象中，避免了请求发送者和接收者之间的耦合。在实际开发中，职责链模式可以帮助我们创建更灵活的系统结构，提高代码的可维护性和扩展性。

抽象出一个公共的父类,然后去定义不同的处理类,他们之间通过nextHandler去连接起来

案例代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

#include <iostream>
#include <string>

// 抽象处理者类
class Handler {
public:
    virtual ~Handler() = default;
    // 设置下一个处理者
    void setNext(Handler* nextHandler) {
        next = nextHandler;
    }
    
    // 处理请求的接口
    virtual void handleRequest(const std::string& request) {
        if (next) {
            next->handleRequest(request);  // 将请求传递给下一个处理者
        }
    }

private:
    Handler* next = nullptr;
};

// 具体处理者1：只处理"low"级别的请求
class LowLevelHandler : public Handler {
public:
    void handleRequest(const std::string& request) override {
        if (request == "low") {
            std::cout << "LowLevelHandler 处理请求: " << request << std::endl;
        } else {
            std::cout << "LowLevelHandler 无法处理请求，传递给下一个处理者" << std::endl;
            Handler::handleRequest(request);  // 调用父类方法传递请求
        }
    }
};

// 具体处理者2：只处理"medium"级别的请求
class MediumLevelHandler : public Handler {
public:
    void handleRequest(const std::string& request) override {
        if (request == "medium") {
            std::cout << "MediumLevelHandler 处理请求: " << request << std::endl;
        } else {
            std::cout << "MediumLevelHandler 无法处理请求，传递给下一个处理者" << std::endl;
            Handler::handleRequest(request);  // 调用父类方法传递请求
        }
    }
};

// 具体处理者3：只处理"high"级别的请求
class HighLevelHandler : public Handler {
public:
    void handleRequest(const std::string& request) override {
        if (request == "high") {
            std::cout << "HighLevelHandler 处理请求: " << request << std::endl;
        } else {
            std::cout << "HighLevelHandler 无法处理请求，传递给下一个处理者" << std::endl;
            Handler::handleRequest(request);  // 调用父类方法传递请求
        }
    }
};

int main() {
    // 创建处理者实例
    LowLevelHandler lowHandler;
    MediumLevelHandler mediumHandler;
    HighLevelHandler highHandler;
    
    // 设置职责链
    lowHandler.setNext(&mediumHandler);
    mediumHandler.setNext(&highHandler);
    
    // 测试不同的请求
    std::string request1 = "low";
    std::string request2 = "medium";
    std::string request3 = "high";
    std::string request4 = "unknown";

    std::cout << "处理请求: " << request1 << std::endl;
    lowHandler.handleRequest(request1);
    
    std::cout << "处理请求: " << request2 << std::endl;
    lowHandler.handleRequest(request2);
    
    std::cout << "处理请求: " << request3 << std::endl;
    lowHandler.handleRequest(request3);

    std::cout << "处理请求: " << request4 << std::endl;
    lowHandler.handleRequest(request4);

    return 0;
}

UML类图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

classDiagram
    class Handler {
        +setNext(Handler* nextHandler)
        +handleRequest(string request)
        -Handler* next
    }

    class LowLevelHandler {
        +handleRequest(string request)
    }

    class MediumLevelHandler {
        +handleRequest(string request)
    }

    class HighLevelHandler {
        +handleRequest(string request)
    }

    class Main {
        +main()
    }

    Handler <|-- LowLevelHandler
    Handler <|-- MediumLevelHandler
    Handler <|-- HighLevelHandler

    Main --> LowLevelHandler
    Main --> MediumLevelHandler
    Main --> HighLevelHandler
    
    LowLevelHandler --> Handler : next
    MediumLevelHandler --> Handler : next
    HighLevelHandler --> Handler : next

命令模式

命令模式它可将请求转换为一个包含与请求相关的所有信息的独立对象。该从而可以进行参数化、日志记录、队列化、撤销等操作。命令模式中，发起者（Invoker）不直接与接收者（Receiver）进行通信，而是通过命令对象来执行操作。

命令模式**通过将请求封装成对象,可以让系统支持复杂的命令以及请求和操作的管理.**他提供了一种拓展系统功能的灵活方式,同时保持调用者和接收者之间的解耦

适用场景: 命令模式非常适合用于实现命令的调度,记录,撤销和重做等功能,当你需要将操作封装为对象,通过操作的排列组合来调控具体行为时,命令模式就显得非常有用

命令模式典型的代表就是事件驱动

很大的优势在于可以轻松实现可撤销功能

优点:

• 动作封装
• 解耦发送者和接收者
• 可拓展性
• 简化和集中错误处理
• 支持撤销和重做功能
• 易于实现宏命令和组合命令

缺点: 复杂度和性能开销

常见应用案例

• 文本编辑器,图形编辑器

架构:

问号是表示懒得画了,太小了

实例架构:

开关灯案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140

#include <iostream>
#include <memory>
#include <vector>
#include <stack>

// 接收者类：灯
class Light {
public:
    void turnOn() {
        std::cout << "灯已打开" << std::endl;
    }
    
    void turnOff() {
        std::cout << "灯已关闭" << std::endl;
    }
};

// 命令接口
class ICommand {
public:
    virtual ~ICommand() = default;
    virtual void execute() = 0;
    virtual void undo() = 0;
};

// 具体命令类：打开灯
class LightOnCommand : public ICommand {
public:
    LightOnCommand(Light* light) : light_(light) {}

    void execute() override {
        light_->turnOn();
    }
    
    void undo() override {
        light_->turnOff();
    }

private:
    Light* light_;
};

// 具体命令类：关闭灯
class LightOffCommand : public ICommand {
public:
    LightOffCommand(Light* light) : light_(light) {}

    void execute() override {
        light_->turnOff();
    }
    
    void undo() override {
        light_->turnOn();
    }

private:
    Light* light_;
};

// 调用者类：遥控器
class RemoteControl {
public:
    void setCommand(std::shared_ptr<ICommand> command) {
        command_ = command;
        // 每次设置新命令时，清空 redo 栈，因为新操作后不再可以重做之前的撤销操作
        while (!redoHistory.empty()) {
            redoHistory.pop();
        }
    }
    
    void pressButton() {
        if (command_) {
            command_->execute();
            undoHistory.push(command_);
        }
    }

    void pressUndo() {
        if (!undoHistory.empty()) {
            undoHistory.top()->undo();
            redoHistory.push(undoHistory.top());
            undoHistory.pop();
        } else {
            std::cout << "没有命令可以撤销！" << std::endl;
        }
    }

    void pressRedo() {
        if (!redoHistory.empty()) {
            redoHistory.top()->execute();
            undoHistory.push(redoHistory.top());
            redoHistory.pop();
        } else {
            std::cout << "没有命令可以重做！" << std::endl;
        }
    }

private:
    std::shared_ptr<ICommand> command_;
    std::stack<std::shared_ptr<ICommand>> undoHistory;  // 用于存储已执行的命令，支持撤销
    std::stack<std::shared_ptr<ICommand>> redoHistory;  // 用于存储撤销的命令，支持重做
};

int main() {
    // 创建灯对象
    Light livingRoomLight;

    // 创建命令对象
    std::shared_ptr<ICommand> lightOnCommand = std::make_shared<LightOnCommand>(&livingRoomLight);
    std::shared_ptr<ICommand> lightOffCommand = std::make_shared<LightOffCommand>(&livingRoomLight);

    // 创建遥控器
    RemoteControl remoteControl;

    // 绑定命令：打开灯
    remoteControl.setCommand(lightOnCommand);
    remoteControl.pressButton();  // 执行打开灯的命令

    // 绑定命令：关闭灯
    remoteControl.setCommand(lightOffCommand);
    remoteControl.pressButton();  // 执行关闭灯的命令

    // 撤销操作
    remoteControl.pressUndo();  // 撤销：灯重新打开
    remoteControl.pressUndo();  // 再次撤销：灯重新关闭

    // 重做操作
    remoteControl.pressRedo();  // 重做：灯重新打开
    remoteControl.pressRedo();  // 重做：灯重新关闭

    return 0;
}

//输出:
灯已打开
灯已关闭
灯已打开
灯已关闭
灯已打开
灯已关闭

UML类图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

classDiagram
    class Light {
        +turnOn()
        +turnOff()
    }

    class ICommand {
        <<interface>>
        +execute() 
        +undo() 
    }

    class LightOnCommand {
        +execute()
        +undo()
    }

    class LightOffCommand {
        +execute()
        +undo()
    }

    class RemoteControl {
        +setCommand(ICommand* command)
        +pressButton()
        +pressUndo()
        +pressRedo()
        -undoHistory : stack<ICommand>
        -redoHistory : stack<ICommand>
    }

    LightOnCommand --> Light
    LightOffCommand --> Light
    LightOnCommand ..|> ICommand
    LightOffCommand ..|> ICommand

    RemoteControl --> ICommand

​ 1. Light 类表示接收者，包含 turnOn() 和 turnOff() 方法。

​ 2. ICommand 是命令接口，定义了 execute() 和 undo() 方法。

​ 3. LightOnCommand 和 LightOffCommand 实现了 ICommand 接口，并依赖于 Light 类，用来执行开灯和关灯的命令。

​ 4. RemoteControl 是调用者，负责将命令对象关联并执行，还管理了撤销和重做功能的栈：undoHistory 和 redoHistory。

文本编辑器案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

#include <iostream>
#include <string>
#include <stack>

// 命令基类
class Command
{
public:
	virtual ~Command() = default;
	virtual void execute() = 0;
	virtual void undo() = 0;
  //如果有必要可以添加redo
};

// 文本接收者
class TextEditor
{
public:
	void insert(const std::string &text)
	{
		content += text;
		std::cout << "插入文本: " << text << std::endl;
		std::cout << "当前文本内容: " << content << std::endl;
	}

	void remove(size_t length)
	{
		if (length <= content.length())
		{
			std::string removedText = content.substr(content.length() - length, length);
			content.erase(content.length() - length);
			std::cout << "删除文本: " << removedText << std::endl;
			std::cout << "当前文本内容: " << content << std::endl;
		}
	}

	const std::string &getContent() const
	{
		return content;
	}

private:
	std::string content;
};

// 具体命令类：插入文本命令
class InsertCommand : public Command
{
public:
	InsertCommand(TextEditor *editor, const std::string &text)
		: editor(editor), text(text) {}

	void execute() override
	{
		editor->insert(text);
		lastInsertLength = text.length(); // 记录插入的长度
	}

	void undo() override
	{
		editor->remove(lastInsertLength); // 撤销插入操作
	}

private:
	TextEditor *editor;
	std::string text;
	size_t lastInsertLength = 0;
};

// 命令执行者（Invoker）
class CommandInvoker
{
public:
	void executeCommand(Command *command)
	{
		command->execute();
		history.push(command); // 执行后将命令存入历史栈
	}

	void undoCommand()
	{
		if (!history.empty())
		{
			Command *lastCommand = history.top();
			lastCommand->undo(); // 撤销最近的命令
			history.pop();
		}
		else
		{
			std::cout << "没有命令可以撤销" << std::endl;
		}
	}

private:
	std::stack<Command *> history; // 存储已执行的命令
};

int main()
{
	TextEditor editor;		// 创建接收者
	CommandInvoker invoker; // 创建命令执行者

	// 创建命令
	Command *insertCommand1 = new InsertCommand(&editor, "Hello");
	Command *insertCommand2 = new InsertCommand(&editor, " World");

	// 执行命令
	invoker.executeCommand(insertCommand1); // 插入 "Hello"
	invoker.executeCommand(insertCommand2); // 插入 " World"

	// 撤销最近的命令
	std::cout << "\n撤销操作:\n";
	invoker.undoCommand(); // 撤销 " World"

	std::cout << "\n再次撤销操作:\n";
	invoker.undoCommand(); // 撤销 "Hello"

	// 清理内存
	delete insertCommand1;
	delete insertCommand2;

	return 0;
}

代码结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

classDiagram
    class Command {
      <<interface>>
      +execute() void
      +undo() void
    }

    class TextEditor {
      +insert(text: string) void
      +remove(length: size_t) void
      +getContent() string
    }

    class InsertCommand {
      -editor: TextEditor
      -text: string
      -lastInsertLength: size_t
      +execute() void
      +undo() void
    }

    class CommandInvoker {
      -history: stack~Command*~
      +executeCommand(command: Command*) void
      +undoCommand() void
    }

    InsertCommand --|> Command : implements
    InsertCommand o-- TextEditor : "1"
    CommandInvoker ..> Command : uses

解释器模式

解释器模式用于定义一个语言的语法表示，并通过解释器来解释语言中的句子。通常，解释器模式用于解析和执行简单的语法规则，如数学表达式、脚本语言或命令语言。

本质是指导我们去开发一个解释器,可以理解成一种语法解释器的开发框架

应用场景：编译器和解释器、配置文件解析器、查询语言解析器

• 当需要解释一种特定的语言时（例如计算器语法、SQL解析）
• 当想要将复杂的问题分解为更简单的子问题，并对这些子问题进行解释和执行

• 抽象表达式（AbstractExpression）: 声明一个interpret()方法，这个方法是所有具体表达式的接口。
  • 终结符表达式（TerminalExpression）: 实现与文法中的终结符相关的解释操作。
  • 非终结符表达式（NonterminalExpression）: 为文法中的非终结符实现解释操作。通常它会包含多个表达式。
• 上下文（Context）: 包含解释器之外的一些全局信息。
• 客户端（Client）: 构建或定义语法树，并将其传递给解释器进行解释。

解释器模式虽然强大，但在处理复杂语法时容易导致类爆炸，因此仅适用于相对简单的文法解析问题。

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

//表达式接口
#include <iostream>
#include <string>
#include <map>

// 表达式接口（抽象表达式）
class Expression {
public:
    virtual int interpret(const std::map<std::string, int>& context) = 0;
    virtual ~Expression() = default;
};

// 变量表达式：终结符表达式
class VariableExpression : public Expression {
    std::string name;
public:
    VariableExpression(const std::string& name) : name(name) {}

    int interpret(const std::map<std::string, int>& context) override {
        if (context.find(name) != context.end()) {
            return context.at(name);
        }
        return 0;
    }
};

// 加法表达式：非终结符表达式
class AddExpression : public Expression {
    Expression* left;
    Expression* right;
public:
    AddExpression(Expression* left, Expression* right) : left(left), right(right) {}

    int interpret(const std::map<std::string, int>& context) override {
        return left->interpret(context) + right->interpret(context);
    }

    ~AddExpression() {
        delete left;
        delete right;
    }
};

// 减法表达式：非终结符表达式
class SubtractExpression : public Expression {
    Expression* left;
    Expression* right;
public:
    SubtractExpression(Expression* left, Expression* right) : left(left), right(right) {}

    int interpret(const std::map<std::string, int>& context) override {
        return left->interpret(context) - right->interpret(context);
    }

    ~SubtractExpression() {
        delete left;
        delete right;
    }
};

//上下文环境
int main() {
    // 上下文，定义变量及其对应的值
    std::map<std::string, int> context;
    context["x"] = 5;
    context["y"] = 10;

    // 表达式：x + y - (x - y)
    Expression* expression = new SubtractExpression(
        new AddExpression(
            new VariableExpression("x"),
            new VariableExpression("y")
        ),
        new SubtractExpression(
            new VariableExpression("x"),
            new VariableExpression("y")
        )
    );

    int result = expression->interpret(context);
    std::cout << "Expression result: " << result << std::endl;

    delete expression;
    return 0;
}

总结:

• 解释器模式将复杂的表达式解析和解释分解为简单的子问题，每个子问题由终结符或非终结符来处理。
• 在需要解释某种特定语言的场景下（如数学表达式、脚本语言），解释器模式是一个非常合适的解决方案。

对于复杂的文法解析，解释器模式可能并不是最合适的选择。更常见的替代方案是编译器技术中的工具和技术，如解析器生成器（parser generators）或者采用更灵活的设计模式。

• 在复杂的语法树遍历场景下，可以考虑使用访问者模式（Visitor Pattern），它能让你在不修改对象结构的情况下，增加新的操作。访问者模式通过将操作从语法树的节点中分离出来，使得对语法树的扩展更加灵活。
• 组合模式允许你将对象组合成树状结构，以表示“部分-整体”的层次结构。通过这种方式，可以将复杂表达式的处理通过组合实现，而不是每个表达式都定义一个新类。

迭代器模式

迭代器模式用于提供一种方法，顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。迭代器模式将迭代的逻辑与容器解耦，使用迭代器对象来负责遍历操作。

迭代器模式的主要组成部分：

• 迭代器接口（Iterator Interface）: 定义访问和遍历元素的接口，通常包含first()、next()、isDone()、currentItem()等方法
• 具体迭代器（Concrete Iterator）: 实现迭代器接口，负责遍历聚合对象的具体元素。
• 聚合接口（Aggregate Interface）: 定义创建迭代器的接口，一般包含一个createIterator()方法。
• 具体聚合（Concrete Aggregate）: 实现聚合接口，存储元素并定义如何创建该聚合对象的迭代器。
• 客户端（Client）: 使用迭代器来遍历聚合对象中的元素，客户端只需要与迭代器交互，不需要知道聚合对象的内部结构。

迭代器模式的好处：