设计模式之抽象工厂模式-优快云博客

本文链接：https://blog.youkuaiyun.com/karl2000/article/details/138320542

问题背景

假设我们正在开发一个跨平台的图形界面库，这个库需要支持不同操作系统（如Windows、Linux、MacOS）上的界面元素的创建。目标是让开发者能够在编写应用程序时不必担心底层操作系统的差异，同时能够根据用户的操作系统动态地提供相应的界面元素，如按钮、文本框和窗口。

我们需要设计一个框架，使得在添加或更改支持的操作系统时，对已有代码的影响最小。同时，这个框架应当能够在应用程序运行时根据不同的操作系统动态地提供具体的界面元素实现。这就要求我们的设计能够抽象出操作系统的差异，并通过某种方式在运行时选择正确的实现。

问题分析

为了解决提出的问题，我们可以采用抽象工厂模式。这种设计模式提供了一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们具体的类。通过这种方式，客户端代码可以从具体产品的实现中解耦出来，使得可以轻松地添加新的产品族或更改现有产品而不影响客户端代码。

抽象工厂模式的定义：抽象工厂模式提供一个接口，该接口负责创建一系列相关或相互依赖的对象，而无需指定它们的具体类。
优点：
1. 增强程序的可扩展性：添加新产品族时，不需要修改原有系统代码，符合开闭原则。
2. 增强程序的可维护性：具体工厂类之间独立，有利于产品的一致性。
3. 隔离具体类的生成：客户端不需要知道它所使用的对象的类。客户端仅通过其接口操作对象，从而减少了系统的依赖性和复杂性。
适用场景：
1. 当系统中的产品有多于一个的产品族，而系统只消费其中某一族的产品时。
2. 当存在多个产品等级结构时，但每次只使用其中某一产品等级结构。

代码部分

#include <iostream>

// 抽象产品类 Button
class Button {
public:
    virtual void paint() = 0;
    virtual ~Button() {}
};

// 抽象产品类 Textbox
class Textbox {
public:
    virtual void render() = 0;
    virtual ~Textbox() {}
};

// 具体产品类 WindowsButton
class WindowsButton : public Button {
public:
    void paint() override {
        std::cout << "Render a button in a Windows style.\n";
    }
};

// 具体产品类 WindowsTextbox
class WindowsTextbox : public Textbox {
public:
    void render() override {
        std::cout << "Render a textbox in a Windows style.\n";
    }
};

// 具体产品类 LinuxButton
class LinuxButton : public Button {
public:
    void paint() override {
        std::cout << "Render a button in a Linux style.\n";
    }
};

// 具体产品类 LinuxTextbox
class LinuxTextbox : public Textbox {
public:
    void render() override {
        std::cout << "Render a textbox in a Linux style.\n";
    }
};

// 抽象工厂类 WidgetFactory
class WidgetFactory {
public:
    virtual Button* createButton() = 0;
    virtual Textbox* createTextbox() = 0;
    virtual ~WidgetFactory() {}
};

// 具体工厂类 WindowsFactory
class WindowsFactory : public WidgetFactory {
public:
    Button* createButton() override {
        return new WindowsButton();
    }
    Textbox* createTextbox() override {
        return new WindowsTextbox();
    }
};

// 具体工厂类 LinuxFactory
class LinuxFactory : public WidgetFactory {
public:
    Button* createButton() override {
        return new LinuxButton();
    }
    Textbox* createTextbox() override {
        return new LinuxTextbox();
    }
};

// 客户端代码
int main() {
    WidgetFactory* factory;
    Button* button;
    Textbox* textbox;

    // 选择需要的工厂
    factory = new WindowsFactory();
    button = factory->createButton();
    textbox = factory->createTextbox();

    button->paint(); // Render a button in a Windows style.
    textbox->render(); // Render a textbox in a Windows style.

    delete button;
    delete textbox;
    delete factory;

    return 0;
}

此代码实现了抽象工厂模式，其中每个具体工厂都能够创建一组相关的产品。这样，我们就能更灵活地在不同的操作系统上提供一致的用户界面组件，而不必修改客户端代码。

代码分析

在上述代码中，我们实现了一个简单的抽象工厂模式，该模式允许创建多个相关的产品族，每个产品族具有不同的实现。这些产品族在这个例子中是各种界面组件，如按钮和文本框，它们根据不同的操作系统有不同的样式。每个操作系统的具体工厂类（如WindowsFactory和LinuxFactory）都能创建相应风格的按钮和文本框。

抽象工厂类 (WidgetFactory)：定义了一个接口，包括createButton和createTextbox两个方法。这允许客户端代码在完全不知道具体产品类的情况下，通过工厂接口来创建产品。
具体工厂类：如WindowsFactory和LinuxFactory，它们实现了抽象工厂接口中定义的方法，返回特定风格的产品对象。
抽象产品类：如Button和Textbox，定义了所有具体产品必须实现的接口。
具体产品类：如WindowsButton、LinuxButton、WindowsTextbox和LinuxTextbox，这些类实现了相应的抽象产品接口，并定义了具体的行为。

编程要点

抽象工厂模式在编程中的关键要点可以概括如下：

1. 抽象工厂接口（Abstract Factory Interface）

定义操作集：创建不同类型的抽象产品的操作。
无需指定具体类：客户端通过这个接口操作实例，而不依赖于具体的产品实现。

2. 具体工厂类（Concrete Factory Classes）

实现抽象工厂接口：每个具体工厂类实现抽象工厂定义的操作，以创建具体产品的实例。
封装产品创建逻辑：具体工厂根据环境或配置创建特定类型的产品对象。

3. 抽象产品类（Abstract Product Classes）

定义接口：所有具体产品类必须实现的通用接口。
规范行为：确定产品必须提供的方法和属性。

4. 具体产品类（Concrete Product Classes）

实现抽象产品接口：具体产品类定义抽象产品规定的操作。
特定实现：每个产品类提供特定于其类别的实现。

5. 客户端使用（Client Usage）

通过工厂接口与产品交互：客户端代码通过抽象工厂和产品接口操作实例，从而与具体实现解耦。
动态工厂选择：根据运行时条件（如操作系统类型），选择相应的具体工厂。

6. 优点和应用

支持可扩展性和灵活性：新的产品族和产品可以被添加进系统而不影响现有代码。
降低耦合度：系统的不同部分通过抽象接口交互，增加了代码的模块化。

7. 注意事项

管理复杂性：随着产品族的增加，管理工厂和产品类的复杂性也会增加。
设计前瞻性：设计抽象工厂和产品接口时需要考虑长期的扩展性，避免频繁修改接口。

实用性讨论

抽象工厂模式非常适用于那些需要创建一系列相关或依赖对象的情况，尤其是当这些对象的具体类可能随着环境的变化而变化时。在我们的示例中，不同操作系统需要不同的用户界面元素，抽象工厂模式使得添加新的操作系统支持变得更加容易，而无需修改现有代码。此外，该模式还有助于保持代码的整洁和组织，因为它促使开发者将依赖关系集中管理。

可能的问题和解决策略

扩展性问题：每当添加新的产品族或新的产品时，都需要修改抽象工厂和所有具体工厂，这可能会导致代码膨胀。解决这一问题的一种策略是仔细设计产品族以确保它们在未来的一段时间内稳定，减少需要添加或修改的次数。
复杂性增加：对于简单的产品创建需求，使用抽象工厂模式可能会使系统过于复杂。因此，应当在确实需要处理多个相关产品系列的创建时，才考虑使用此模式。