🏗️ 创建型设计模式 总结与对比
创建型模式关注的是：
如何创建对象，以及何时创建、创建谁、由谁来创建、创建后如何使用，以提高灵活性和可维护性。
🧱 一张总览表
| 模式名 |
作用 |
是否抽象产品？ |
是否抽象创建？ |
典型用途 |
| 单例模式 |
确保一个类只有一个实例 |
❌ |
❌ |
配置中心、线程池、缓存、全局管理器 |
| 简单工厂模式 |
根据传参返回不同产品（由工厂判断创建） |
✅ |
❌（逻辑集中） |
创建不同支付对象、消息对象等 |
| 工厂方法模式 |
每个产品一个工厂，创建逻辑分散 |
✅ |
✅ |
日志框架（Log4j）、数据库连接等 |
| 抽象工厂模式 |
一组产品族的工厂 |
✅ |
✅ |
跨平台 UI 工厂、支付系统不同渠道下创建组件组合 |
| 建造者模式 |
按步骤构建复杂对象，过程与构造分离 |
✅ |
✅ |
构造复杂订单、Http 请求、Burger 套餐等 |
| 原型模式 |
通过克隆创建对象 |
✅ |
❌（靠 clone） |
创建类似对象但仅改动少量字段，性能敏感场景 |
🧠 使用时重点考虑的问题
| 你关心的问题 |
推荐模式 |
原因说明 |
| 只允许创建一个实例？ |
✅ 单例模式 |
控制资源使用，全局共享 |
想屏蔽 new 操作？ |
✅ 工厂模式（简单工厂、工厂方法） |
将对象创建封装在工厂中，调用者无需关系具体实现 |
| 创建的对象构造过程复杂？ |
✅ 建造者模式 |
按步骤构造，链式调用清晰，避免构造器参数过多问题 |
| 创建的是“产品族”？ |
✅ 抽象工厂模式 |
一整套相互关联的产品，且产品种类/平台变动频繁 |
| 创建的对象几乎一样？ |
✅ 原型模式 |
直接克隆已有对象，比重新 new 更高效 |
🎨 举个统一支付场景串起来：
| 模式 |
在支付系统中的应用举例 |
| 单例模式 |
支付配置中心（如支付宝/微信配置，全局唯一） |
| 简单工厂模式 |
根据参数返回不同支付方式（AliPay、WeChatPay） |
| 工厂方法模式 |
每种支付方式对应一个工厂（AliPayFactory、WeChatPayFactory） |
| 抽象工厂模式 |
不同支付渠道（如国内支付、国际支付）下，每个渠道下生产一组组件（配置、签名器、处理器） |
| 建造者模式 |
构建一笔复杂支付订单（设置支付人、金额、渠道、附加参数等） |
| 原型模式 |
复制一笔订单对象，快速改个金额或时间重发 |
✅ 总结小卡片（记忆口诀）
| 模式名 |
一句话总结 |
| 单例模式 |
整个系统只要我一个（全局唯一） |
| 简单工厂模式 |
交给我，我帮你判断该创建谁（集中创建逻辑） |
| 工厂方法模式 |
每个产品自己有个工厂（创建细化、符合开闭） |
| 抽象工厂模式 |
一次造一整套（产品族）东西（如手机 + 配件 + UI） |
| 建造者模式 |
按步骤一步步造，参数清晰流程稳（构建复杂对象） |
| 原型模式 |
拿现成的复制，改一点再用（高性能克隆） |
🔍 创建型模式之间的对比图
| 模式 |
是否抽象产品 |
是否抽象创建逻辑 |
是否封装构建过程 |
是否共享实例 |
关键目的 |
| 单例 |
❌ |
❌ |
❌ |
✅ |
控制实例数量 |
| 简单工厂 |
✅ |
❌ |
❌ |
❌ |
用参数选择创建谁 |
| 工厂方法 |
✅ |
✅ |
❌ |
❌ |
多个产品多个工厂 |
| 抽象工厂 |
✅（产品族） |
✅ |
❌ |
❌ |
创建一组相关对象 |
| 建造者 |
✅ |
✅ |
✅ |
❌ |
构建步骤复杂的对象 |
| 原型 |
✅ |
❌（靠 clone） |
✅（复制） |
❌ |
快速复制已有对象 |
🧠 实战建议
- 优先从简单工厂 → 工厂方法 → 抽象工厂演进（复杂度升级）
- 构造复杂对象时考虑建造者；克隆对象考虑原型；
- 需要控制资源实例唯一性则选择单例；
- 工厂类多了，记得结合配置 + 反射 + 依赖注入（Spring 框架天然支持工厂注册）