抽象工厂模式通过定义创建一系列相关对象的接口，实现产品族的统一创建与解耦，如GUI库中不同平台组件的生成，客户端无需关心具体实现，仅依赖抽象接口，提升代码灵活性与可维护性。
C++中的抽象工厂模式，在我看来，核心在于它提供了一种创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。简单来说，它就像一个“产品家族的生产线”，你可以根据不同的“品牌”（具体工厂）生产出一整套风格统一、功能互补的产品。这种模式的巧妙之处在于，它让你的代码在面对需要切换不同产品实现集时，变得异常灵活和解耦。
抽象工厂模式的魅力，很大程度上在于它对“产品族”概念的封装。想象一下，你正在构建一个跨平台的GUI库，需要为Windows、macOS和Linux提供一套统一的按钮、文本框和滚动条。如果每次都手动去实例化对应平台的组件，那代码会变得一团糟，而且修改起来简直是噩梦。
这时候，抽象工厂就派上用场了。它定义了一个抽象接口，比如
IGUIFactory
，里面声明了创建按钮、文本框等抽象产品的方法。然后，我们为每个平台实现一个具体的工厂，比如
WindowsGUIFactory
、
MacOSGUIFactory
，它们各自负责生产对应平台的具体产品——
WindowsButton
、
MacOSButton
等等。
核心结构通常是这样的：
立即学习“C++免费学习笔记（深入）”；
抽象工厂 (Abstract Factory)：声明一组用于创建抽象产品的方法。具体工厂 (Concrete Factory)：实现抽象工厂接口，负责创建特定产品族中的具体产品。抽象产品 (Abstract Product)：为一类产品对象声明接口。具体产品 (Concrete Product)：实现抽象产品接口，是具体工厂创建的对象。
#include #include // For std::unique_ptr// 抽象产品接口：按钮class IButton {public: virtual ~IButton() = default; virtual void paint() = 0;};// 抽象产品接口：文本框class ITextBox {public: virtual ~ITextBox() = default; virtual void render() = 0;};// 具体产品 (Windows系列)class WindowsButton : public IButton {public: void paint() override { std::cout << "Rendering a Windows button." << std::endl; }};class WindowsTextBox : public ITextBox {public: void render() override { std::cout << "Rendering a Windows text box." << std::endl; }};// 具体产品 (MacOS系列)class MacOSButton : public IButton {public: void paint() override { std::cout << "Rendering a MacOS button." << std::endl; }};class MacOSTextBox : public ITextBox {public: void render() override { std::cout << "Rendering a MacOS text box." << std::endl; }};// 抽象工厂接口class IGUIFactory {public: virtual ~IGUIFactory() = default; virtual std::unique_ptr createButton() = 0; virtual std::unique_ptr createTextBox() = 0;};// 具体工厂 (Windows)class WindowsGUIFactory : public IGUIFactory {public: std::unique_ptr createButton() override { return std::make_unique(); } std::unique_ptr createTextBox() override { return std::make_unique(); }};// 具体工厂 (MacOS)class MacOSGUIFactory : public IGUIFactory {public: std::unique_ptr createButton() override { return std::make_unique(); } std::unique_ptr createTextBox() override { return std::make_unique(); }};// 客户端代码：使用抽象工厂创建产品void clientCode(IGUIFactory* factory) { auto button = factory->createButton(); auto textBox = factory->createTextBox(); button->paint(); textBox->render();}/*int main() { std::cout << "Client: Testing with Windows factory." << std::endl; WindowsGUIFactory windowsFactory; clientCode(&windowsFactory); std::cout << "nClient: Testing with MacOS factory." << std::endl; MacOSGUIFactory macosFactory; clientCode(&macosFactory); return 0;}*/
这种模式的强大之处在于，客户端代码只需要依赖
IGUIFactory
和
IButton
、
ITextBox
这些抽象接口，根本不需要知道它具体是在使用Windows还是MacOS的组件。切换平台？只需要更换一个具体工厂的实例就行了，简直是丝滑。
抽象工厂模式与工厂方法模式有何不同，我该如何选择？
这确实是很多初学者容易混淆的地方，我自己刚开始学设计模式的时候也常常搞不清楚。简单来说，工厂方法模式（Factory Method）只负责生产一种产品，比如一个
ButtonFactory
就只生产
Button
。而抽象工厂模式则更宏大一些，它负责生产一个“产品族”，也就是一系列相互关联、相互依赖的产品。
你可以这样理解：
工厂方法模式：专注于“如何创建一个对象”。它把对象的创建延迟到子类，让子类决定实例化哪个具体类。当你有一个类，但不知道它将创建哪个子类的对象时，或者想让子类决定创建什么对象时，它很合适。比如，一个文档编辑器，可能有多种导出格式（PDF、DOCX），每个格式都有一个对应的导出工厂。抽象工厂模式：专注于“如何创建一组相关的对象”。它提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们具体的类。当你需要创建一组对象，并且这些对象必须协同工作，或者需要确保它们来自同一个“家族”时，抽象工厂就是你的首选。回到GUI的例子，一个工厂生产一套完整的Windows风格组件，另一个工厂生产一套完整的MacOS风格组件。
选择的关键点在于：如果你只需要创建单一类型的对象，并且希望将对象的创建逻辑封装起来，那么工厂方法可能就足够了。它更轻量，也更容易实现。但如果你需要创建一组相互关联的对象，并且希望在不修改客户端代码的情况下，能够方便地切换这组对象的具体实现，那么抽象工厂模式无疑是更强大的工具。它提供了更高级别的抽象和解耦。我个人觉得，抽象工厂更像是一个“套件供应商”，而工厂方法只是一个“单品制造商”。
实现C++抽象工厂模式时，如何有效管理产品族中的产品类型演进？
这是个好问题，也是抽象工厂模式最常被诟病的一个“痛点”。当你的产品族需要增加一个新的产品类型时，比如在GUI库中，除了按钮和文本框，现在还需要一个
ICheckbox
。这时候，你不得不修改
IGUIFactory
接口，添加
createCheckbox()
方法，这意味着所有实现
IGUIFactory
的具体工厂（
WindowsGUIFactory
、
MacOSGUIFactory
）也都要跟着修改。这显然违背了开闭原则（Open/Closed Principle），因为你为了扩展功能，修改了已有的代码。这种问题，有时我们称之为“N维问题”的一个侧面，即在两个维度（产品族和产品类型）上扩展时，一个维度上的变化会影响到另一个维度。
那么，有没有什么技巧可以缓解这个问题呢？
使用默认实现或空对象（Null Object）：对于新增加的产品类型，你可以在抽象工厂接口中提供一个默认的空实现
以上就是C++抽象工厂模式与产品族实现技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474187.html
微信扫一扫 
支付宝扫一扫 
