简介

工厂方法是一种创建型设计模式，它提供了在父类中创建对象的接口，但允许子类改变将要创建的对象的类型。工厂方法（Factory Method）的核心目标是解耦对象创建与使用逻辑。

场景

假设你正在创建一个物流管理应用程序。物流只采用卡车运输，所以当前只能处理卡车运输，大部分代码都位于 Truck 类中。

/** 客户端运输管理类 */
class LogisticsManager {public void transportCargo() {// 直接依赖具体类 TruckTruck truck = new Truck();truck.deliver();// 新增其他运输类型需要继续扩展条件分支}
}/** 卡车类（硬编码具体实现） */
class Truck {public void deliver() {System.out.println("陆地运输：卡车配送");}
}

一段时间后，你想把海运物流也加到应用中。
这个时候你会发现，你可能需要再创建一个Ship类用于处理海运的请求，并且还需要修改主流程代码。你可能会做出如下修改：

/** 客户端运输管理类 */
class LogisticsManager {public void transportCargo(String type) {// 直接依赖具体类 Truckif ("land".equals(type)) {Truck truck = new Truck();truck.deliver();} else if ("sea".equals(type)) {Ship ship = new Ship(); // 新增 Ship 需修改此处ship.deliver();}// 新增其他运输类型需要继续扩展条件分支}
}/** 卡车类（硬编码具体实现） */
class Truck {public void deliver() {System.out.println("陆地运输：卡车配送");}
}/** 新增船舶类时被迫修改既有代码 */
class Ship {public void deliver() {System.out.println("海运：船舶配送");}
}

问题

1. 直接依赖具体实现

LogisticsManager 直接通过 new Truck() 硬编码创建对象，客户端代码与 Truck 类强耦合。新增 Ship 类时必须修改 transportCargo 方法的逻辑。

2. 违反开闭原则

每添加一种新的运输工具（例如 Ship 或 Airplane），都需要：

• 修改 transportCargo 方法，增加条件分支
• 引入对其他具体类的依赖
• 导致核心业务逻辑频繁变更

3. 条件分支泛滥

if-else 或 switch 语句扩散到多个位置（例如支付方式、日志记录等其他模块重复出现类似代码），维护成本指数级增长。

4. 代码重复风险

若其他模块（如计费系统）也需要根据运输类型创建对象，必须重复编写相同的条件分支逻辑，系统复杂度失控。

解决

根本问题

对象创建逻辑与业务逻辑深度耦合，未遵循「面向接口编程」原则 。工厂方法模式通过把创建过程封装到独立层级（如新增 LandLogistics / SeaLogistics 子类）可彻底解决这些问题。

我们用工厂方法代替直接调用对象构造函数（也就是使用new）。但是对象还是通过new创建，只是new变成了在工厂方法里调用。工厂方法返回的对象就是“产品”。

粗略看着这种更改可能没啥意义，我们只是改变了程序中调用构造函数的位置而已。但是，仔细想一下，现在你可以在子类中重写工厂方法，从而改变它创建产品的类型。
但有一点需要注意:只有这些产品具有共同的基类或者接口时，子类才能返回不同类型的产品，同时基类中工厂方法的返回类型也要声明成这个共有接口。

举例来说，卡车Truck和轮船Ship类都必须实现运输Trans­port接口，这个接口声明了一个deliver方法。每个类都会以不同的方式实现这个方法：卡车走陆路交付货物，轮船走海路交付货物。陆路运输Road­Logis­tics类里的工厂方法返回卡车对象，而海路运输Sea­Logis­tics类就返回轮船对象。

完整类图

完整代码

// 抽象产品接口：所有运输工具必须实现此接口 [^6]
interface Transport {void deliver();
}// 具体产品实现：卡车类
class Truck implements Transport {@Overridepublic void deliver() {System.out.println("陆地运输：卡车配送");}
}// 具体产品实现：船舶类
class Ship implements Transport {@Overridepublic void deliver() { System.out.println("海运：船舶配送");}
}// 抽象工厂类（核心工厂方法) [^6]
abstract class Logistics {// 模板方法：组合核心逻辑与工厂方法public void planDelivery() {Transport transport = createTransport();transport.deliver();}// 工厂方法声明：延迟具体运输工具创建到子类public abstract Transport createTransport();
}// 具体工厂类：陆地物流 [^6]
class RoadLogistics extends Logistics {@Overridepublic Transport createTransport() {return new Truck(); // 无需判读条件的直接构造}
}// 具体工厂类：海洋物流
class SeaLogistics extends Logistics {@Overridepublic Transport createTransport() {return new Ship();}
}// 客户端调用示例
class Client {public void clientMethod(String logisticsType) {Logistics logistics;// 通过简单映射选择具体工厂if ("road".equals(logisticsType)) {logistics = new RoadLogistics();} else {logistics = new SeaLogistics(); }// 统一调用接口（核心业务逻辑无需修改）logistics.planDelivery();}
}

说明

1. 实现关系：Truck/Ship 实现 Transport 接口
2. 继承关系：RoadLogistics/SeaLogistics 继承 Logistics 抽象类
3. 依赖关系：Logistics 依赖 Transport 接口（虚线箭头）

核心优势

1. 快速扩展能力：新增空运只需添加 AirLogistics 类和 Plane 产品类，零/少修改现有代码
2. 核心业务稳定：planDelivery() 模板方法与运输工具实现完全解耦
3. 统一接口调用：客户端通过 Logistics 基类操作所有物流类型，符合里氏替换原则(在使用继承的过程中，子类可以完全替换掉父类，并且软件的功能不受到影响。这个原则是保证代码的健壮性和可扩展性的重要原则之一)

代码优化

以上代码在客户端中还是存在条件判断分支，可以通过静态配置注册表或者动态策略解决。如果新增运输工具，客户端就只需要修改配置文件即可，真正实现零修改现有代码。

静态配置表

// 创建对象注册表
class LogisticsRegistry {private static Map<String, Supplier<Logistics>> registry = new HashMap<>();static {registry.put("road", RoadLogistics::new); // 配置化绑定， 可以从配置文件中加载registry.put("sea", SeaLogistics::new);}public static Logistics getLogistics(String type) {return registry.getOrDefault(type, SeaLogistics::new).get();}
}// 客户端无需任何条件判断
class Client {public void clientMethod(String logisticsType) {Logistics logistics = LogisticsRegistry.getLogistics(logisticsType);logistics.planDelivery();}
}

动态策略

若系统存在动态运行时判定逻辑（如根据GPS坐标实时选择最优运输方式），则需在简单工厂层用策略模式处理：

class DynamicLogisticsSelector {public Logistics selectByConditions(Context ctx) {// 动态策略分支（仍可避免硬编码if）return strategyMap.get(ctx.analyze()).create();}
}

总结

1. 产品（Prod­uct）接口。对于所有由创建者（Creator）以及它的子类构建的对象，这些接口都是通用的。
2. 具体产品（Con­crete Prod­ucts）是产品接口的不同实现。
3. 创建者（Cre­ator）声明了返回产品对象的工厂方法。方法的返回对象类型必须与产品接口一致。你可以把工厂方法声明为抽象方法，强制要求每个子类重新实现。或者，你也可以在基类工厂方法中返回默认产品类型。
4. 具体创建者（Con­crete Cre­ators）会重写基础的工厂方法，让他返回不同类型的产品。注意，并不一定每次调用工厂方法都会创建新的实例。工厂方法也可以返回缓存、对象池或其他来源的已有对象。