工厂模式通过将对象创建逻辑集中封装，解耦业务代码与具体实现，支持动态类型选择、统一配置管理及后续架构演进。
工厂模式解决了对象创建与使用紧耦合的问题，把“怎么造对象”从业务逻辑里摘出来，让代码更易扩展、维护和测试。
解耦创建逻辑和业务逻辑
没有工厂时，每新增一个产品类型，往往要在多处 new 具体类，比如支付模块里直接写 new Alipay() 或 new WechatPay()。一旦加新支付方式（如 ApplePay），就得改所有用到的地方。工厂模式把创建过程集中到一个地方（工厂类），业务代码只面向接口编程，完全不知道具体实现是谁。
- 业务层调用 PaymentFactory.create("alipay")，拿到 Payment 接口实例
- 新增 ApplePay？只需在工厂里加一行判断，不碰任何已有业务代码
- 测试时还能轻松替换为 MockPayment，不用动真实创建逻辑
统一管理对象的生命周期和配置
有些对象创建成本高（如数据库连接池）、依赖复杂（需注入多个服务）、或需要特定初始化（如设置超时、重试策略）。工厂可以封装这些细节，确保每次创建都符合规范。
- 比如 HttpClient 工厂可统一设置连接池大小、默认 header、SSL 配置
- 避免每个调用方重复写相同的 builder 链或 try-catch 初始化逻辑
- 必要时还能做单例缓存、线程安全控制、或根据环境返回不同实现
支持运行时动态决定具体类型
实际项目中，对象类型常由配置、参数、用户行为等外部因素决定。工厂模式天然适配这种场景，把“选哪个类”交给工厂决策，而不是硬编码在业务分支里。
立即学习“Java免费学习笔记（深入）”；
- 读取配置文件中的 payment.type=wechat，工厂据此返回对应实例
- 根据 HTTP Header 中的 User-Agent 创建不同解析器（PC版/移动端/爬虫）
- 结合策略模式，让工厂成为策略选择的入口，进一步提升灵活性
为后续演进留出空间
工厂不是终点，而是抽象的第一步。它让“创建”这件事变得可插拔——今天是简单静态工厂，明天可升级为抽象工厂（管理产品族），后天接入 Spring 的 BeanFactory，甚至对接 SPI 机制。
- Spring 的 @Bean 方法本质就是工厂方法
- Java 的 ServiceLoader 机制背后也是工厂思想：按约定加载实现类
- 微服务中，工厂还可包装远程服务发现逻辑，隐藏 RPC 创建细节
