《Head First设计模式》：抽象工厂模式是否包含工厂模式及二者关系咨询

首先明确：你的核心理解完全正确——Factory Method模式专注创建单个类型的对象，Abstract Factory模式则负责创建一组相关/依赖的对象族。

核心差异 #

• 创建目标：
  • Factory Method：聚焦单一产品类型的实例化，比如只创建「按钮」或只创建「日志器」。
  • Abstract Factory：聚焦一套配套的产品组合，比如同时创建「Windows风格按钮 + Windows风格输入框」，或者「Mac风格按钮 + Mac风格输入框」。
• 实现方式：
  • Factory Method是继承驱动：通过子类重写工厂方法来决定具体创建哪个产品。
  • Abstract Factory是组合驱动：一个抽象工厂会包含多个Factory Method，每个方法负责创建产品族里的一个成员。
• 扩展逻辑：
  • 给Factory Method新增产品，需要新增对应的工厂子类；
  • 给Abstract Factory新增产品族，只需新增一个工厂实现类，不用修改现有产品代码，更符合开闭原则。

关于「Abstract Factory是否包含Factory Pattern」 #

从实现逻辑来看：是的。Abstract Factory的每个产品创建方法，本质上就是一个Factory Method。但从概念层面，二者是独立的设计模式——Factory Method解决「单一对象的创建解耦」，Abstract Factory解决「配套对象族的创建解耦」，后者是前者的高阶组合应用，但并非包含关系，而是互补的。

实际交互示例 #

比如做跨平台UI：

1. 定义UIFactory抽象工厂，包含createButton()和createInput()两个方法；
2. 实现WindowsUIFactory和MacUIFactory两个具体工厂，每个工厂的createButton()和createInput()内部，用Factory Method的逻辑创建对应风格的组件；
3. 客户端代码只依赖UIFactory接口，调用它的方法就能拿到一套匹配的UI组件，完全不用关心具体是Windows还是Mac风格。

适用场景选择 #

选Factory Method的情况 #

• 只需要创建单一类型的对象，且未来可能要扩展该类型的新子类；
• 想把对象创建逻辑和业务逻辑彻底分开，通过子类来控制具体创建的对象；
• 例子：日志框架中创建不同类型的日志器（文件日志、控制台日志）。

选Abstract Factory的情况 #

• 需要创建一组必须搭配使用的对象，比如不同风格的UI组件、不同数据库的连接池+查询器；
• 希望客户端代码和具体产品族解耦，切换产品族时只需要替换工厂实例；
• 例子：跨平台应用的UI组件库、多数据库兼容的持久层框架。

内容的提问来源于stack exchange，提问作者Lee Soobin