Java工厂模式与抽象工厂模式的概念_技术教程

工厂模式与抽象工厂模式解决不同层级创建需求：前者解耦单一
产品族，后者支持多产品族组合创建；SimpleFactory适合轻量级同类型实例创建，FactoryMethod适用于框架扩展，AbstractFactory强调产品族一致性协同工作。

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

什么时候该用 `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();
    }
}

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