Java工厂模式与抽象工厂区别解析

本文深入剖析了Java中工厂模式与抽象工厂模式的本质区别与适用场景：简单工厂适合轻量级同类型对象创建，工厂方法侧重框架扩展性，而抽象工厂则聚焦于保障多产品族（如不同操作系统的UI组件）间的一致性协同；关键不在于“哪个更好”，而在于精准识别业务中的创建层级需求——单一产品族解耦用工厂模式，多产品族组合创建且需强一致性约束时才用抽象工厂，同时警惕误将无关对象强行纳入同一工厂的典型反模式，强调产品族边界的合理划分需紧密结合领域模型反复推演。

工厂模式和抽象工厂模式不是“选哪个更好”的问题，而是解决不同层级对象创建需求的设计手段——前者应对单一产品族的解耦，后者应对多产品族的组合创建。

什么时候该用 SimpleFactory 或 FactoryMethod

当系统只需要生产同一类产品的不同实例（比如不同数据库驱动的 Connection），且产品之间无强关联时，用简单工厂或工厂方法足够轻量。

• SimpleFactory 不是 GoF 23 种之一，但实用：把 if-else 创建逻辑集中到一个静态方法里，避免散落在业务代码中
• FactoryMethod 把创建逻辑推迟到子类，适合框架扩展——比如 Spring 的 AbstractBeanFactory 让子类决定如何获取 bean 实例
• 注意：工厂方法引入了继承结构，如果产品类型频繁增减，子类会爆炸；此时应考虑策略+工厂结合

为什么 AbstractFactory 必须成对定义产品族

抽象工厂的核心约束是“一套产品必须协同工作”，比如 WindowsButton 和 WindowsCheckbox 共享 UI 主题、字体渲染逻辑，不能混搭 MacButton + WindowsCheckbox。

• 接口设计上，AbstractFactory 声明多个创建方法：createButton()、createCheckbox()，每个实现类（如 MacFactory）返回对应平台的一整套组件
• 客户端代码只依赖抽象工厂接口和抽象产品接口，完全不感知具体实现类名
• 新增产品族（如加一个 LinuxFactory）只需新增实现类；新增产品类型（如加 ComboBox）则需修改所有工厂接口和实现——这是它的扩展痛点

AbstractFactory 在真实项目中的典型误用

最常见的错误是把“多个不相关的对象”强行塞进一个工厂，只因它们都由同一个类创建——这违背了“产品族一致性”原则，反而增加耦合。

• 例如：用一个 OrderFactory 同时创建 Order、Payment、Log ——三者生命周期、变更原因、依赖模块完全不同，不属于同一产品族
• 正确做法：按领域职责拆分，OrderFactory 只管订单相关对象；支付走 PaymentFactory；日志用 SLF4J 等标准门面，不进工厂
• Spring 的 @Configuration 类常被误当成抽象工厂——其实它只是配置组织方式，真正解耦靠的是依赖注入容器管理生命周期，而非工厂接口契约

// 示例：抽象工厂接口定义（精简版）
public interface GUIFactory {
    Button createButton();
    Checkbox createCheckbox();
}

public class MacFactory implements GUIFactory {
    public Button createButton() { return new MacButton(); }
    public Checkbox createCheckbox() { return new MacCheckbox(); }
}

// 客户端不关心具体实现
public class Application {
    private Button button;
    private Checkbox checkbox;

    public Application(GUIFactory factory) {
        this.button = factory.createButton();
        this.checkbox = factory.createCheckbox();
    }
}

抽象工厂最难把握的其实是“产品族边界”——画得太窄，工厂类泛滥；画得太宽，一个工厂承担过多职责，违反单一职责。这需要结合领域模型反复推演，而不是一上来就套模式。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java工厂模式与抽象工厂区别解析》文章吧，也可关注golang学习网公众号了解相关技术文章。