工厂模式三种实现方法详解

工厂模式是Java设计模式中用于封装对象创建过程，实现创建与使用分离的关键技术，旨在降低代码耦合度，提升系统灵活性和可维护性。本文深入对比解析了工厂模式的三种常见实现方式：简单工厂、工厂方法和抽象工厂。简单工厂适用于产品种类少且稳定的场景，但违背开闭原则；工厂方法通过抽象工厂接口让子类决定创建哪个产品，符合开闭原则，适合产品类型多且需扩展的场景；抽象工厂则用于创建一组相关或依赖的产品族，适合跨平台或主题切换等复杂场景。文章旨在帮助开发者根据实际需求选择最合适的工厂模式，避免过度设计，提升代码质量和可维护性。

工厂模式的核心目的是封装对象创建过程，解耦创建与使用，提升灵活性和可维护性，主要有三种实现方式：1. 简单工厂由一个工厂类根据参数创建所有产品，适用于产品种类少且稳定的场景，但违背开闭原则；2. 工厂方法通过抽象工厂接口让子类决定创建哪个产品，符合开闭原则，适合产品类型多且需扩展的场景，但类数量增加；3. 抽象工厂用于创建一组相关或依赖的产品族，适合跨平台或主题切换等场景，但结构复杂且扩展新产品类型困难。

工厂模式在Java设计模式中，核心目的都是为了封装对象的创建过程，从而将对象的创建与使用分离，降低代码的耦合度，提升系统的灵活性和可维护性。它主要有三种常见的实现方式：简单工厂（Simple Factory）、工厂方法（Factory Method）和抽象工厂（Abstract Factory），它们各有侧重，适用于不同的场景。

解决方案

工厂模式，顾名思义，就是像一个工厂一样，负责“生产”对象。这三种模式在实现上各有千秋，但都围绕着“解耦创建逻辑”这个核心思想。

1. 简单工厂模式（Simple Factory Pattern）

这可能是我们日常编码中最容易想到的，也是最“不那么”像设计模式的设计模式。它通常包含一个工厂类，这个类里有一个静态方法，根据传入的参数来决定创建并返回哪种具体的产品对象。

• 核心思想： 由一个工厂类负责所有产品的创建。
• 优点：
  • 简单易用： 代码量少，理解成本低，对于少量产品类型非常方便。
  • 集中管理： 所有的创建逻辑都集中在一个地方，方便修改。
• 缺点：
  • 违背开闭原则（Open/Closed Principle）： 每增加一种新产品，都需要修改工厂类的创建逻辑（通常是if-else或switch-case语句），这会导致工厂类变得臃肿且难以维护。
  • 职责过重： 工厂类承担了所有产品的创建职责。
• 适用场景： 产品种类较少且相对稳定，或者只是为了简单地封装创建过程，不想引入过多复杂度的场景。

// 产品接口
interface Product {
    void use();
}

// 具体产品A
class ConcreteProductA implements Product {
    @Override
    public void use() {
        System.out.println("使用产品A");
    }
}

// 具体产品B
class ConcreteProductB implements Product {
    @Override
    public void use() {
        System.out.println("使用产品B");
    }
}

// 简单工厂
class SimpleProductFactory {
    public static Product createProduct(String type) {
        if ("A".equalsIgnoreCase(type)) {
            return new ConcreteProductA();
        } else if ("B".equalsIgnoreCase(type)) {
            return new ConcreteProductB();
        } else {
            throw new IllegalArgumentException("未知产品类型: " + type);
        }
    }
}

// 客户端使用
public class Client {
    public static void main(String[] args) {
        Product productA = SimpleProductFactory.createProduct("A");
        productA.use(); // 输出: 使用产品A

        Product productB = SimpleProductFactory.createProduct("B");
        productB.use(); // 输出: 使用产品B
    }
}

2. 工厂方法模式（Factory Method Pattern）

这是为了解决简单工厂模式中违反开闭原则的问题而诞生的。它将产品对象的创建延迟到子类工厂中。每个具体产品都对应一个具体的工厂类。

• 核心思想： 定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
• 优点：
  • 符合开闭原则： 增加新产品时，只需增加新的具体产品类和对应的具体工厂类，无需修改现有代码。
  • 职责单一： 每个工厂只负责创建一种产品。
  • 客户端与具体产品解耦： 客户端只与抽象工厂和抽象产品交互。
• 缺点：
  • 类数量增加： 每增加一个产品，就需要增加一个对应的工厂类，导致类的数量膨胀，增加了系统的复杂性。
• 适用场景： 当一个类不知道它所需要的对象的类时；当一个类希望它的子类来指定它所创建的对象时。这是最常用的一种工厂模式。

// 产品接口 (同上)
// interface Product { void use(); }
// class ConcreteProductA implements Product { ... }
// class ConcreteProductB implements Product { ... }

// 抽象工厂接口
interface ProductFactory {
    Product createProduct();
}

// 具体产品A的工厂
class ConcreteProductAFactory implements ProductFactory {
    @Override
    public Product createProduct() {
        return new ConcreteProductA();
    }
}

// 具体产品B的工厂
class ConcreteProductBFactory implements ProductFactory {
    @Override
    public Product createProduct() {
        return new ConcreteProductB();
    }
}

// 客户端使用
public class Client {
    public static void main(String[] args) {
        ProductFactory factoryA = new ConcreteProductAFactory();
        Product productA = factoryA.createProduct();
        productA.use(); // 输出: 使用产品A

        ProductFactory factoryB = new ConcreteProductBFactory();
        Product productB = factoryB.createProduct();
        productB.use(); // 输出: 使用产品B
    }
}

3. 抽象工厂模式（Abstract Factory Pattern）

这是工厂模式中最复杂的一种，它不仅创建单个产品，而是创建一系列相关或相互依赖的产品对象，而无需指定它们具体的类。

• 核心思想： 提供一个接口，用于创建相关或依赖对象的家族，而无需明确指定具体类。
• 优点：
  • 提供一个产品族的抽象接口： 确保客户端使用一个产品族中的多个对象是相互兼容的。
  • 客户端与具体工厂和产品解耦： 客户端完全不知道具体的产品和工厂实现。
  • 易于切换产品族： 改变一个产品族的实现，只需切换具体的工厂即可。
• 缺点：
  • 增加复杂性： 引入了更多的接口和类，理解和维护成本更高。
  • 难以扩展新产品类型： 如果要增加新的产品类型（而不是新的产品族），需要修改所有的抽象工厂和具体工厂，违反开闭原则。
• 适用场景： 当需要创建一组相关或相互依赖的对象时；当系统需要独立于这些对象的创建、组合和表示时。比如，一个UI库需要支持多种操作系统主题（Windows风格、Mac风格），每种主题下有按钮、文本框等控件，这些控件在同一主题下是相互兼容的。

// 抽象产品A接口
interface AbstractProductA {
    void showA();
}

// 抽象产品B接口
interface AbstractProductB {
    void showB();
}

// 具体产品A1
class ConcreteProductA1 implements AbstractProductA {
    @Override
    public void showA() {
        System.out.println("这是产品A1");
    }
}

// 具体产品A2
class ConcreteProductA2 implements AbstractProductA {
    @Override
    public void showA() {
        System.out.println("这是产品A2");
    }
}

// 具体产品B1
class ConcreteProductB1 implements AbstractProductB {
    @Override
    public void showB() {
        System.out.println("这是产品B1");
    }
}

// 具体产品B2
class ConcreteProductB2 implements AbstractProductB {
    @Override
    public void showB() {
        System.out.println("这是产品B2");
    }
}

// 抽象工厂接口
interface AbstractFactory {
    AbstractProductA createProductA();
    AbstractProductB createProductB();
}

// 具体工厂1，生产产品A1和B1
class ConcreteFactory1 implements AbstractFactory {
    @Override
    public AbstractProductA createProductA() {
        return new ConcreteProductA1();
    }

    @Override
    public AbstractProductB createProductB() {
        return new ConcreteProductB1();
    }
}

// 具体工厂2，生产产品A2和B2
class ConcreteFactory2 implements AbstractFactory {
    @Override
    public AbstractProductA createProductA() {
        return new ConcreteProductA2();
    }

    @Override
    public AbstractProductB createProductB() {
        return new ConcreteProductB2();
    }
}

// 客户端使用
public class Client {
    public static void main(String[] args) {
        AbstractFactory factory1 = new ConcreteFactory1();
        AbstractProductA productA1 = factory1.createProductA();
        AbstractProductB productB1 = factory1.createProductB();
        productA1.showA(); // 输出: 这是产品A1
        productB1.showB(); // 输出: 这是产品B1

        AbstractFactory factory2 = new ConcreteFactory2();
        AbstractProductA productA2 = factory2.createProductA();
        AbstractProductB productB2 = factory2.createProductB();
        productA2.showA(); // 输出: 这是产品A2
        productB2.showB(); // 输出: 这是产品B2
    }
}

为什么我们需要工厂模式？

说实话，刚接触设计模式的时候，我个人觉得工厂模式有点“小题大做”。不就是new一个对象吗？直接new不香吗？但随着项目规模的扩大，我逐渐意识到，直接new带来的问题远比想象中要多。这背后其实是对“依赖”的深刻理解。

我们直接new一个对象时，比如Product p = new ConcreteProductA();，我们的代码就直接依赖于ConcreteProductA这个具体的类。如果哪天ConcreteProductA的构造函数变了，或者我们需要换成ConcreteProductB，那么所有直接new的地方都得改。这在大型项目中简直是灾难。

工厂模式的核心价值，就在于它把“谁来创建对象”这个职责给抽象并封装起来了。客户端代码不再直接关心具体产品是如何被创建的，它只关心抽象的产品接口。这样一来，我们的业务逻辑代码就能专注于处理业务本身，而不用被底层的对象创建细节所干扰。这大大提升了代码的解耦性和可维护性。想象一下，如果你的系统需要支持多种数据库，直接new MySQLConnection、new OracleConnection，那改起来简直要命。但如果通过工厂来获取连接，切换就变得轻而易举。

三种工厂模式的适用场景与权衡

我们已经看到了这三种模式的实现方式，但更重要的是，什么时候该用哪个？这其实是一个权衡的过程，没有绝对的“最好”，只有最适合当前上下文的。

简单工厂，我通常把它看作是“初级封装”。它最简单，上手快，如果你只是想把一些散乱的new操作集中起来，或者你的产品类型非常少，而且未来基本不会变动，那么简单工厂是你的不二之选。比如，一个工具类，根据传入的字符串返回不同的解析器实例。它的缺点在于，一旦产品种类增多，那个工厂方法里的if-else链条就会变得很长，每次新增产品都要修改它，这就违反了开闭原则，维护起来会很头疼。

工厂方法，在我看来，是工厂模式的“主力军”。它解决了简单工厂的扩展性问题。当你预计系统会不断增加新的产品类型时，工厂方法就显得尤为重要。它通过引入抽象工厂和具体工厂，将创建的职责下放到子类，完美地符合了开闭原则。每次新增产品，你只需要添加一个新的具体产品类和一个新的具体工厂类，对现有代码几乎没有影响。它的代价是类文件数量会显著增加。对于一个产品，你可能需要一个产品接口、一个具体产品类、一个工厂接口、一个具体工厂类，这一下子就多了四份代码。但为了系统的可扩展性，这种“臃肿”是值得的。

抽象工厂，这是工厂模式中的“重型武器”，也是最复杂的。它不是为了创建单个产品，而是为了创建“产品族”。想象一下，你正在开发一个跨平台的GUI应用，需要同时支持Windows和macOS风格的界面。Windows风格的按钮和文本框，与macOS风格的按钮和文本框，它们各自形成一个“家族”。抽象工厂就能让你在不修改客户端代码的情况下，轻松切换整个产品家族。它的缺点是显而易见的：复杂性急剧上升。而且，如果你想新增一个产品“类型”（比如，除了按钮和文本框，现在还要增加一个滑块），那么所有的抽象工厂和具体工厂都需要修改，这又是一个违反开闭原则的地方。所以，除非你真的有“产品族”的需求，否则不要轻易使用抽象工厂，过度设计带来的麻烦可能比它解决的问题还要多。

实践中的选择：何时从简单转向复杂？

在我的实际开发经验中，一个很关键的点是不要过度设计。我个人倾向于在起步阶段保持简单，但心里要清楚，一旦业务逻辑开始膨胀，就得考虑升级了。

通常，我会从简单工厂开始。如果项目初期产品类型不多，或者需求变动不大，简单工厂足够满足需求。它能快速搭建起创建逻辑的雏形，避免了最初就引入过多不必要的复杂性。

然而，当你的产品列表开始变得冗长，或者你发现自己频繁地修改简单工厂中的if-else语句来添加新产品时，这就是一个明确的信号：你该升级到工厂方法了。这种升级通常是渐进的，你可以先将最常变动的产品类型抽取出来，用工厂方法来管理。一旦你开始感受到简单工厂带来的维护负担，工厂方法模式的引入就显得水到渠成，它会让你在产品扩展时感到非常顺畅。

至于抽象工厂，它是一个更高级别的抽象，只有当你面临创建“产品族”的需求时，才应该考虑它。比如，你的系统需要同时支持多种主题、多种皮肤、或者不同系列的产品（如Intel系列CPU和AMD系列CPU，它们各自有一套主板、内存等配套产品）。如果你的需求仅仅是创建单一类型的产品，即使有很多种，工厂方法也足够了。不要为了用设计模式而用设计模式，因为抽象工厂的复杂性是实实在在的，它会增加学习曲线和维护成本。

总结一下，我的选择路径是：简单工厂 -> 工厂方法 -> 抽象工厂。从最简单的开始，随着业务复杂度的提升和对可扩展性要求的增加，逐步引入更复杂的模式。这就像盖房子，一开始可能只需要一个简单的棚子，但随着家庭成员的增加和生活需求的提升，你才需要考虑建造多层别墅，而不是一开始就规划一个宫殿。设计模式是解决问题的工具，不是炫技的手段。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。