工厂方法模式（Factory Method Pattern）是创建型设计模式的核心成员，其核心理念在于定义一个用于创建对象的接口，但将具体的实例化逻辑延迟到子类中完成。这种设计使得类库的提供者能够预留扩展点，而具体应用开发者则可以根据需求决定实例化的具体类型，从而实现高层逻辑与底层实现的深度解耦。

模式的动机与核心价值

在传统的软件开发中，如果直接使用 new 关键字实例化对象，会导致调用方与具体实现类产生硬编码耦合。一旦需要更换实现或增加新类型，就必须修改调用方代码，这违背了"开闭原则"（Open-Closed Principle）。

工厂方法模式通过引入抽象工厂层，将"对象的创建"与"对象的使用"分离。其遵循依赖倒置原则（Dependency Inversion Principle），使高层模块依赖于抽象接口而非具体的工具类。相比简单工厂模式，它解决了工厂类职责过重以及新增产品必须修改工厂源码的缺陷。

工厂方法模式的角色构成

• 抽象产品（Abstract Product）： 定义产品的通用接口或抽象类，描述产品的主要功能。
• 具体产品（Concrete Product）： 实现抽象产品接口，是工厂方法最终创建的目标对象。
• 抽象工厂（Abstract Factory）： 声明工厂方法，通常返回一个抽象产品类型。
• 具体工厂（Concrete Factory）： 覆盖抽象工厂中的工厂方法，负责返回特定的具体产品实例。

代码实现示例：云存储集成方案

假设我们需要开发一个支持多种云服务商（如阿里云、AWS）的存储组件，以下是使用工厂方法模式的实现逻辑：

// 抽象产品：云存储接口
interface CloudStorage {
    void upload(String fileName);
}

// 具体产品：阿里云存储
class AliyunStorage implements CloudStorage {
    @Override
    public void upload(String fileName) {
        System.out.println("上传文件 [" + fileName + "] 到阿里云 OSS");
    }
}

// 具体产品：AWS S3 存储
class S3Storage implements CloudStorage {
    @Override
    public void upload(String fileName) {
        System.out.println("上传文件 [" + fileName + "] 到 AWS S3");
    }
}

// 抽象工厂
abstract class StorageProvider {
    // 抽象工厂方法
    public abstract CloudStorage createStorage();

    // 可以在此处定义通用业务逻辑
    public void storeFile(String fileName) {
        CloudStorage storage = createStorage();
        storage.upload(fileName);
    }
}

// 具体工厂：阿里云提供商
class AliyunProvider extends StorageProvider {
    @Override
    public CloudStorage createStorage() {
        return new AliyunStorage();
    }
}

// 具体工厂：AWS 提供商
class S3Provider extends StorageProvider {
    @Override
    public CloudStorage createStorage() {
        return new S3Storage();
    }
}

// 客户端调用
public class StorageClient {
    public static void main(String[] args) {
        // 根据配置选择不同的提供商
        StorageProvider provider = new AliyunProvider();
        provider.storeFile("backup.zip");
    }
}

进阶应用：模板方法与工厂方法的结合

在复杂的工业级架构中，工厂方法常与模板方法模式结合使用。抽象工厂不仅负责声明创建方法，还会定义一套标准的对象生命周期流程。子类通过实现工厂方法来提供具体对象，而父类则通过模板方法控制这些对象的初始化、配置和校验过程。

abstract class ConnectionFactory {
    // 模板方法
    public final Connection getConnection() {
        Connection conn = createConnection(); // 调用工厂方法
        conn.authenticate();
        conn.setReadTimeout(3000);
        return conn;
    }

    // 由子类实现的工厂方法
    protected abstract Connection createConnection();
}

模式的优缺点分析

优势：

• 极佳的扩展性： 新增产品时只需添加对应的产品类和工厂类，完全不需要修改现有代码。
• 封装性强： 客户端只需关心抽象工厂和抽象产品，屏蔽了具体创建细节。
• 符合单一职责： 每个具体工厂类只负责创建对应的产品，逻辑清晰。

挑战：

• 类数量膨胀： 每增加一个产品，就需要增加两个类（具体产品和具体工厂），增加了系统的抽象复杂性。
• 理解成本： 引入了额外的抽象层，对于简单的业务场景可能存在过度设计的情况。

典型应用场景

1. 日志记录器： 系统需要支持输出日志到文件、数据库、控制台或远程服务器，且未来可能增加新的输出介质。
2. 数据库访问层： 支持多种数据库（MySQL, PostgreSQL, Oracle），通过不同的具体工厂返回对应的数据库连接对象。
3. 框架插件机制： Spring 等框架中，FactoryBean 接口及其实现就是工厂方法模式的典型应用，允许开发者自定义 Bean 的创建逻辑。
4. 集合迭代器： Java 集合框架中的 iterator() 方法，不同的集合子类（ArrayList, HashSet）通过该工厂方法返回适合自身数据结构的迭代器实现。

架构设计建议

在实际工程中，如果产品的种类相对固定，且创建逻辑简单，优先考虑简单工厂或静态工厂方法。当产品等级结构复杂，或者系统需要高度的可扩展性，甚至需要支持第三方插件扩展时，工厂方法模式则是不可或缺的架构基础。为了减轻类爆炸问题，可以结合反射机制或配置驱动的方式，在具体工厂中实现动态实例化。