C++ 工厂模式/抽象工厂剖析

最新推荐文章于 2025-03-29 16:52:35 发布

攻城狮CSU

最新推荐文章于 2025-03-29 16:52:35 发布

阅读量299

点赞数

文章标签：个人开发性能优化 c++ qt

本文链接：https://blog.youkuaiyun.com/zzwwgg1984/article/details/123756298

版权

本文介绍了面向对象编程中的三种设计模式：简单工厂、工厂方法及抽象工厂。通过游戏中的动物角色实例，展示了如何利用这些模式来实现多态并提高代码的扩展性和可维护性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

正文

在面向对象的编程中，一般通过继承和虚函数来提供抽象能力，多态让程序在执行期，调用者只需要看到父类类型，而不需要关心继承的子类类型。举个例子: 比如有个游戏，里面的游戏的活动对象为动物，比如有老虎和猫，会对主人公进行攻击。那么可能会实现为如下：

代码如下：

class Animal
{
public:
virtual void Attack() = 0;
};
class Tiger : public Animal
{
public:
virtual void Attack() { std::cout << "Tiger Attack!" << std::endl; };
};
class Cat : public Animal
{
public:
virtual void Attack() { std::cout << "Cat Attack!" << std::endl; };
};

那如果在外面有个方法，并不需要关心具体的对象类型，只需要使用基类Animal的指针去操作对象, 利用多态机制变可以实现对具体对象类型的方法调用：

void Attack(Animal* pAnimal)
{
pAnimal->Attack();
}

比如这个时候采用如下方法进行调用(忽略里面内存释放的问题)：

Animal* pAnimal = new Tiger;
Attack(pAnimal);
pAnimal = new Cat;
Attack(pAnimal);

输出结果为：

Tiger Attack!
Cat Attack!

上面多态例子说明了在程序实现的时候只需要操控Animal，知道其方法即可操作继承自Animal的对象。那么也就是说：

1,继承自Animal的Cat和Tiger的不需要暴露给使用者

2,可以屏蔽Cat和Tiger的创建过程，不需要被调用者所关心

那么这个时候模块化和工厂设计模式可以对其进行实现：

1,比如将Animal, Cat, Tiger的实现都放进一个动态链接库的模块中，并且只暴露Animal的头文件给调用者

2,而工厂方法设计模式，可以使用一个工厂方法创建具体的对象，返回的时候只返回基类Animal的指针。

本文将先从简单工厂说起，然后再谈一谈工厂方法以及抽象工厂。

简单工厂
我相信这个是大家最常见的一种实现方法，如下：

class AnimalFactory
{
public:
enum class AnimalType
{
TIGER,
CAT
};
static Animal* CreateAnimal(const AnimalType type)
{
if (AnimalType::TIGER == type)
{
return new Tiger;
}
else if (AnimalType::CAT == type)
{
return new Cat;
}
return nullptr;
}
};

调用方法如下：

Animal* pAnimal = AnimalFactory::CreateAnimal(AnimalFactory::AnimalType::TIGER);
Attack(pAnimal);
pAnimal = AnimalFactory::CreateAnimal(AnimalFactory::AnimalType::CAT);
Attack(pAnimal);

但是这种方式违背了软件开发原则的开闭原则(Open-Closed Principle, OCP)，如果你需要新增一个叫做Dog的对象，则需要在CreateAnimal方法中修改分支判断逻辑。简单来说这种扩展方式，破坏了原有的逻辑，扩展中可能对软件的原有的稳定性产生影响。

可能有些人是不能够容忍代码，但也有人认为这种书写方式比较简单。从我个人在工程实践经验，认为软件开发设计原则是有非常好的指导性意义，但是也并不是所有的代码一定要符合软件开发的设计原则。个人的理解大致如下:

1.工程实践中有时候为了代码完全遵循软件开发设计原则，反而是有负担的，比如过度设计问题，一来有些代码模块可能甚至几年都不会对其进行修改扩展了，二来当逻辑实现比较简单的时候，过度设计也会让代码维护的人阅读代码实际是更加费劲的。毕竟大多数人都只是普通的程序员。

2.往往可扩展的代码编写时间是更长的，但是压在程序员头上的还有软件开发时间，对于一般的程序员来说，在规定时间内，有质量的完成需求是第一位的，而这个时候很可能就不会完全照顾软件开发设计原则了。

如果要符合开闭原则，那么我们可以实现工厂方法模式，让我们一起来看看吧。

工厂方法
工厂方法的主要是通过继承一个AnimalFactory来实现具体的工厂，比如CatFatory主要负责生产Cat，而TigerFacotory主要负责生产Tiger，其类图如下：

代码如下：

class AnimalFactory
{
public:
virtual Animal* CreateAnimal() = 0;
};
class CatFactory : public AnimalFactory
{
public:
virtual Animal* CreateAnimal()
{
return new Cat;
}
};
class TigerFactory : public AnimalFactory
{
public:
virtual Animal* CreateAnimal()
{
return new Tiger;
}
};

调用方式如下代码：

AnimalFactory* pFactory = new TigerFactory;
Animal* pAnimal = pFactory->CreateAnimal();
Attack(pAnimal);
pFactory = new CatFactory;
pAnimal = pFactory->CreateAnimal();
Attack(pAnimal);

可以发现工厂方法模式如果需要扩展一个新的动物类型，也可以对应扩展一个新的工厂，比如增加一个新的DogFactory继承AnimalFactory去生产Dog，从而符合开闭原则，更加安全的进行扩展。但是这种方式也可以看出来，每增加一个新的动物类型就得新增一个Fatory。个人对这种模式理解如下：

1.当这种动物类型创建并不是很繁琐的时候，采用这种方式相比较简单工程而言会繁琐一些；但是当初始化过程比较多的时候，用工厂方法模式方式扩展会显得更加清晰；

2.这种设计模式的本身实现是取消了条件判断的逻辑，但是其实是把这个条件判断任务交给了使用者去判断选择哪个工厂了。

抽象工厂
对于新手来说可能不太好理解抽象工厂模式，容易和工厂方法模式混淆起来。工厂方法模式中的每一个工厂是生产一个动物角色，而在抽象工厂中是生产一类动物角色的抽象。

一个动物角色比较好理解，就是我们上面的CatFactory生产Cat角色，而TigerFactory生产Tiger角色。

一类动物角色，我们可以理解在这个游戏中，这些动物角色的攻击性也分普通模式和困难模式。

那么我们首先要将Tiger分成SimpleModeTiger和HardModeTiger; Cat分为SimpleModeCat和HardModeCat。然后抽象工厂提供CreateAnimal的接口，继承的SimpleModeFactory可以生产简单模式的Cat角色和Tiger角色，继承的HardModeFactory可以生产困难模式的Cat角色和Tiger角色。

实现的代码如下所示：

#include <iostream>
class Animal
{
public:
virtual void Attack() = 0;
};
class AbstructTiger : public Animal
{
public:
virtual void Attack() = 0;
};
class SimpleModeTiger : public AbstructTiger
{
public:
virtual void Attack() { std::cout << "Tiger Simple Attack!" << std::endl; }
};
class HardModeTiger : public AbstructTiger
{
public:
virtual void Attack() { std::cout << "Tiger Hard Attack!" << std::endl; }
};
class AbstructCat : public Animal
{
public:
virtual void Attack() = 0;
};
class SimpleModeCat : public AbstructCat
{
public:
virtual void Attack() { std::cout << "Cat Simple Attack!" << std::endl; }
};
class HardModeCat : public AbstructCat
{
public:
virtual void Attack() { std::cout << "Cat Hard Attack!" << std::endl; }
};
enum class AnimalType
{
TIGER,
CAT
};
class AbscractAnimalFactory
{
public:
virtual Animal* CreateAnimal(const AnimalType type) = 0;
};
class SimpleModeAnimalFactory : public AbscractAnimalFactory
{
public:
virtual Animal* CreateAnimal(const AnimalType type)
{
if (AnimalType::TIGER == type)
{
return new SimpleModeTiger;
}
else if (AnimalType::CAT == type)
{
return new SimpleModeCat;
}
return nullptr;
}
};
class HardModeAnimalFactory : public AbscractAnimalFactory
{
public:
virtual Animal* CreateAnimal(const AnimalType type)
{
if (AnimalType::TIGER == type)
{
return new HardModeTiger;
}
else if (AnimalType::CAT == type)
{
return new HardModeCat;
}
return nullptr;
}
};
void Attack(Animal* pAnimal)
{
pAnimal->Attack();
}
int main()
{
//简单模式
AbscractAnimalFactory* pFactory = new SimpleModeAnimalFactory;
Animal* pAnimal = pFactory->CreateAnimal(AnimalType::TIGER);
Attack(pAnimal);
pAnimal = pFactory->CreateAnimal(AnimalType::CAT);
Attack(pAnimal);
//困难模式
pFactory = new HardModeAnimalFactory;
pAnimal = pFactory->CreateAnimal(AnimalType::TIGER);
Attack(pAnimal);
pAnimal = pFactory->CreateAnimal(AnimalType::CAT);
Attack(pAnimal);
}

为了让结构简单便于读者理解抽象工厂模式，以及和工厂方法模式的区别，上面的SimpleModeFactory和HardModeFactory用的是简单工厂的形式实现的，如果需要符合开闭原则，可以再对SimpleModeFactory和HardModeFactory进行工厂方法的实现。可以想象如果抽象工厂再加上工厂方法这个类的结构是有多么的庞大，而且这还仅仅只是两个游戏角色的描述。所以笔者认为在做工程实践的时候，尽量不要做过度设计，有时候反而不利于代码阅读，修改也未必简单。自己要权衡好工程和理论的平衡点。