仅含一个方法的抽象工厂仍属于抽象工厂模式吗？

抽象工厂通常用于构建一组相关对象的“家族”，每个对象都继承自相应的抽象类。比如常见的示例中，工厂可以同时构建植物和采摘工具：OrangeFactory 负责创建 Oranges 和 OrangePickers，AppleFactory 负责创建 Apples 和 ApplePickers。

但如果对象家族仅包含一种抽象类型，比如下面的代码实现，这还属于抽象工厂吗？

interface PlantFactory {
  Plant makePlant();
}

public class AppleFactory implements PlantFactory {
  Plant makePlant() {
    return new Apple();
  }
}

这种实现属于抽象工厂的示例，还是其他设计模式？我从未在工厂、抽象工厂或工厂方法的示例中见过此类实现，但它似乎仍具备实用性。这种设计模式存在本质问题吗？

这不属于抽象工厂模式，而是标准的工厂方法模式，而且这种实现完全合理，没有本质问题。

核心区别：抽象工厂 vs 工厂方法 #

• 抽象工厂模式的核心是创建一组相关/依赖的对象家族，它的抽象工厂接口会包含多个创建不同类型产品的方法（比如同时有makePlant()和makePicker()），每个具体工厂负责实现这一组方法，产出配套的产品族。
• 工厂方法模式则聚焦于单一产品类型：它定义一个创建对象的抽象接口（比如你的PlantFactory），让具体子类（AppleFactory）决定实例化哪个具体产品（Apple），全程只围绕一种抽象产品（Plant）展开。

你的实现分析 #

你的代码完全符合工厂方法的结构：

1. 抽象产品：Plant
2. 具体产品：Apple
3. 抽象工厂（工厂方法接口）：PlantFactory（定义了创建产品的方法makePlant()）
4. 具体工厂：AppleFactory（实现接口，返回具体产品实例）

这种设计的实用性很强：

• 它把产品的创建逻辑和业务逻辑解耦，调用方只需要依赖PlantFactory和Plant，不需要知道具体是Apple还是未来可能扩展的Orange。
• 未来如果要新增植物类型，只需要新增对应的XXPlant类和XXPlantFactory类，完全符合开闭原则。

之所以你没在常见示例中看到这种极简实现，是因为很多工厂方法的示例会加入更多业务逻辑（比如产品的初始化参数、复杂创建流程），但这种最基础的结构正是工厂方法的核心本质。

内容的提问来源于stack exchange，提问作者Alexander Guyer