C++工厂方法模式怎么应用 抽象基类与具体产品实现方案

工厂方法模式通过将对象创建责任下放到子类，实现客户端与具体产品的解耦。1.定义抽象产品（product）作为所有具体产品的接口；2.实现具体产品（如concreteproducta、concreteproductb）；3.定义抽象创建者（creator），声明纯虚的工厂方法createproduct()；4.实现具体创建者（如concretecreatora、concretecreatorb），重写工厂方法返回具体产品实例；5.客户端通过抽象创建者接口操作产品，不依赖具体实现。该模式依托抽象基类和多态性，使系统遵循开闭原则，支持新增产品类型而不修改现有代码。当面对多种产品系列时，可通过多个工厂方法或转向抽象工厂模式处理；复杂创建逻辑可封装在工厂方法内部，包括参数化创建、资源初始化、依赖注入等。抽象基类在此模式中起到定义契约、强制多态、提供扩展点的关键作用。

C++的工厂方法模式，说白了，就是把创建对象的活儿，从直接调用构造函数，变成了通过一个“工厂”来生产。它最核心的理念，就是把产品创建的责任下放到子类去实现，这样一来，你的客户端代码就不用关心具体创建的是哪个产品了，它只跟一个抽象的“工厂”打交道，大大提升了系统的灵活性和可扩展性。这种模式，天然地就跟抽象基类和多态性绑定在一起，它们是实现这个模式的基石。

解决方案

要应用C++的工厂方法模式，我们通常会构建一个平行于产品等级结构的创建者等级结构。这听起来有点绕，但实际操作起来，核心就是抽象与具体的分离。

1. 定义抽象产品（Abstract Product）：这是一个纯虚类，它定义了所有具体产品必须遵循的接口。客户端代码会通过这个抽象接口来操作产品，而不是具体的实现。

   立即学习“C++免费学习笔记（深入）”；

   

   // 抽象产品接口
   class Product {
   public:
       virtual void use() = 0;
       virtual ~Product() = default; // 虚析构函数很重要
   };

   登录后复制

2. 实现具体产品（Concrete Product）：这些是抽象产品的具体实现。每个具体产品都实现了抽象产品接口中定义的方法。

   // 具体产品A
   class ConcreteProductA : public Product {
   public:
       void use() override {
           // 这里可以有一些具体的业务逻辑
           // 比如，打印日志，执行某个特定操作
           std::cout << "Using ConcreteProductA." << std::endl;
       }
   };
   
   // 具体产品B
   class ConcreteProductB : public Product {
   public:
       void use() override {
           std::cout << "Using ConcreteProductB." << std::endl;
       }
   };

   登录后复制

3. 定义抽象创建者（Abstract Creator）：这个类声明了工厂方法，它返回一个抽象产品类型的对象。这个工厂方法通常是一个纯虚函数，迫使子类去实现它。抽象创建者也可以包含一些与产品创建无关的通用操作。

   

   // 抽象创建者
   class Creator {
   public:
       // 工厂方法：返回一个抽象产品指针
       virtual Product* createProduct() = 0;
       virtual ~Creator() = default;
   
       // 也可以有其他操作，不一定只跟产品创建有关
       void someOperation() {
           Product* product = createProduct(); // 内部调用工厂方法
           product->use();
           delete product; // 注意内存管理
       }
   };

   登录后复制

4. 实现具体创建者（Concrete Creator）：每个具体创建者都重写了抽象创建者的工厂方法，负责实例化并返回一个特定的具体产品。它们知道要创建哪个具体产品，但客户端代码不需要知道。

   // 具体创建者A
   class ConcreteCreatorA : public Creator {
   public:
       Product* createProduct() override {
           // 这里可以有复杂的创建逻辑，比如读取配置，依赖注入等
           return new ConcreteProductA();
       }
   };
   
   // 具体创建者B
   class ConcreteCreatorB : public Creator {
   public:
       Product* createProduct() override {
           return new ConcreteProductB();
       }
   };

   登录后复制

5. 客户端使用：客户端代码通过抽象创建者接口来使用产品，而不是直接依赖于具体的产品或具体创建者。这使得系统非常灵活，因为你可以轻松地替换不同的具体创建者，而无需修改客户端代码。

   // 客户端代码示例
   void clientCode(Creator* creator) {
       // 客户端通过抽象接口与创建者交互
       // 不知道具体创建的是哪种产品
       creator->someOperation();
   }
   
   // main 函数中
   // Creator* creator1 = new ConcreteCreatorA();
   // clientCode(creator1); // 使用产品A
   // delete creator1;
   
   // Creator* creator2 = new ConcreteCreatorB();
   // clientCode(creator2); // 使用产品B
   // delete creator2;

   登录后复制

   通过这种方式，当需要引入新的产品类型时，你只需要添加新的具体产品类和新的具体创建者类，而无需修改现有的客户端代码或抽象接口，这完美地体现了“开闭原则”。

为什么工厂方法模式是解耦的利器？

在我看来，工厂方法模式之所以能成为解耦的强大工具，核心就在于它把“谁来创建对象”和“创建什么对象”这两件事彻底分开了。客户端代码只需要知道它需要一个“产品”接口，而不需要知道这个产品具体是哪种类型，更不需要知道它是由谁、如何创建出来的。

举个例子，如果你的程序需要根据用户的选择或者配置来加载不同类型的数据库连接器（MySQL、PostgreSQL等）。如果没有工厂方法，你的客户端代码里可能会充斥着大量的 if-else 或 switch 语句，根据不同的条件直接 new MySQLConnector() 或 new PostgreSQLConnector()。这样一来，每当你需要支持一个新的数据库类型，就得回去修改这些散落在各处的创建逻辑，这简直是维护的噩梦。

但有了工厂方法，客户端代码只跟一个抽象的 DBConnectorFactory 打交道，调用它的 createConnector() 方法。具体是 MySQLConnectorFactory 还是 PostgreSQLConnectorFactory 来实现这个方法，那都是工厂自己的事情。客户端根本不关心，它只知道它拿到了一个 DBConnector 接口的对象，然后就可以愉快地调用 connect()、query() 等方法了。这种“我只知道我要什么，不关心你怎么给我”的姿态，就是解耦的精髓。它把对具体实现的依赖，转化为了对抽象接口的依赖，系统自然就变得更健壮、更灵活了。

英特尔AI工具

英特尔AI与机器学习解决方案

70

查看详情

抽象基类在工厂方法中扮演了什么角色？

抽象基类在工厂方法模式中，简直就是“灵魂”一般的存在。它扮演的角色，远不止是提供一个接口那么简单，它更是整个多态体系的基石，确保了模式的可用性和扩展性。

首先，它定义了共同的契约。无论是产品抽象基类还是创建者抽象基类，它们都通过纯虚函数，明确地规定了所有派生类必须实现的功能。这就像是定下了一个规矩，所有“产品”都必须有 use() 方法，所有“创建者”都必须有 createProduct() 方法。这样，即使我们面对的是不同的具体产品或创建者，我们总能通过基类的指针或引用，以统一的方式去操作它们，这就是多态的魅力。

其次，它强制了多态的使用。因为抽象基类不能被直接实例化，你必须通过它的派生类来创建对象。而当你通过基类指针或引用去操作这些派生类对象时，你自然而然地就利用了C++的运行时多态性。工厂方法正是利用了这一点，它返回的是一个抽象产品指针，客户端代码拿到这个指针后，无需知道具体的类型，就能调用其方法，这极大地简化了客户端的逻辑。

再者，它为系统提供了扩展点。当需要增加新的产品类型时，我们只需要派生一个新的具体产品类，并实现抽象产品接口；同时，如果需要，也可以派生一个新的具体创建者类，来生产这种新产品。这个过程完全不需要修改原有的抽象基类或已有的具体类，这正是“开闭原则”的体现。抽象基类在这里就像一个稳定的“锚点”，无论上层应用如何变化，下层实现如何丰富，它都保持不变，提供了一个可靠的、可扩展的接口。没有抽象基类，工厂方法模式就失去了它的多态性，也就失去了其核心的解耦能力。

如何处理多种产品系列或复杂的创建逻辑？

当面临多种产品系列（比如，一个工厂不仅生产汽车，还生产摩托车，且它们有各自的抽象和具体实现），或者产品的创建逻辑本身就很复杂时，工厂方法模式依然有它的应对之道，尽管有时候它会演变成另一种模式——抽象工厂模式。

处理多种产品系列： 如果一个“工厂”需要生产多种不同“种类”的产品，而这些产品之间又没有直接的继承关系（比如，汽车和摩托车），那么你可能会发现你的抽象创建者类中会有多个工厂方法，每个方法负责创建一种不同类型的产品。

// 抽象产品A族
class Car { public: virtual void drive() = 0; virtual ~Car() = default; };
class Sedan : public Car { /* ... */ };
class SUV : public Car { /* ... */ };

// 抽象产品B族
class Motorcycle { public: virtual void ride() = 0; virtual ~Motorcycle() = default; };
class SportBike : public Motorcycle { /* ... */ };
class Cruiser : public Motorcycle { /* ... */ };

// 抽象创建者，包含多个工厂方法
class VehicleFactory {
public:
    virtual Car* createCar() = 0;
    virtual Motorcycle* createMotorcycle() = 0;
    virtual ~VehicleFactory() = default;
};

// 具体创建者，生产特定系列的汽车和摩托车
class LuxuryVehicleFactory : public VehicleFactory {
public:
    Car* createCar() override { return new Sedan(); }
    Motorcycle* createMotorcycle() override { return new SportBike(); }
};

class EconomyVehicleFactory : public VehicleFactory {
public:
    Car* createCar() override { return new SUV(); } // 假设SUV是经济型
    Motorcycle* createMotorcycle() override { return new Cruiser(); }
};

你看，这其实已经有点抽象工厂模式的影子了，抽象工厂模式就是由一系列工厂方法组成的。如果产品系列非常庞大且相互关联，那么直接转向抽象工厂模式会更清晰。但如果只是少数几种不相关的产品，在同一个工厂里提供多个工厂方法也未尝不可，这取决于你的设计偏好和实际需求。

处理复杂的创建逻辑： 工厂方法不仅仅是简单地 new 一个对象，它完全可以封装非常复杂的创建过程。这种复杂性可能体现在几个方面：

1. 参数化创建：工厂方法可以接受参数，根据参数的不同来决定创建哪个具体产品，或者如何初始化产品。

   // 抽象创建者，工厂方法接受参数
   class ConfigurableProductCreator {
   public:
       virtual Product* createProduct(const std::string& type) = 0;
       virtual ~ConfigurableProductCreator() = default;
   };
   
   class MyCreator : public ConfigurableProductCreator {
   public:
       Product* createProduct(const std::string& type) override {
           if (type == "A") {
               return new ConcreteProductA();
           } else if (type == "B") {
               return new ConcreteProductB();
           }
           // 错误处理或默认产品
           return nullptr;
       }
   };

   登录后复制

2. 资源管理与初始化：产品创建可能涉及到从文件读取配置、连接数据库、初始化复杂子组件等。这些逻辑都可以封装在工厂方法内部。比如，一个数据库连接工厂在创建连接对象时，可能需要读取配置文件中的IP、端口、用户名和密码。

3. 依赖注入：工厂方法内部可以负责解析和注入产品所需的依赖。这使得产品类本身更专注于其核心职责，而不用关心依赖的获取。

4. 缓存或对象池：为了性能优化，工厂方法可以检查是否已经存在一个可用的产品实例（比如从对象池中获取），而不是每次都创建新对象。如果池中没有，再创建新的。

5. 日志记录或监控：在产品创建前后，工厂方法可以加入日志记录、性能监控等非业务性功能，这有助于追踪和调试。

总之，工厂方法是一个强大的封装点。它把对象的创建细节完全隐藏起来，对外只暴露一个简单的接口。这意味着，无论创建过程有多么曲折、多么复杂，客户端代码都不需要知道，它只管调用工厂方法，然后拿到它想要的产品就行了。这正是软件设计中“关注点分离”的体现，让每个模块都只专注于自己的职责。

以上就是C++工厂方法模式怎么应用 抽象基类与具体产品实现方案的详细内容，更多请关注php中文网其它相关文章！