在软件系统中,对象的创建并不是一个“语法问题”,而是一个架构控制问题。
创建型模式解决的核心不是“如何 new 对象”, 而是:谁来控制对象的诞生方式、创建时机与生命周期?
当系统规模扩大,对象创建会暴露出三个根本性风险:
变化失控
复杂性泄漏
生命周期失序
👉 创建型模式的本质目标:
将“对象如何诞生”的不稳定性,从业务逻辑中隔离出来, 并集中到可治理、可演进的位置。
从原理层看,所有创建型模式都在回答同一组问题:
| 维度 | 核心问题 |
|---|---|
| 创建时机 | 立即创建?延迟创建?按需创建? |
| 创建复杂度 | 一步完成?多步构造?复制生成? |
| 生命周期 | 短生命周期?长生命周期?全局唯一? |
| 变化来源 | 类型变化?结构变化?产品族变化? |
不同模式 = 对这些变量的不同控制策略
当一个对象的创建:
此时,“构造函数”已不再是合适的抽象。
Builder 的本质: 将“构建过程”从“最终表示”中剥离出来
Builder 引入三个角色分离关注点:
| 角色 | 责任 |
|---|---|
| Builder | 定义构建步骤 |
| ConcreteBuilder | 实现具体构建细节 |
| Director | 控制构建顺序 |
👉 控制权变化: 对象不再“被一次性构造”,而是“被过程性组装”。
Builder 适用于:
而不适用于:
interface Builder {
Builder process1();
Builder process2();
Builder process3();
Product build();
}
Director 将构建逻辑集中:
public Product constructProduct(Builder builder){
builder.process1();
builder.process2();
builder.process3();
return builder.build();
}
工厂模式的本质不是“替你 new”, 而是:将“产品类型变化”从使用方隔离出去
优点:
根本问题:
👉 适合小系统,不适合演进型系统
将“创建哪个产品”的决策权,下放到子类
核心思想:
这使得:
👉 工厂方法本质上是一种 “创建逻辑的多态化”
抽象工厂解决的是更高阶的问题:
不是“创建一个产品”, 而是“创建一组相互依赖、风格一致的产品”
典型场景:
⚠️ 代价:
| 模式 | 控制的变化 |
|---|---|
| 简单工厂 | 创建参数 |
| 工厂方法 | 产品类型 |
| 抽象工厂 | 产品族一致性 |
当对象:
此时,“重新构建”是一种浪费。
原型模式的核心思想: 用已有实例作为创建模板
但其风险在于:
@Override
protected Object clone() throws CloneNotSupportedException {
Product product = (Product) super.clone();
product.part1 = (Part1) part1.clone();
return product;
}
👉 原型的难点不在 clone,而在“复制语义是否正确”
Singleton 解决的不是“创建问题”, 而是**“全局生命周期失控问题”**
它本质上是一种:
这些都是实现策略,而非设计本身。
👉 Singleton 往往是“阶段性方案”,而非终局设计
Singleton
↓
Factory + 配置
↓
DI 容器
↓
显式生命周期管理
| 模式 | 核心控制点 | 主要代价 |
|---|---|---|
| Builder | 构建过程 | 引入额外对象 |
| Factory Method | 产品类型 | 类数量增加 |
| Abstract Factory | 产品族 | 扩展受限 |
| Prototype | 创建成本 | 拷贝复杂 |
| Singleton | 生命周期 | 全局状态 |