设计模式之创建型模式详解

设计模式

创建型模式

创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。

创建型模式在创建什么(What)，由谁创建(Who)，何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。

1.简单工厂模式（Simple Factory）（重要程度四颗星）

1.1 模式动机

考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按钮对象，此时，就可以使用简单工厂模式。

1.2 模式定义

简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

1.3 模式结构

简单工厂模式包含如下角色：

Factory：工厂角色
工厂角色负责实现创建所有实例的内部逻辑
Product：抽象产品角色
抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口
ConcreteProduct：具体产品角色
具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。

1.4 代码分析

#include <iostream>
#include <string>

// 抽象产品类
class Product {
public:
    virtual void operation() = 0;
};

// 具体产品类A
class ConcreteProductA : public Product {
public:
    void operation() override {
        std::cout << "ConcreteProductA operation" << std::endl;
    }
};

// 具体产品类B
class ConcreteProductB : public Product {
public:
    void operation() override {
        std::cout << "ConcreteProductB operation" << std::endl;
    }
};

// 简单工厂类
class SimpleFactory {
public:
    // 创建产品的静态方法
    static Product* createProduct(const std::string& type) {
        if (type == "A")
            return new ConcreteProductA();
        else if (type == "B")
            return new ConcreteProductB();
        else
            return nullptr;
    }
};

int main() {
    // 使用简单工厂创建产品
    Product* productA = SimpleFactory::createProduct("A");
    Product* productB = SimpleFactory::createProduct("B");

    // 调用产品的操作方法
    if (productA)
        productA->operation();
    if (productB)
        productB->operation();

    // 释放内存
    delete productA;
    delete productB;

    return 0;
}

1.5 模式分析

将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易。
在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过类名直接调用，而且只需要传入一个简单的参数即可，在实际开发中，还可以在调用时将所传入的参数保存在XML等格式的配置文件中，修改参数时无须修改任何源代码。
简单工厂模式最大的问题在于工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，这一点与开闭原则是相违背的。
简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。

1.6 简单工厂模式的优点

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

1.7 简单工厂模式的缺点

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

1.8 适用环境

工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。

2.工厂方法模式（Factory Method）（重要程度五颗星）

2.1 模式动机

现在对该系统进行修改，不再设计一个按钮工厂类来统一负责所有产品的创建，而是将具体按钮的创建过程交给专门的工厂子类去完成，我们先定义一个抽象的按钮工厂类，再定义具体的工厂类来生成圆形按钮、矩形按钮、菱形按钮等，它们实现在抽象按钮工厂类中定义的方法。这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的产品，如果出现新的按钮类型，只需要为这种新类型的按钮创建一个具体的工厂类就可以获得该新按钮的实例，这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性，更加符合“开闭原则”。

2.2 模式定义

工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

2.3模式结构

工厂方法模式包含如下角色：

Product：抽象产品
ConcreteProduct：具体产品
Factory：抽象工厂
ConcreteFactory：具体工厂

2.4 代码分析

#include <iostream>
#include <string>

// 抽象产品类
class Product {
public:
    virtual void operation() = 0;
};

// 具体产品类A
class ConcreteProductA : public Product {
public:
    void operation() override {
        std::cout << "ConcreteProductA operation" << std::endl;
    }
};

// 具体产品类B
class ConcreteProductB : public Product {
public:
    void operation() override {
        std::cout << "ConcreteProductB operation" << std::endl;
    }
};

// 抽象工厂类
class Factory {
public:
    virtual Product* createProduct() = 0;
};

// 具体工厂类A，用于创建具体产品类A
class ConcreteFactoryA : public Factory {
public:
    Product* createProduct() override {
        return new ConcreteProductA();
    }
};

// 具体工厂类B，用于创建具体产品类B
class ConcreteFactoryB : public Factory {
public:
    Product* createProduct() override {
        return new ConcreteProductB();
    }
};

int main() {
    // 创建具体工厂类A的对象
    Factory* factoryA = new ConcreteFactoryA();
    // 使用具体工厂A创建产品对象
    Product* productA = factoryA->createProduct();
    // 调用产品A的操作方法
    productA->operation();

    // 创建具体工厂类B的对象
    Factory* factoryB = new ConcreteFactoryB();
    // 使用具体工厂B创建产品对象
    Product* productB = factoryB->createProduct();
    // 调用产品B的操作方法
    productB->operation();

    // 释放内存
    delete factoryA;
    delete productA;
    delete factoryB;
    delete productB;

    return 0;
}

2.5 模式分析

工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪一个产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

2.6 工厂方法模式的优点

在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。

2.7 工厂方法模式的缺点

在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

2.8 适用环境

在以下情况下可以使用工厂方法模式：

一个类不知道它所需要的对象的类：在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。
一个类通过其子类来指定创建哪个对象：== 在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象==，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。
将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。

2.9 模式扩展

使用多个工厂方法：在抽象工厂角色中可以定义多个工厂方法，从而使具体工厂角色实现这些不同的工厂方法，这些方法可以包含不同的业务逻辑，以满足对不同的产品对象的需求。
产品对象的重复使用：工厂对象将已经创建过的产品保存到一个集合（如数组、List等）中，然后根据客户对产品的请求，对集合进行查询。如果有满足要求的产品对象，就直接将该产品返回客户端；如果集合中没有这样的产品对象，那么就创建一个新的满足要求的产品对象，然后将这个对象在增加到集合中，再返回给客户端。
多态性的丧失和模式的退化：如果工厂仅仅返回一个具体产品对象，便违背了工厂方法的用意，发生退化，此时就不再是工厂方法模式了。一般来说，工厂对象应当有一个抽象的父类型，如果工厂等级结构中只有一个具体工厂类的话，抽象工厂就可以省略，也将发生了退化。当只有一个具体工厂，在具体工厂中可以创建所有的产品对象，并且工厂方法设计为静态方法时，工厂方法模式就退化成简单工厂模式

3.抽象工厂模式（Abstract Factory）（重要程度五颗星）

3.1 模式动机

在工厂方法模式中具体工厂负责生产具体的产品，每一个具体工厂对应一种具体产品，工厂方法也具有唯一性，一般情况下，一个具体工厂中只有一个工厂方法或者一组重载的工厂方法。但是有时候我们需要一个工厂可以提供多个产品对象，而不是单一的产品对象。

为了更清晰地理解工厂方法模式，需要先引入两个概念：
- 产品等级结构：产品等级结构即产品的继承结构，如一个抽象类是电视机，其子类有海尔电视机、海信电视机、TCL电视机，则抽象电视机与具体品牌的电视机之间构成了一个产品等级结构，抽象电视机是父类，而具体品牌的电视机是其子类。
- 产品族：在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中。
当系统所提供的工厂所需生产的具体产品并不是一个简单的对象，而是多个位于不同产品等级结构中属于不同类型的具体产品时需要使用抽象工厂模式。
抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。
抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建。当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、有效率。

3.2. 模式定义

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。

3.3 模式结构

抽象工厂模式包含如下角色：

AbstractFactory：抽象工厂
ConcreteFactory：具体工厂
AbstractProduct：抽象产品
Product：具体产品

3.4 代码分析

#include <iostream>
#include <string>

// 抽象产品类A
class AbstractProductA {
public:
    virtual void operationA() = 0;
};

// 具体产品类A1
class ConcreteProductA1 : public AbstractProductA {
public:
    void operationA() override {
        std::cout << "ConcreteProductA1 operationA" << std::endl;
    }
};

// 具体产品类A2
class ConcreteProductA2 : public AbstractProductA {
public:
    void operationA() override {
        std::cout << "ConcreteProductA2 operationA" << std::endl;
    }
};

// 抽象产品类B
class AbstractProductB {
public:
    virtual void operationB() = 0;
};

// 具体产品类B1
class ConcreteProductB1 : public AbstractProductB {
public:
    void operationB() override {
        std::cout << "ConcreteProductB1 operationB" << std::endl;
    }
};

// 具体产品类B2
class ConcreteProductB2 : public AbstractProductB {
public:
    void operationB() override {
        std::cout << "ConcreteProductB2 operationB" << std::endl;
    }
};

// 抽象工厂类
class AbstractFactory {
public:
    virtual AbstractProductA* createProductA() = 0;
    virtual AbstractProductB* createProductB() = 0;
};

// 具体工厂类1，负责创建产品A1和产品B1
class ConcreteFactory1 : public AbstractFactory {
public:
    AbstractProductA* createProductA() override {
        return new ConcreteProductA1();
    }

    AbstractProductB* createProductB() override {
        return new ConcreteProductB1();
    }
};

// 具体工厂类2，负责创建产品A2和产品B2
class ConcreteFactory2 : public AbstractFactory {
public:
    AbstractProductA* createProductA() override {
        return new ConcreteProductA2();
    }

    AbstractProductB* createProductB() override {
        return new ConcreteProductB2();
    }
};

int main() {
    // 创建具体工厂类1的对象
    AbstractFactory* factory1 = new ConcreteFactory1();
    // 使用具体工厂1创建产品A1和产品B1
    AbstractProductA* productA1 = factory1->createProductA();
    AbstractProductB* productB1 = factory1->createProductB();
    // 调用产品A1和产品B1的操作方法
    productA1->operationA();
    productB1->operationB();

    // 创建具体工厂类2的对象
    AbstractFactory* factory2 = new ConcreteFactory2();
    // 使用具体工厂2创建产品A2和产品B2
    AbstractProductA* productA2 = factory2->createProductA();
    AbstractProductB* productB2 = factory2->createProductB();
    // 调用产品A2和产品B2的操作方法
    productA2->operationA();
    productB2->operationB();

    // 释放内存
    delete factory1;
    delete productA1;
    delete productB1;
    delete factory2;
    delete productA2;
    delete productB2;

    return 0;
}

3.5 抽象工厂模式的优点

抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用。
当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式。
增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”。

3.6 抽象工厂模式的缺点

在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便。
开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）。

3.7 适用环境

在以下情况下可以使用抽象工厂模式：

产品族概念存在：当产品对象存在多个系列，且这些系列中的产品对象之间存在一定的关联或依赖关系时，抽象工厂模式非常适用。例如，汽车制造业中的零部件（发动机、轮胎、座椅等）就可以组成不同的产品族。
系统独立于产品的创建和组合：抽象工厂模式将产品的创建和组合从客户端代码中分离出来，使得客户端代码可以独立于具体产品类，并与其抽象接口进行交互。这样可以降低系统的耦合度，提高了系统的灵活性和可维护性。
需要跨越多个平台或多个产品族：如果系统需要在不同的平台上运行，或者需要支持多个不同的产品系列，抽象工厂模式可以为每个平台或产品族提供一个独立的工厂类，从而使得系统具备更好的可扩展性和可移植性。
需要满足一致性要求：抽象工厂模式保证了同一产品族内的所有产品对象之间的兼容性，从而可以确保系统中的不同对象能够正常协作。这在一些要求产品之间高度一致性的系统中非常重要。
需要动态切换产品族：== 在运行时动态切换不同的产品族是抽象工厂模式的一个重要应用场景==。通过使用抽象工厂模式，可以在不修改客户端代码的情况下，更改系统使用的产品族，从而实现了系统行为的灵活变化。

3.8 模式应用

图形界面工具包（GUI）： GUI 库通常需要在不同的操作系统上运行，并且需要支持多种外观风格。抽象工厂模式可以用来创建不同操作系统下的窗口、按钮、菜单等组件，同时保证它们之间的风格统一。
数据库访问库：数据库访问库需要根据不同的数据库提供商（如 MySQL、Oracle、SQL Server 等）提供相应的数据库连接、命令、事务等对象。抽象工厂模式可以用来创建不同数据库产品族的对象，使得客户端代码可以方便地切换不同的数据库提供商。
加密算法库：加密算法库需要支持多种加密算法（如 DES、AES、RSA 等），并且可能需要在不同的平台上运行。抽象工厂模式可以用来创建不同算法家族的加密算法对象，从而使得系统可以灵活地使用不同的加密算法。
汽车制造业：在汽车制造业中，不同的汽车品牌会生产各种不同类型的汽车（轿车、SUV、跑车等），每种类型的汽车又需要配备不同的零部件（发动机、轮胎、座椅等）。抽象工厂模式可以用来创建不同品牌的汽车以及它们所需的零部件。
电子产品制造业：电子产品制造业中的手机、平板电脑、笔记本电脑等产品，它们都需要由不同的供应商提供不同的硬件组件（处理器、内存、屏幕等）。抽象工厂模式可以用来创建不同品牌的电子产品以及它们所需的硬件组件。

3.9 模式扩展

“开闭原则”的倾斜性

“开闭原则”要求系统对扩展开放，对修改封闭，通过扩展达到增强其功能的目的。对于涉及到多个产品族与多个产品等级结构的系统，其功能增强包括两方面：
1. 增加产品族：对于增加新的产品族，工厂方法模式很好的支持了“开闭原则”，对于新增加的产品族，只需要对应增加一个新的具体工厂即可，对已有代码无须做任何修改。
2. 增加新的产品等级结构：对于增加新的产品等级结构，需要修改所有的工厂角色，包括抽象工厂类，在所有的工厂类中都需要增加生产新产品的方法，不能很好地支持“开闭原则”。
抽象工厂模式的这种性质称为“开闭原则”的倾斜性，抽象工厂模式以一种倾斜的方式支持增加新的产品，它为新产品族的增加提供方便，但不能为新的产品等级结构的增加提供这样的方便。

工厂模式的退化

当抽象工厂模式中每一个具体工厂类只创建一个产品对象，也就是只存在一个产品等级结构时，抽象工厂模式退化成工厂方法模式；当工厂方法模式中抽象工厂与具体工厂合并，提供一个统一的工厂来创建产品对象，并将创建对象的工厂方法设计为静态方法时，工厂方法模式退化成简单工厂模式。

4.建造者模式（Builder）（重要程度两颗星）

4.1 模式动机

无论是在现实世界中还是在软件系统中，都存在一些复杂的对象，它们拥有多个组成部分，如汽车，它包括车轮、方向盘、发送机等各种部件。而对于大多数用户而言，无须知道这些部件的装配细节，也几乎不会使用单独某个部件，而是使用一辆完整的汽车，可以通过建造者模式对其进行设计与描述，建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

在软件开发中，也存在大量类似汽车一样的复杂对象，它们拥有一系列成员属性，这些成员属性中有些是引用类型的成员对象。而且在这些复杂对象中，还可能存在一些限制条件，如某些属性没有赋值则复杂对象不能作为一个完整的产品使用；有些属性的赋值必须按照某个顺序，一个属性没有赋值之前，另一个属性可能无法赋值等。

复杂对象相当于一辆有待建造的汽车，而对象的属性相当于汽车的部件，建造产品的过程就相当于组合部件的过程。由于组合部件的过程很复杂，因此，这些部件的组合过程往往被“外部化”到一个称作建造者的对象里，建造者返还给客户端的是一个已经建造完毕的完整产品对象，而用户无须关心该对象所包含的属性以及它们的组装方式，这就是建造者模式的模式动机。

4.2 模式定义

造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。建造者模式属于对象创建型模式。根据中文翻译的不同，建造者模式又可以称为生成器模式。

4.3 模式结构

建造者模式包含如下角色：

Builder：抽象建造者
ConcreteBuilder：具体建造者
Director：指挥者
Product：产品角色

4.4 代码分析

#include <iostream>
#include <string>
#include <memory>

// 产品类
class Pizza {
public:
    void setDough(const std::string& dough) {
        dough_ = dough;
    }

    void setSauce(const std::string& sauce) {
        sauce_ = sauce;
    }

    void setTopping(const std::string& topping) {
        topping_ = topping;
    }

    void display() const {
        std::cout << "Pizza with " << dough_ << " dough, " << sauce_ << " sauce and " << topping_ << " topping." << std::endl;
    }

private:
    std::string dough_;
    std::string sauce_;
    std::string topping_;
};

// 抽象建造者类
class PizzaBuilder {
public:
    virtual ~PizzaBuilder() {}
    virtual void buildDough() = 0;
    virtual void buildSauce() = 0;
    virtual void buildTopping() = 0;
    virtual std::unique_ptr<Pizza> getPizza() = 0;
};

// 具体建造者类A
class HawaiianPizzaBuilder : public PizzaBuilder {
public:
    void buildDough() override {
        pizza_->setDough("cross");
    }

    void buildSauce() override {
        pizza_->setSauce("mild");
    }

    void buildTopping() override {
        pizza_->setTopping("ham and pineapple");
    }

    std::unique_ptr<Pizza> getPizza() override {
        return std::move(pizza_);
    }

private:
    std::unique_ptr<Pizza> pizza_{std::make_unique<Pizza>()};
};

// 具体建造者类B
class SpicyPizzaBuilder : public PizzaBuilder {
public:
    void buildDough() override {
        pizza_->setDough("pan baked");
    }

    void buildSauce() override {
        pizza_->setSauce("hot");
    }

    void buildTopping() override {
        pizza_->setTopping("pepperoni and salami");
    }

    std::unique_ptr<Pizza> getPizza() override {
        return std::move(pizza_);
    }

private:
    std::unique_ptr<Pizza> pizza_{std::make_unique<Pizza>()};
};

// 指挥者类
class Cook {
public:
    void setPizzaBuilder(std::unique_ptr<PizzaBuilder> builder) {
        pizza_builder_ = std::move(builder);
    }

    std::unique_ptr<Pizza> getPizza() {
        return pizza_builder_->getPizza();
    }

    void constructPizza() {
        pizza_builder_->buildDough();
        pizza_builder_->buildSauce();
        pizza_builder_->buildTopping();
    }

private:
    std::unique_ptr<PizzaBuilder> pizza_builder_;
};

int main() {
    Cook cook;

    // 制作夏威夷披萨
    cook.setPizzaBuilder(std::make_unique<HawaiianPizzaBuilder>());
    cook.constructPizza();
    std::unique_ptr<Pizza> hawaiian_pizza = cook.getPizza();
    std::cout << "Hawaiian Pizza:" << std::endl;
    hawaiian_pizza->display();

    // 制作辣味披萨
    cook.setPizzaBuilder(std::make_unique<SpicyPizzaBuilder>());
    cook.constructPizza();
    std::unique_ptr<Pizza> spicy_pizza = cook.getPizza();
    std::cout << "Spicy Pizza:" << std::endl;
    spicy_pizza->display();

    return 0;
}

4.5 模式分析

抽象建造者类中定义了产品的创建方法和返回方法;

建造者模式的结构中还引入了一个指挥者类Director，该类的作用主要有两个：一方面它隔离了客户与生产过程；另一方面它负责控制产品的生成过程。指挥者针对抽象建造者编程，客户端只需要知道具体建造者的类型，即可通过指挥者类调用建造者的相关方法，返回一个完整的产品对象

在客户端代码中，无须关心产品对象的具体组装过程，只需确定具体建造者的类型即可，建造者模式将复杂对象的构建与对象的表现分离开来，这样使得同样的构建过程可以创建出不同的表现。

4.6 建造者模式优点

在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。
可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”。

4.7 建造者模式缺点

建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

4.8 适用环境

在以下情况下可以使用建造者模式：

需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
对象的创建过程独立于创建该对象的类。在建造者模式中引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类中。
隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

4.9 模式扩展

建造者模式的简化:

省略抽象建造者角色：如果系统中只需要一个具体建造者的话，可以省略掉抽象建造者。
省略指挥者角色：在具体建造者只有一个的情况下，如果抽象建造者角色已经被省略掉，那么还可以省略指挥者角色，让Builder角色扮演指挥者与建造者双重角色。

建造者模式与抽象工厂模式的比较:

与抽象工厂模式相比，建造者模式返回一个组装好的完整产品，而抽象工厂模式返回一系列相关的产品，这些产品位于不同的产品等级结构，构成了一个产品族。
在抽象工厂模式中，客户端实例化工厂类，然后调用工厂方法获取所需产品对象，而在建造者模式中，客户端可以不直接调用建造者的相关方法，而是通过指挥者类来指导如何生成对象，包括对象的组装过程和建造步骤，它侧重于一步步构造一个复杂对象，返回一个完整的对象。
如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车。

5.原型模式（Factory Method）（重要程度三颗星）

5.1 模式动机

在软件开发过程中，有时候需要创建一个新的对象，但是新对象的属性和某个已有对象非常相似，甚至是一模一样的，只是在某些属性上有所不同。传统的做法是通过调用对象的构造函数来创建新对象，然后手动设置不同的属性值。但是，如果对象的创建成本较高，或者对象的初始化过程比较复杂，这种方式会带来不少麻烦。此外，在某些情况下，我们可能需要动态地创建对象，并且不知道具体对象类型。这时候，如果能够直接复制现有对象来创建新对象，无疑会更加方便和高效。

原型模式就是为了解决这些问题而诞生的。它提供了一种对象创建的方式，通过复制现有对象来创建新对象，而无需显式地使用构造函数。这样一来，我们就可以在运行时动态地克隆对象，并且可以根据需要修改新对象的属性值，而无需重新创建对象或了解对象的具体类型。原型模式可以提高对象的创建效率，避免重复地进行初始化操作，同时提高系统的灵活性和可扩展性。

5.2 模式定义

原型模式是一种创建型设计模式，它允许通过复制现有对象来创建新对象，而无需显式地使用构造函数。该模式涉及实现一个原型接口，以便在运行时动态地克隆对象。

原型模式的核心概念是原型接口，它定义了一个克隆自身的接口方法，具体的对象类实现这个接口方法来实现对象的复制。客户端通过调用原型接口的克隆方法来创建新对象，而无需知道具体对象的类型。
在原型模式中，每个具体对象类都有一个对应的原型类，该原型类是具体对象的抽象，负责实现克隆方法来复制自身。客户端通过调用原型类的克隆方法来复制具体对象，然后可以根据需要修改新对象的属性值。
原型模式可以提高对象的创建效率，避免重复地进行初始化操作，同时可以在运行时动态地克隆对象，而不必知道具体的对象类型。因此，原型模式是一种非常灵活和高效的对象创建方式，适用于对象创建成本较高或对象初始化过程复杂的场景。

5.3 模式结构

Prototype（原型接口）：定义了一个克隆自身的接口。
ConcretePrototype（具体原型类）：实现了原型接口，实现克隆方法来复制自身。
Client（客户端）：使用原型对象克隆方法创建新对象的客户端。

5.4 代码分析

// 原型接口
class Prototype {
public:
    virtual Prototype* clone() = 0;
    virtual void setProperty(int property) = 0;
    virtual int getProperty() const = 0;
};

// 具体原型类
class ConcretePrototype : public Prototype {
public:
    ConcretePrototype(int property) : property_(property) {}

    Prototype* clone() override {
        return new ConcretePrototype(*this);
    }

    void setProperty(int property) override {
        property_ = property;
    }

    int getProperty() const override {
        return property_;
    }

private:
    int property_;
};

// 客户端
int main() {
    ConcretePrototype prototype(100);
    Prototype* clonedPrototype = prototype.clone();

    clonedPrototype->setProperty(200);

    std::cout << "Original Property: " << prototype.getProperty() << std::endl;
    std::cout << "Cloned Property: " << clonedPrototype->getProperty() << std::endl;

    delete clonedPrototype;

    return 0;
}

5.5 模式分析

原型模式的核心思想是通过复制现有对象来创建新对象，而无需显式地使用构造函数。这种方式使得客户端可以在运行时动态地创建新对象，并且可以根据需要修改新对象的属性值，而无需重新创建对象或了解对象的具体类型。以下是原型模式的一些关键点和分析：

对象复制： 原型模式的关键在于实现对象的克隆方法，该方法将现有对象的状态复制到新创建的对象中。这种方式可以避免重复地进行对象初始化操作，提高了对象创建的效率。
动态创建： 原型模式允许在运行时动态地克隆对象，并且可以根据需要修改新对象的属性值。客户端无需知道具体对象的类型，只需要调用原型对象的克隆方法即可创建新对象。
灵活性和可扩展性： 原型模式提高了系统的灵活性和可扩展性。客户端可以根据需要克隆不同类型的对象，并且可以根据需要修改新对象的属性值，而无需修改现有的代码。
对象状态： 在原型模式中，克隆方法通常会执行浅拷贝或深拷贝操作，以确保新对象和原始对象之间的状态不会互相影响。这样可以保持对象的一致性，避免出现意外的行为。
原型管理器： 在一些应用中，原型模式可以结合原型管理器来管理原型对象的注册、复制和获取操作。原型管理器可以帮助客户端更方便地使用原型对象，提高了系统的易用性和可维护性。

5.6 原型模式优点

减少对象初始化成本： 原型模式通过复制现有对象来创建新对象，避免了重复地进行对象初始化操作，降低了对象创建的成本。
动态创建对象： 原型模式允许在运行时动态地克隆对象，并且可以根据需要修改新对象的属性值。这种方式使得客户端可以灵活地创建和修改对象，而无需知道具体对象的类型。
简化对象创建过程： 原型模式将对象的创建和复制操作分离开来，使得对象的创建过程更加简单和直观。客户端只需要调用原型对象的克隆方法即可创建新对象，而无需关心对象的初始化细节。
提高系统灵活性和可扩展性： 原型模式提供了一种灵活和高效的对象创建方式，可以根据需要克隆不同类型的对象，并且可以根据需要修改新对象的属性值，而无需修改现有的代码。这样可以提高系统的灵活性和可扩展性，使得系统更易于维护和扩展。
保持对象一致性： 在原型模式中，克隆方法通常会执行浅拷贝或深拷贝操作，以确保新对象和原始对象之间的状态不会互相影响。这样可以保持对象的一致性，避免出现意外的行为。

5.7 原型模式缺点

深拷贝问题： 如果对象包含了其他对象的引用，那么在进行克隆时需要进行深拷贝操作，否则可能会导致对象状态的不一致。深拷贝操作的实现可能会比较复杂，需要考虑对象的所有状态及其相互关系。
复杂性： 在某些情况下，如果对象的复制操作比较复杂，那么实现起来可能会比较困难。需要考虑对象的所有状态及其相互关系，以确保新对象和原始对象之间的状态一致性。
不适用于所有场景： 原型模式适用于对象创建成本较高或对象初始化过程复杂的场景，但并不适用于所有场景。在一些简单的场景中，直接使用构造函数来创建对象可能会更加简单和直观。
对于多线程环境的考虑： 如果在多线程环境中使用原型模式，可能会存在对象状态不一致的问题。在进行对象复制操作时，需要考虑多线程环境下的并发访问，以避免出现意外的行为。

5.8适用环境

原型模式适用于以下情况：

对象的创建成本较高，或者对象初始化过程比较复杂，例如需要进行数据库查询、文件读写或网络通信等操作。
需要动态地创建对象，并且不知道具体对象类型的情况下，可以使用原型模式来克隆现有对象。
需要避免由于对象初始化导致的性能损耗，例如在大量创建对象的情况下，可以使用原型模式来复制现有对象，而无需重新创建对象。
对象的状态需要保持一致性，并且需要避免对象之间的相互影响，可以使用原型模式来实现对象的深拷贝。

5.9 模式扩展

在一些应用中，原型模式可以结合原型管理器来管理原型对象的注册、复制和获取操作，以进一步提高系统的灵活性和可扩展性。原型管理器可以帮助客户端更方便地使用原型对象，并且可以避免客户端直接与具体原型类耦合。

另外，原型模式还可以与其他设计模式结合使用，以实现更复杂的功能。例如，原型模式可以与工厂方法模式结合使用，以便根据原型对象动态地创建新对象。原型模式还可以与享元模式结合使用，以共享部分状态，并减少内存消耗。总的来说，原型模式是一种非常灵活和高效的对象创建方式，可以根据需要灵活地组合和扩展，以满足不同的应用场景。

6.单例模式（Singleton）（重要程度四颗星）

6.1 模式动机

对于系统中的某些类来说，只有一个实例很重要，例如，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；一个系统只能有一个窗口管理器或文件系统；一个系统只能有一个计时工具或ID（序号）生成器。

如何保证一个类只有一个实例并且这个实例易于被访问呢？定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象。

一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。

6.2 模式定义

单例模式(Singleton Pattern)：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。

单例模式的要点有三个：一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。

6.3 模式结构

单例模式包含如下角色：

Singleton：单例

6.4 代码分析

#include <iostream>

class Singleton {
public:
    // 获取单例实例的静态方法
    static Singleton* getInstance() {
        // 如果实例不存在，则创建实例
        if (instance_ == nullptr) {
            instance_ = new Singleton();
        }
        // 返回单例实例
        return instance_;
    }

    // 删除拷贝构造函数和赋值运算符重载，确保单例对象不能被拷贝和赋值
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    // 单例对象的其他方法
    void showMessage() {
        std::cout << "Hello, I am a singleton object!" << std::endl;
    }

private:
    // 私有化构造函数，确保单例对象不能通过构造函数外部创建
    Singleton() {}

    // 单例对象的静态指针，用于保存单例实例
    static Singleton* instance_;
};

// 静态成员变量需要在类外部进行初始化
Singleton* Singleton::instance_ = nullptr;

int main() {
    // 获取单例实例并调用方法
    Singleton* singleton = Singleton::getInstance();
    singleton->showMessage();

    return 0;
}

6.5 模式分析

单例模式的目的是保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例模式包含的角色只有一个，就是单例类——Singleton。单例类拥有一个私有构造函数，确保用户无法通过new关键字直接实例化它。除此之外，该模式中包含一个静态私有成员变量与静态公有的工厂方法，该工厂方法负责检验实例的存在性并实例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建。

在单例模式的实现过程中，需要注意如下三点：

单例类的构造函数为私有；
提供一个自身的静态私有成员变量；
提供一个公有的静态工厂方法。

6.6 单例模式优点

提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它，并为设计及开发团队提供了共享的概念。
由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。
允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例。

6.7 单例模式缺点

由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致对象状态的丢失。

6.8 适用环境

在以下情况下可以使用单例模式：

系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器，或者需要考虑资源消耗太大而只允许创建一个对象。
客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来，如果一个类可以有几个实例共存，就需要对单例模式进行改进，使之成为多例模式

6.9 模式拓展

单例模式与全局访问点：单例模式通常被用作全局访问点，因为它提供了一种在整个应用程序中访问单例对象的简单方法。虽然全局访问点能够方便地访问对象，但也容易导致对象的耦合性增加，降低代码的可维护性和可测试性。
单例模式与线程安全性：在多线程环境中，单例模式需要考虑线程安全性。常见的解决方案包括懒加载、双重检查锁定、静态局部变量等。确保在多线程环境中只有一个实例存在是很重要的，以避免竞态条件和数据不一致性。
单例模式与依赖注入：虽然单例模式本身不涉及依赖注入，但在一些情况下可以与依赖注入框架结合使用，以管理单例对象的创建和生命周期。依赖注入框架可以帮助解决对象之间的依赖关系，提高代码的可维护性和可测试性。
单例模式与序列化与反序列化：在某些情况下，需要将单例对象序列化到磁盘或网络中，并在需要时反序列化成对象。在进行序列化和反序列化时，需要特别注意单例对象的唯一性，以避免创建多个实例。
单例模式与资源管理：单例模式可以用于管理应用程序中的共享资源，例如数据库连接、线程池、日志记录器等。通过单例模式，可以确保资源在整个应用程序中只被创建和使用一次，避免资源泄漏和浪费。
单例模式与测试：单例模式可能会影响代码的可测试性，因为它引入了全局状态。为了方便测试，可以考虑将依赖注入和依赖反转等技术与单例模式结合使用，以便在测试中使用模拟对象。
单例模式与并发性能：在高并发环境中，单例模式可能会成为性能瓶颈，因为所有线程都必须竞争访问同一个对象。在设计单例模式时，需要考虑到并发性能，选择合适的线程安全方案。