工厂模式与抽象工厂模式解决不同层级创建需求：前者解耦单一产品族，后者支持多产品族组合创建；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();
}
}
抽象工厂最难把握的其实是“产品族边界”——画得太窄，工厂类泛滥；画得太宽，一个工厂承担过多职责，违反单一职责。这需要结合领域模型反复推演，而不是一上来就套模式。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
