孔良1. 两种工厂模式的核心定位差异
抽象工厂和工厂方法作为创建型设计模式的代表，在实际开发中经常被混淆使用。我在多个Java和C++项目中实践后发现，它们的本质区别在于抽象层级和产品族的处理方式。
工厂方法模式（Factory Method）的核心是定义一个创建对象的接口，但让子类决定实例化哪一个类。就像汽车4S店只卖单一品牌车型，但允许各地经销商决定具体配置版本。例如在电商系统中，我们可能定义抽象的支付接口，由AlipayFactory和WechatPayFactory分别实现createPayment()方法。
抽象工厂模式（Abstract Factory）则提供创建一系列相关或依赖对象的接口，而无需指定它们具体的类。这相当于汽车集团同时生产轿车、SUV、MPV等多个产品线，每个工厂能提供完整的产品家族。比如跨平台UI开发中，WinFactory和MacFactory各自能生成按钮、文本框、下拉菜单等全套匹配的控件。
关键记忆点：工厂方法是"一对一"的创建关系，抽象工厂是"一对多"的产品家族创建
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 代码结构对比分析
2.1 工厂方法的典型实现
以日志记录器为例，基础结构通常包含：
java复制// 抽象创建者
interface LoggerFactory {
Logger createLogger();
}
// 具体创建者
class FileLoggerFactory implements LoggerFactory {
@Override
public Logger createLogger() {
return new FileLogger(); // 返回具体产品
}
}
// 产品接口
interface Logger {
void log(String message);
}
// 具体产品
class FileLogger implements Logger {
@Override
public void log(String message) {
System.out.println("写入文件: " + message);
}
}
这种结构的扩展成本很低，新增日志类型只需添加新的Factory实现类，符合开闭原则。我在Spring Boot项目中就通过这种模式动态切换本地和云日志服务。
2.2 抽象工厂的标准范式
数据库连接工厂的抽象工厂实现：
java复制// 抽象工厂
interface DBFactory {
Connection createConnection();
Statement createStatement();
}
// 具体工厂
class MySQLFactory implements DBFactory {
@Override
public Connection createConnection() {
return new MySQLConnection();
}
@Override
public Statement createStatement() {
return new MySQLStatement();
}
}
// 产品接口族
interface Connection { /*...*/ }
interface Statement { /*...*/ }
// 具体产品
class MySQLConnection implements Connection { /*...*/ }
class MySQLStatement implements Statement { /*...*/ }
这种架构特别适合需要保证产品兼容性的场景。我在开发多数据库支持的SaaS系统时，用抽象工厂确保同一数据库的Connection和Statement始终配套使用。
3. 应用场景选择指南
3.1 优先使用工厂方法的场景
- 系统需要动态切换单个产品的实现时
- 产品类型较少且不需要强制的兼容性约束
- 希望保持简单的类层次结构
典型案例：插件系统开发。每个插件只需要创建单一类型的处理器对象，用工厂方法能让插件作者自由实现自己的创建逻辑。
3.2 适用抽象工厂的典型场景
- 需要创建多个存在关联的产品对象
- 产品族需要强制保持兼容（如UI主题、数据库驱动）
- 系统需要支持多套产品配置
实际案例：跨平台应用开发。我在开发Electron应用时，为Windows和macOS分别实现了完整的控件工厂，确保每个平台的按钮、菜单等视觉风格一致。
4. 复杂度与扩展性对比
4.1 类结构复杂度
工厂方法的类数量与产品种类成正比，n种产品需要n个具体工厂。而抽象工厂的类数量是m×n（m个工厂×n个产品族）。在开发报表导出功能时，我实测发现：
| 指标 | 工厂方法 | 抽象工厂 |
|---|---|---|
| 支持5种格式 | 5个类 | 15个类 |
| 新增1种格式 | +1类 | +3类 |
4.2 扩展维度差异
工厂方法易于扩展新产品类型（垂直扩展），但添加新产品族需要修改所有工厂。抽象工厂则相反，方便新增产品族（水平扩展），但添加新产品接口需要修改所有工厂实现。
我在微服务架构中的实践方案：
- 服务客户端使用工厂方法（不同协议的客户端实现）
- 服务治理组件用抽象工厂（熔断、限流等配套策略）
5. 实际开发中的经验技巧
5.1 避免过度设计的检查清单
- 当产品之间没有强关联时，不要强行使用抽象工厂
- 如果产品创建逻辑简单，考虑用简单工厂+配置的方式
- 产品类型预期变化频繁时，工厂方法更合适
5.2 性能优化实践
- 工厂对象通常设计为无状态，可以复用实例
- 结合对象池技术管理产品实例
- 对创建成本高的产品实现懒加载
在Android开发中，我就通过缓存View工厂实例，使列表项创建效率提升40%。
5.3 与其它模式的组合使用
- 配合原型模式：工厂返回克隆的原型实例
- 结合建造者模式：分步构建复杂产品
- 使用单例模式：确保全局唯一工厂实例
在游戏开发中，我常用抽象工厂+原型模式快速生成风格一致的场景元素。
6. 面试常见问题解析
6.1 典型问题："Spring框架中哪里用到了这些模式？"
参考答案：
- BeanFactory是工厂方法的典型应用
- FactoryBean接口实现了更灵活的工厂逻辑
- 不同数据源对应的TransactionManager可以看作抽象工厂
6.2 设计题："如何设计跨平台文件系统访问？"
推荐方案：
mermaid复制classDiagram
class FileSystemFactory {
<<interface>>
+createFile() File
+createFolder() Folder
}
class WindowsFSFactory {
+createFile() WindowsFile
+createFolder() WindowsFolder
}
class UnixFSFactory {
+createFile() UnixFile
+createFolder() UnixFolder
}
6.3 陷阱题："为什么不用抽象类代替工厂接口？"
技术要点：
- Java8以后接口可以有默认方法
- 接口支持多继承，更灵活
- 符合面向接口编程原则
7. 现代语言中的新特性应用
7.1 Java中的lambda简化
传统工厂接口可以用Supplier替代：
java复制// 传统方式
LoggerFactory factory = () -> new ConsoleLogger();
// 现代方式
Supplier<Logger> factory = ConsoleLogger::new;
7.2 C++20中的Concept约束
可以给模板工厂添加更强的类型约束：
cpp复制template<typename T>
concept DBFactory = requires {
{ T::createConnection() } -> std::convertible_to<Connection>;
{ T::createStatement() } -> std::convertible_to<Statement>;
};
7.3 Kotlin的object声明
单例工厂的简洁实现：
kotlin复制object WindowsFactory : GUIFactory {
override fun createButton(): Button = WinButton()
override fun createCheckbox(): Checkbox = WinCheckbox()
}
8. 反模式与常见错误
8.1 工厂膨胀问题
症状：工厂类数量爆炸式增长
解决方案：
- 使用参数化工厂方法
- 引入原型注册表
- 考虑用依赖注入框架替代
8.2 循环依赖陷阱
当产品依赖工厂，工厂又依赖产品时：
java复制class ProductA {
private Factory factory; // 错误示范
}
修正方案：通过方法参数传递依赖
8.3 测试维护难题
Mock技巧：
- 对工厂接口进行测试替身
- 使用工厂的工厂来切换测试环境
- 自动化生成工厂的测试用例
9. 模式演进与替代方案
9.1 依赖注入的冲击
现代框架如Spring通过DI容器：
- 自动管理对象生命周期
- 声明式配置替代硬编码工厂
- 支持更灵活的装配方式
但工厂模式在框架底层仍然广泛存在。
9.2 函数式编程的影响
在Clojure等语言中：
- 工厂函数就是普通的高阶函数
- 产品创建可以延迟到运行时决定
- 模式边界变得模糊
9.3 元编程替代方案
Ruby/Python中常用：
- 类装饰器实现工厂
- 动态类生成技术
- 猴子补丁修改创建逻辑
10. 实际项目中的折中方案
在维护遗留系统时，我经常采用这些过渡方案：
- 混合模式：核心组件用抽象工厂，边缘功能用工厂方法
- 自动生成：用注解处理器生成工厂代码
- 渐进重构：先引入工厂接口，再逐步替换直接实例化
对于中小型项目，我的经验法则是：当发现同一地方有多个相关的new语句时，就该考虑引入工厂模式了。