简介

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

场景

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

/** 客户端运输管理类 */
class LogisticsManager {
    public void transportCargo() {
        // 直接依赖具体类 Truck
        Truck truck = new Truck();
        truck.deliver();
        // 新增其他运输类型需要继续扩展条件分支
    }
}

/** 卡车类（硬编码具体实现） */
class Truck {
    public void deliver() {
        System.out.println("陆地运输：卡车配送");
    }
}

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

/** 客户端运输管理类 */
class LogisticsManager {
    public void transportCargo(String type) {
        // 直接依赖具体类 Truck
        if ("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 {
    @Override
    public void deliver() {
        System.out.println("陆地运输：卡车配送");
    }
}

// 具体产品实现：船舶类
class Ship implements Transport {
    @Override
    public 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 {
    @Override
    public Transport createTransport() {
        return new Truck(); // 无需判读条件的直接构造
    }
}

// 具体工厂类：海洋物流
class SeaLogistics extends Logistics {
    @Override
    public 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）会重写基础的工厂方法，让他返回不同类型的产品。注意，并不一定每次调用工厂方法都会创建新的实例。工厂方法也可以返回缓存、对象池或其他来源的已有对象。