工厂模式-C++实现

工厂模式是一个创建型设计模式，即“对象创建模式”，通过这种模式可以绕开new，来避免对象创建过程中，也就是new的方法造成的紧耦合，从而支持对象创建的稳定。

工厂模式中引入了一个工厂类，该工厂负责根据客户端的请求创建相应的对象案例，客户端只需要通过工厂类获取对象，不需要之间调用具体对象的构造函数。

工厂模式有四个角色：抽象产品、具体产品、抽象工厂、具体工厂。

举例：
假设我们现在要创建一个图形库，支持绘制矩形和圆形两种形状。

// 抽象产品
class IShape
{
public:virtual ~IShape() {}virtual void Draw() = 0;
};// 具体产品-矩形
class Rectange: public IShape
{
public:virtual void Draw() override{std::cout << "绘制矩形" << std::endl;}
};// 具体产品-圆形
class Circle: public IShape
{
public:virtual void Draw() override{std::cout << "绘制圆形" << std::endl;}
};// 抽象工厂
class IFactory
{
public:virtual ~IFactory() {}virtual std::shared_ptr<IShape> CreateShape() = 0;
};// 具体工厂 - 创建圆形
class CircleFactory: public IFactory
{
public:virtual std::shared_ptr<IShape> CreateShape() override{return std::make_shared<Circle>();}
};// 具体工厂 - 创建矩形
class RactangeFactory: public IFactory
{
public:virtual std::shared_ptr<IShape> CreateShape() override{return std::make_shared<Rectange>();}
};

void TestFactory()
{// 创建矩形工厂std::shared_ptr<IFactory> rac_factory = std::make_shared<RactangeFactory>();// 创建圆形工厂std::shared_ptr<IFactory> cir_factory = std::make_shared<CircleFactory>();// 创建矩形产品std::shared_ptr<IShape> ractange = rac_factory->CreateShape();// 创建圆形产品std::shared_ptr<IShape> circle = cir_factory->CreateShape();// 绘制矩形ractange->Draw();// 绘制圆形circle->Draw();
}int main()
{// 策略模式用法// TestStrategy();// TestObserver();// TestDecorator();// TestBridge();TestFactory();system("pause");return 0;
}

抽象图形类 IShape 定义了图形的抽象接口，具体的图形类 Circle 和 Rectangle 继承自 Shape，实现了抽象接口，并实现了各自的绘制逻辑。

抽象工厂类 IFactory 定义了创建图形对象的抽象接口，具体的工厂类 CircleFactory 和 RectangleFactory 继承自 IFactory，实现了创建图形对象的具体逻辑。

在客户端代码中，分别通过 CircleFactory 和 RectangleFactory 工厂类来创建圆形和矩形对象，并调用各自的 Draw() 方法，共同完成图形的绘制过程。

工厂模式的主要优点包括：

• 将对象的创建与使用分离，使客户端代码只依赖于抽象工厂和抽象产品，而不依赖于具体产品。
• 可以很方便地扩展和修改具体产品的创建过程，而对客户端代码没有影响。
• 符合开闭原则，即对修改关闭，对扩展开放。
• 遵循依赖倒置原则，即
  1、高模块不应该依赖低模块，两者都应该依赖抽象。
  2、抽象不应该依赖具体实现，具体实现应该依赖抽象。

简单来说，依赖倒置原则的核心思想是通过创建抽象接口或者抽象类来作为模块之间的依赖（比如上面代码中的抽象产品和抽象工厂），而不是依赖具体的实现类。

通过遵循依赖倒置原则，我们能够实现以下几个好处：

• 提高代码的灵活性和可扩展性：通过依赖于抽象而不是具体实现，我们可以方便地替换底层模块，以及添加新的实现来满足不同的需求，而不需要修改高层模块的代码。
• 减少模块间的耦合度：模块间的依赖关系通过抽象接口进行解耦，使得模块的改动不会对其他模块产生过多的影响。
• 更好的代码维护性：由于模块间的依赖关系被明确地定义在抽象层面上，我们可以更容易理解和维护代码。