设计模式 on 纪伟的个人博客

设计模式实战（九）：命令与状态模式——CQRS 与状态机的落地

Sat, 03 Jan 2026 10:00:00 +0800

写在前面

收官篇。讲两个行为型模式——命令和状态。选它俩收尾，是因为它们正好接上 DDD 系列的两个核心：命令模式 = CQRS 里的 Command 对象（DDD 第五篇）；状态模式 = 订单聚合里的状态流转（DDD 第二篇）。

讲完这篇，设计模式系列和 DDD 系列就完美合龙了。

一、命令模式：把"请求"变成对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


场景：一个编辑器，要做"加粗""复制""粘贴"等操作，还要支持【撤销/重做】。

 朴素写法（直接调方法）：
 editor.Bold(); editor.Copy(); editor.Paste();
 问题：
 ✗ 没法撤销（不知道"刚才做了什么"）
 ✗ 没法排队、记录日志、宏录制
 ✗ 调用者（按钮/快捷键）和具体操作绑死

 反转：把"做一件事"封装成一个对象，里面记录"做什么 + 怎么撤"。
 调用者只管"执行这个对象"，不知道里面是什么操作。
 → 这就是命令模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


意图：把请求封装成对象，从而可以参数化、排队、记录、撤销。

 结构：
 ICommand ← 命令接口（Execute / Undo）
 ConcreteCommand ← 每个操作一个命令对象（持有接收者）
 Invoker ← 调用者（按钮、队列），触发命令
 Receiver ← 真正干活的（Editor、Service）

 价值：
 ✓ 撤销/重做（每个命令记录"怎么撤"）
 ✓ 队列/调度/延迟执行（命令是对象，可存可排）
 ✓ 宏/日志/重放（命令序列化、记录、批量）
 ✓ 调用者与接收者解耦

二、命令模式手写

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// 命令接口：执行 + 撤销
public interface ICommand
{
 void Execute();
 void Undo();
}

// 具体命令：加粗（持有接收者 Editor）
public class BoldCommand(Editor _editor) : ICommand
{
 private string? _previousText; // 记录撤销所需的状态
 public void Execute()
 {
 _previousText = _editor.Text;
 _editor.BoldSelection();
 }
 public void Undo() => _editor.Text = _previousText!;
}

// 调用者：命令历史栈，支持撤销
public class CommandHistory
{
 private readonly Stack<ICommand> _done = new();
 public void Execute(ICommand cmd) { cmd.Execute(); _done.Push(cmd); }
 public void Undo() { if (_done.Count > 0) _done.Pop().Undo(); }
}

1
2
3
4


关键：每个命令对象封装了"做什么 + 怎么撤"，
 调用者（历史栈）只管 Push/Pop/Execute，不关心具体操作。
 → 加新操作 = 加一个命令类，调用者不动（开闭）。
 → 撤销/重做、命令队列、宏录制，全靠"命令是对象"这一点。

三、.NET 里的命令模式：CQRS 的 Command

我在 DDD 第五篇讲 CQRS 时说过：写侧的入口是"命令"（CancelOrderCommand）。那正是命令模式的工程化应用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// CQRS 命令对象（MediatR 的 IRequest）
public sealed record CancelOrderCommand(Guid OrderId, string Reason) : IRequest;

// 命令处理器（接收者）
public class CancelOrderHandler(IOrderRepository _repo) : IRequestHandler<CancelOrderCommand>
{
 public async Task Handle(CancelOrderCommand cmd, CancellationToken ct)
 {
 var order = await _repo.Find(cmd.OrderId, ct) ?? throw new NotFoundException();
 order.Cancel(cmd.Reason);
 await _repo.Save(order, ct);
 }
}

// 调用者：发命令，不关心谁处理
await _mediator.Send(new CancelOrderCommand(orderId, "误操作"));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


对应关系：
 ICommand（Execute） → CancelOrderCommand（数据载体）+ Handler（逻辑）
 Invoker → MediatR（_mediator.Send 派发）
 Receiver → Order 聚合 / 仓储

 CQRS 把"命令"提升为一等公民：
 ✓ 可序列化、可入队（消息队列）、可重放
 ✓ 写侧与读侧、调用方与处理方解耦
 ✓ 配合事件溯源，命令/事件可审计
 → 这就是命令模式在现代架构里的"高阶用法"。

四、状态模式：行为随状态变

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


场景：订单有 草稿/已下单/已支付/已发货/已取消 多种状态，
 每种状态下，"能不能改地址""能不能取消""能不能再付款"的规则都不一样。

 朴素写法（每个方法里一堆 switch 状态）：
 void Cancel() {
 switch (Status) {
 case Draft: ...; break;
 case Placed: ...; break;
 case Shipped: throw "已发货不能取消"; break;
 ...
 }
 }
 void ChangeAddress() { switch (Status) {...} }
 void Pay() { switch (Status) {...} }
 病：
 ✗ 每个方法都重复判断状态，switch 满天飞
 ✗ 加新状态 = 改所有方法的 switch
 ✗ 状态流转规则散落，看不出"某状态下能做什么"

 反转：把"每种状态下的行为"封装成对象，让当前状态对象决定行为。
 → 这就是状态模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


意图：对象行为随状态变化，把每种状态封装成类，自动切换。

 结构：
 IState ← 状态接口（Cancel/Pay/ChangeAddress）
 ConcreteState ← 每种状态一个实现（DraftState/PaidState...）
 Context ← 持有当前状态，把行为委托给它

 vs 一堆 switch：
 ✓ 每种状态的行为内聚在一个类
 ✓ 加新状态 = 加一个状态类，老的不动（开闭）
 ✓ 状态流转规则集中、清晰

五、状态模式 vs DDD 的状态机

在 DDD 第二篇里，订单聚合的状态流转是这样写的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class Order : Entity<OrderId>, IAggregateRoot
{
 public OrderStatus Status { get; private set; }

 public void Cancel(string reason)
 {
 if (Status >= OrderStatus.Shipped)
 throw new DomainException("已发货不能取消");
 Status = OrderStatus.Cancelled;
 }
 public void MarkPaid() { /* 仅 Placed → Paid */ }
 public void Ship() { /* 仅 Paid → Shipped */ }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


这是状态模式的"轻量版"：
 - 状态用枚举表示（OrderStatus）
 - 行为内聚在聚合根方法里（Cancel/MarkPaid/Ship 各自校验 + 流转）
 - 没有为每种状态单独建类（订单状态不多，枚举够用）

 对比完整状态模式（每种状态一个类）：
 当状态非常多、每个状态行为复杂、流转规则庞大时，
 才值得拆成 IState + 各 State 类。
 订单这种 5 个状态、规则简单的场景，枚举 + 聚合方法就够（YAGNI）。

 → DDD 的 OrderStatus 是状态模式的务实落地，不是完整形态。

六、状态 vs 策略（极易混）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


两者结构几乎一样（都是"持有当前对象，委托行为"），但意图不同：

 策略模式：客户端【主动选】一个算法
 → 算法之间平等，可随时替换，互不转换
 → 例：选折扣算法、选排序方式
 → "用哪个"由外部决定

 状态模式：对象【根据当前状态】自动表现不同行为，状态间会【转换】
 → 状态之间有流转关系（Draft → Placed → Paid）
 → "现在是哪个"由对象自己管理
 → 例：订单状态机、TCP 连接状态

 鉴别：
 选项会互相转换、有生命周期 → 状态
 选项平行、随时换、互不转换 → 策略

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


命令模式：
 ✓ 需要撤销/重做、命令队列、宏录制、任务调度
 ✓ 调用者与执行者解耦（CQRS、事件驱动）
 ✗ 简单一次性调用、不需要撤销/排队 → 直接调方法

状态模式：
 ✓ 对象状态多、每状态行为不同、状态间有流转
 ✓ switch(state) 满天飞、加状态要改一堆方法
 ✗ 状态少、规则简单 → 枚举 + 几个 if 就够（DDD 订单就是）
 ✗ 是"选算法"而非"状态流转" → 那是策略

八、小结

命令模式：把请求封装成对象 → 可撤销/排队/记录/解耦
- 手写：ICommand（Execute/Undo）+ 接收者 + 历史栈
- .NET 高阶：CQRS 的 Command + MediatR（呼应 DDD 第五篇）
状态模式：把每种状态的行为封装成类，行为随状态变
- 解决 switch(state) 满天飞，加状态加类（开闭）
- DDD 的 OrderStatus 是它的轻量落地（枚举够用就别拆类）
状态 vs 策略：状态有流转/生命周期，策略是平行可替换
务实原则：简单场景用枚举/直接调用，复杂了再上完整模式

九、设计模式系列总结

九篇下来，一条主线：

（一）SOLID 是底座：把变化关进笼子，所有模式的共同骨架
（二）策略：算法族可替换，干掉 switch
（三）工厂：封装创建，DI 容器是终极形态
（四）建造者：分步构造，对抗伸缩构造函数
（五）装饰器：透明叠加功能，组合优于继承
（六）责任链：处理者串链，ASP.NET Core 中间件的真相
（七）观察者：一对多通知，C# event 天生支持
（八）单例：全局唯一，优先 DI Singleton 别手写
（九）命令与状态：请求即对象（CQRS）、行为随状态变（状态机）

回到第一篇的初心：模式是"有名字的设计经验"，不是教条。.NET 里很多模式已经融化进语言和框架（event/委托/DI/ LINQ），你不必死记 UML，要记的是意图——什么问题、用什么解、付出什么代价。

和 DDD 系列、微服务系列合在一起看，你会发现它们都在讲同一件事：把复杂度控制在边界内、把变化封装起来、让代码对扩展开放对修改关闭。SOLID 是原则，模式是套路，DDD 是建模，架构是组合——殊途同归。真正理解了这一层，写出来的代码，天然就是好代码。

设计模式实战（八）：单例模式——全局唯一与它的反模式面

Tue, 30 Dec 2025 10:00:00 +0800

写在前面

单例是 23 个模式里名声最差的一个——不是因为它没用，而是因为它被滥用得最狠。新手最爱写单例（Instance 多酷），然后收获一堆"测试不了、并发炸了、依赖藏起来"的坑。

这篇不光讲怎么写单例，更要讲怎么别写单例——以及 .NET DI 容器提供的正确姿势。

一、问题：全局唯一实例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


有些对象，整个进程只要一个：
 - 配置读取器（Configuration）
 - 日志工厂（LoggerFactory）
 - 数据库连接池
 - 全局缓存（IMemoryCache）
 - 设备访问（打印机、硬件接口）

 为什么必须唯一：
 - 多个实例浪费资源（重复加载配置、多个连接池）
 - 多个实例导致状态不一致（两个缓存各存各的）
 - 有些资源本身是单点的（一个打印机）

 → 需求：保证一个类只有一个实例，全局可访问。
 → 这就是单例模式。

二、单例：保证全局唯一

1
2
3
4
5
6
7
8


意图：确保一个类只有一个实例，并提供全局访问点。

 要点：
 1. 构造函数私有（外部不能 new）
 2. 类内持有一个静态实例
 3. 提供一个静态访问点（Instance）

 关键词：唯一 + 全局可访问。

三、.NET 线程安全的几种写法

单例最大的技术难点是多线程下也要保证唯一。几种写法，从糙到精：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// ❌ 错：非线程安全，多线程下可能造出多个
public class BadSingleton
{
 private static BadSingleton? _instance;
 public static BadSingleton Instance =>
 _instance ??= new BadSingleton(); // 竞态：两个线程同时进来
}

// ✅ 写法 1：双检锁（经典，但要 volatile + lock）
public class DclSingleton
{
 private static DclSingleton? _instance;
 private static readonly object _lock = new();
 public static DclSingleton Instance
 {
 get
 {
 if (_instance is null) // 一检：已有就直接返，避免锁开销
 lock (_lock)
 if (_instance is null) // 二检：进了锁再确认一次
 _instance = new DclSingleton();
 return _instance;
 }
 }
}

// ✅✅ 写法 2：静态只读字段（最简洁，CLR 保证线程安全的懒初始化）
public class StaticSingleton
{
 public static readonly StaticSingleton Instance = new();
 private StaticSingleton() { } // 私有构造
} // CLR 在首次访问类时初始化 static 字段，且保证线程安全

// ✅✅✅ 写法 3：Lazy<T>（显式控制，延迟到首次访问 Instance）
public class LazySingleton
{
 private static readonly Lazy<LazySingleton> _lazy = new(() => new LazySingleton());
 public static LazySingleton Instance => _lazy.Value; // 线程安全 + 懒加载
 private LazySingleton() { }
}

1
2


现代 .NET 推荐：写法 2（static readonly，最简洁）或写法 3（Lazy<T>，最灵活）。
双检锁是 Java 时代的老黄历，C# 里基本不用了。

四、但请优先用 DI 容器的 Singleton

上面三种手写单例，现代 .NET 开发几乎都不用。理由是 DI 容器给了更干净的方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 注册为 Singleton —— 容器保证全局唯一
services.AddSingleton<IConfigurationReader, JsonConfigurationReader>();
services.AddSingleton<ILoggerFactory, LoggerFactory>();
services.AddSingleton<IMemoryCache, MemoryCache>();

// 用：构造函数注入，不直接碰 Instance
public class OrderService(IConfigurationReader _config, IMemoryCache _cache)
{
 ...
}

1
2
3
4
5
6
7
8
9


DI Singleton vs 手写单例：

 ✓ 全局唯一由容器保证（你不用操心线程安全）
 ✓ 显式依赖（构造函数注入，依赖一目了然，不藏）
 ✓ 可测试（单测时换 Transient/假实现，改注册即可）
 ✓ 生命周期集中管理（Singleton/Scoped/Transient 统一规则）
 ✓ 没有静态全局状态（Instance 全局可访问 = 反模式，下面讲）

 → 唯一性需求，首选 services.AddSingleton，别手写 Instance。

五、单例的反模式面（为什么名声差）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


手写单例（静态 Instance）的五大罪：

 1. 全局状态
 Instance 是全局可变点，任何代码都能访问修改
 → 状态在程序各处飘，谁改的、什么时候改的，无从追踪

 2. 隐藏依赖
 public void DoWork() { Config.Instance.Get(...) }
 → 方法签名看不出依赖 Config，像个隐式全局变量
 → 代码可读性、可测试性都差

 3. 测试困难
 单元测试想隔离，但 Instance 是全局静态，没法 mock/替换
 → 测试时不得不连真实配置/真实缓存
 → 详见《.NET 单元测试（四）：依赖注入与可测试性》

 4. 并发陷阱
 单例被多线程共享，状态必须自己加锁保护
 → 稍不留神就是竞态、死锁

 5. 生命周期捕获（.NET DI 专属大坑）
 services.AddSingleton<Foo>(); Foo 注入了一个 Scoped 服务
 → Singleton 持有 Scoped，Scoped 被强制升级为单例
 → 跨请求共享本不该共享的状态，数据串了
 → 容器会抛异常提醒（Cannot resolve scoped service from root provider）

 所以社区共识：能不用手写单例就不用，用 DI Singleton 替代。

六、什么时候仍需要单例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


不全是反模式，少数场景仍合理：

 ✓ 互斥的外部资源（硬件接口、单点打印机、全局信号量）
 ✓ 框架/底层组件的引导（LoggerFactory、Configuration 根）
 ✓ 性能敏感、确实只要一份的全局缓存

 但即便这些，也优先用 DI Singleton 表达"唯一性"，
 只在"必须用静态全局访问点"时（如扩展方法里取服务、遗留代码）才手写。

 判断：要的是"唯一性"，还是"全局可访问"？
 多数时候只要"唯一性" → DI Singleton 就够。
 真需要"全局随便谁能取"才手写 Instance。

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


该用（以 DI Singleton 形式）：
 ✓ 确需进程内唯一的共享资源（配置、缓存、连接池、日志工厂）
 ✓ 构造昂贵、可复用的无状态服务

别用：
 ✗ 只是为了"方便取"就上单例 → 那是全局变量，用依赖注入
 ✗ 有状态的"上下文"对象 → 单例会跨请求/跨线程串数据
 ✗ 为了少传参数 → 把依赖藏进单例 → 测试灾难
 ✗ Singleton 注入 Scoped 服务（生命周期捕获）

 信号：当你想写 `static Instance` 时，先问自己：
 "我能不能用 services.AddSingleton + 构造函数注入 代替？"
 99% 的答案是可以。

八、小结

意图：保证一个类只有一个实例，全局可访问
手写：私有构造 + 静态实例；线程安全用 static readonly 或 Lazy<T>（双检锁过时了）
正确姿势：services.AddSingleton<T>() —— 容器保证唯一，干净、可测
反模式五罪：全局状态、隐藏依赖、测试困难、并发陷阱、生命周期捕获（Singleton 注入 Scoped）
多数时候你要的是"唯一性"而非"全局可访问" → DI Singleton 足矣，别手写 Instance
要单例，先想 DI；手写静态 Instance 是最后手段

下一篇（收官）讲命令与状态模式——正好接上 DDD 里的 CQRS Command 和订单状态机，给整个模式系列收口。

设计模式实战（七）：观察者模式——C# event 的真相与领域事件

Fri, 26 Dec 2025 10:00:00 +0800

写在前面

我写 DDD 第四篇讲"领域事件"时说过：聚合做完自己的事，发个事件，通知所有感兴趣的下游。这套机制的底层，就是观察者模式。

而 C# 是所有语言里观察者模式最舒服的——event 和委托是语言级支持，不用手写。这篇讲清观察者，并把它和 DDD 领域事件、Rx 串起来。

一、问题：怎么通知"一群"依赖者？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


场景：订单状态变了，要通知：库存系统、积分系统、通知系统、报表系统。

 朴素写法（被观察者直接调用每个下游）：
 class Order {
 void StatusChanged() {
 _inventory.Handle(this);
 _points.Handle(this);
 _notifier.Handle(this);
 _report.Handle(this);
 }
 }
 病：
 ✗ 订单模块依赖了库存、积分、通知、报表 → 强耦合
 ✗ 加一个新下游（比如风控）要改 Order 类 → 违反开闭
 ✗ 下游增减要在被观察者里改

 病根：被观察者"主动知道"每个下游是谁。
 反转：让下游"主动订阅"，被观察者只负责"广播"，不认识具体下游。
 这就是观察者模式。

二、观察者：发布者 + 订阅者

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


意图：定义对象间一对多依赖。一个对象状态变化，所有依赖者自动收到通知。

 角色：
 Subject（主题/发布者）—— 持有一组观察者，状态变化时遍历通知
 Observer（观察者） —— 提供更新接口，被通知时执行

 关键：
 - 发布者不认识具体观察者，只认识接口
 - 订阅者随时 + / - 加入退出
 - 一对多（一个发布者 → N 个订阅者）

 应用：事件总线、消息广播、UI 数据绑定、领域事件、响应式编程

三、C# 的 event/委托 = 天生观察者

很多语言要手写 Subject/Observer 接口。C# 直接把这套做进了语言：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 1. 声明一个事件（发布者）
public class Order
{
 // event 关键字 = 受控的观察者列表；EventHandler = 标准回调签名
 public event EventHandler<OrderStatusChangedEventArgs>? StatusChanged;

 public void Cancel()
 {
 Status = Cancelled;
 // 2. 状态变化时，触发事件 = 通知所有订阅者
 StatusChanged?.Invoke(this, new OrderStatusChangedEventArgs(Status));
 }
}

// 3. 订阅者：用 += 注册，-= 取消
order.StatusChanged += Inventory.OnOrderStatusChanged;
order.StatusChanged += Points.OnOrderStatusChanged;
order.StatusChanged += Notifier.OnOrderStatusChanged;

// 订单状态一变，三个订阅者自动被调用
order.Cancel();

1
2
3
4
5
6
7
8


拆解：
 event → Subject 的"观察者列表"（语言帮你管，外部只能 +=/-=）
 EventHandler → Observer 接口的化身（一个回调签名）
 Invoke → Subject 遍历通知
 += / -= → 订阅 / 取消订阅

 → GoF 那套 Subject/Observer 抽象，C# 用 event 三行就实现了。
 这就是上一篇说的"模式在 .NET 里融化进语言"的典型。

四、手写 IObservable / IObserver（标准接口）

如果不用 event，.NET 也提供了一对标准接口，常用于"推数据流"的场景：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 发布者
public class PriceFeed : IObservable<decimal>
{
 private readonly List<IObserver<decimal>> _subs = new();
 public IDisposable Subscribe(IObserver<decimal> observer)
 {
 _subs.Add(observer);
 return new Unsub(() => _subs.Remove(observer)); // 返回"取消订阅"句柄
 }
 public void Push(decimal price)
 {
 foreach (var s in _subs) s.OnNext(price); // 通知所有订阅者
 }
}

// 订阅者
public class PriceLogger : IObserver<decimal>
{
 public void OnNext(decimal price) => Log($"价格: {price}"); // 收到数据
 public void OnError(Exception e) => Log($"出错: {e}");
 public void OnCompleted() => Log("结束");
}

1
2
3
4
5
6


event vs IObservable：
 event → "发生了一件事"通知（离散事件，如 StatusChanged）
 IObservable → "数据流"推送（连续序列，如股价、鼠标移动）

 后者配合 Rx（Reactive Extensions）能做强大的流式处理：
 窗口聚合、防抖、过滤、合并 —— 把事件当集合用。

五、和 DDD 领域事件的关系

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


DDD 第四篇讲的"领域事件"，本质就是观察者模式在领域层的应用：

 聚合（Order） = Subject，变更后发事件
 领域事件（OrderPlaced） = 通知的载荷
 下游订阅者（库存/积分/通知） = Observer
 事件分发器（MediatR 等） = Subject 的通知遍历机制

 对应关系：
 Order.Collect events → Dispatcher.Dispatch → 各 Handler.Handle
 就是 Subject.Notify → 遍历 Observers → 各 Observer.Update

 区别：
 C# event：进程内、同步（Invoke 直接调）
 领域事件：可进程内，也可跨服务（配 Outbox 走消息队列，最终一致）

 → DDD 领域事件不是新东西，是观察者模式在"跨边界/异步"场景的工程化。

六、坑：事件订阅不取消 = 内存泄漏

观察者模式最经典的坑，C# 里尤其要注意：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 短生命周期对象订阅了长生命周期对象的事件
public class MyWindow
{
 public MyWindow(Order longLivedOrder)
 {
 longLivedOrder.StatusChanged += OnChanged; // 订阅
 }
 void OnChanged(object? s, EventArgs e) { ... }
}

// Window 关闭、被丢弃后，只要 Order 还活着、还持有这个事件委托，
// 就等于持有 Window 的引用 → Window 永远不被 GC → 内存泄漏！

1
2
3
4
5
6
7
8
9


原因：event 持有订阅者的委托 = 持有订阅者的引用。
 订阅者想被回收，必须先 -= 取消订阅。

 对策：
 1. 订阅者销毁前 -= 取消（实现 IDisposable）
 2. 短生命周期对象订阅长生命周期事件，用弱事件（WeakEventManager）
 3. 局部订阅用完即退，别让 lambda 偷偷持有 this

 这是观察者模式落地时最常见的 bug，面试常考。

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


该用观察者：
 ✓ 一对多通知（一个变化，多个下游关心）
 ✓ 发布者和订阅者要解耦（互不认识）
 ✓ 订阅者动态增减
 ✓ 事件驱动/响应式场景

别用：
 ✗ 就一对一回调 → 普通接口/委托就够，别上事件
 ✗ 调用顺序严格、必须按序、不能少 → 观察者顺序不定，别用
 ✗ 需要订阅者返回值/同步结果 → 事件是单向通知，不适合
 ✗ 忘了管理生命周期 → 泄漏

 信号：当 A 的变化要让 B、C、D 都反应，但 A 不想认识 B/C/D —— 上观察者。

八、小结

问题：一对多通知，发布者不该认识每个下游
观察者模式：Subject 持有一组 Observer，状态变化时遍历通知
C# event 是天生观察者：event = 观察者列表，+=/-= = 订阅/取消，Invoke = 通知
IObservable/IObserver：标准接口，适合数据流（配合 Rx）
领域事件就是观察者在 DDD 的工程化（进程内或跨服务）
大坑：事件订阅不 -= → 内存泄漏（订阅者被发布者持有，无法 GC）
信号：一变多通知、要解耦 → 观察者

下一篇讲单例模式——以及它为什么是"最该谨慎使用的模式"（反模式面 + DI 的正确姿势）。

设计模式实战（六）：责任链模式——ASP.NET Core 中间件的真相

Mon, 22 Dec 2025 10:00:00 +0800

写在前面

这是本系列的重头戏。因为责任链模式在 .NET 后端有一个教科书级的应用——ASP.NET Core 的中间件管道。你天天写 app.UseAuthentication()、app.UseRouting()，它们的底子就是责任链。

读完这篇，你不光懂这个模式，还会"从原理上"看透你写过的那 5 篇 ASP.NET Core 笔记里的中间件机制。

一、问题：一个请求，多种处理，谁来管？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


场景：一个 HTTP 请求进来，要依次经过：
 异常处理 → 日志 → 鉴权 → 路由 → 限流 → 缓存 → 业务处理

 朴素写法（在入口方法里一堆 if/调用）：
 Handle(req) {
 ExceptionFilter(req);
 Logger(req);
 Auth(req);
 Route(req);
 ...
 }
 病：
 ✗ 顺序写死在代码里，改顺序要动入口
 ✗ 每加一环改这里，违反开闭
 ✗ 处理者互相耦合，没法单独插拔
 ✗ 谁该处理、处理到哪停、怎么传递——全糊在一起

 病根：把"一串处理者"硬编进了一个方法。

二、责任链：处理者串成链，请求沿链传递

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


意图：把多个处理者串成链，请求沿链传递。
 每个处理者决定：自己处理、处理完往下传、还是直接短路。

 结构：
 IHandler ← 处理者接口
 ConcreteHandler（持有一个 next） ← 处理 + 决定是否传给下一个

 关键：
 - 发送者不知道谁最终处理（解耦）
 - 每个处理者只关心自己的事 + 要不要传
 - 顺序由链的组装决定（可配置）
 - 任何一环可以"短路"（不调 next，终止链）

 适用：请求要经过一串处理步骤、顺序敏感、可能中途短路。

三、经典手写

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// 处理者接口：处理 + 持有下一个
public abstract class Handler
{
 private readonly Handler? _next;
 protected Handler(Handler? next) => _next = next;
 public virtual void Handle(Request req)
 {
 _next?.Handle(req); // 默认：只往下传
 }
}

// 具体处理者：鉴权
public class AuthHandler(Handler? next) : Handler(next)
{
 public override void Handle(Request req)
 {
 if (!req.IsAuthenticated)
 {
 req.Respond(401);
 return; // 短路：不调 base.Handle，链终止
 }
 base.Handle(req); // 通过 → 传给下一个
 }
}

// 具体处理者：限流
public class RateLimitHandler(Handler? next) : Handler(next)
{
 public override void Handle(Request req)
 {
 if (OverLimit(req)) { req.Respond(429); return; }
 base.Handle(req);
 }
}

// 组装链（顺序在这里定，可配置）
var chain = new AuthHandler(
 new RateLimitHandler(
 new BusinessHandler(null)));
chain.Handle(request);

1
2
3
4


重点看两种处理者的行为：
 - 通过 → base.Handle(req) → 传给 next
 - 拒绝 → return → 短路，next 不执行
 发送方只管 chain.Handle(request)，不关心谁处理、在哪停。

四、重头：ASP.NET Core 中间件 = 责任链

ASP.NET Core 的请求管道，就是责任链模式的工业级实现。我写过 5 篇 ASP.NET Core 笔记，这里把它的原理彻底拆开。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 你写的中间件长这样：
app.Use(async (context, next) =>
{
 // —— 进站：请求往里走时执行 ——
 Console.WriteLine("请求进入: " + context.Request.Path);

 await next(); // ← 把控制权交给链的下一个中间件

 // —— 出站：响应往回走时执行 ——
 Console.WriteLine("响应状态: " + context.Response.StatusCode);
});

1
2
3
4
5
6
7


这段代码的每一部分，对应责任链的每一环：

 next → 就是责任链里的 "_next"，"下一个处理者"
 await next() → base.Handle()，把请求传下去
 不调 next → 短路（如 app.Run，或鉴权失败直接 401 返回）
 进站逻辑 → 处理者"自己的事"
 出站逻辑 → next() 返回后执行（洋葱模型，后面讲）

4.1 洋葱模型（Onion / Pipeline）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


请求像一个箭头穿入、再穿出洋葱：

 ┌─ 异常处理（最外层，最后兜底）
 │ ┌─ 日志
 │ │ ┌─ 鉴权
 │ │ │ ┌─ 路由 → 控制器
 │ │ │ │
 请求 → → → → → → → → 处理
 │ │ │ │
 │ │ │ └─ 出站：鉴权后置逻辑
 │ │ └──── 出站：日志记录响应
 │ └─────── 出站：异常处理收尾
 └──────────

 每个中间件 next() 之前的代码 = "进站"（按外→内顺序执行）
 next() 之后的代码 = "出站"（按内→外顺序执行）

 → 这就是为什么"鉴权放最后注册能拦住所有人""日志放最外层能记到所有响应"
 注册顺序（UseAuthentication、UseRouting 的先后）决定一切。

4.2 中间件类的写法（封装成类）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 约定俗成的中间件类写法
public class RequestTimingMiddleware
{
 private readonly RequestDelegate _next; // ← 这就是"下一个处理者"
 public RequestTimingMiddleware(RequestDelegate next) => _next = next;

 public async Task InvokeAsync(HttpContext ctx)
 {
 var sw = Stopwatch.StartNew();
 try { await _next(ctx); } // 传给下一个
 finally { sw.Stop(); Log($"{ctx.Request.Path} {sw.ElapsedMilliseconds}ms"); }
 }
}
// 注册
app.UseMiddleware<RequestTimingMiddleware>();

1
2
3
4
5


RequestDelegate = "下一个处理者"的类型别名：
 public delegate Task RequestDelegate(HttpContext context);
 → 它就是 Handler.Handle(Request) 的现代化身。

 整个 ASP.NET Core 管道，就是一条由 RequestDelegate 串起来的责任链。

五、为什么用责任链（而不是别的）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


中间件用责任链的好处：

 ✓ 解耦：每个中间件只管自己的事（鉴权、限流、日志互不知）
 ✓ 可插拔：加/删中间件 = 加/删一行注册，业务代码不动（开闭）
 ✓ 顺序可控：注册顺序即执行顺序，可配置
 ✓ 短路能力：鉴权失败 / 限流触发 → 不调 next，链终止
 ✓ 洋葱模型：进站、出站都能做事（前置 + 后置逻辑）

 这五条，正好是一个 Web 框架处理"请求-响应"最需要的能力。
 所以几乎所有主流 Web 框架的请求管道都是责任链变体
 （Express/Koa、Spring Filter、ASP.NET Core 中间件）。

六、责任链 vs 装饰器 vs 策略

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


容易混，一次分清：

 责任链：多个处理者串起来，请求沿链走，可短路
 → 重点：流程/管道，顺序敏感（鉴权→路由→业务）
 → ASP.NET Core 中间件

 装饰器：层层包裹，每层加功能，不短路（一定传到内核）
 → 重点：增强单一对象（日志/缓存/重试）
 → Stream、IRepository 装饰

 策略：从一组算法里选一个执行
 → 重点：多选一（折扣/支付方式）
 → 不串链、不叠加

 鉴别：
 "要经过一串步骤，可能中途停" → 责任链
 "要给一个对象叠加功能" → 装饰器
 "要从几种做法里选一种" → 策略

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


该用责任链：
 ✓ 请求要经过有序的多步骤处理（Web 管道、审批流、事件处理链）
 ✓ 步骤可插拔、顺序可配置
 ✓ 需要"任一环可决定终止"的短路能力
 ✓ 处理者之间要解耦

别用：
 ✗ 步骤固定、就两三步、顺序不变 → 直接调函数更清楚
 ✗ 是"选一种算法"而非"经过一串" → 那是策略
 ✗ 是"叠加功能"而非"流程传递" → 那是装饰器

 信号：当你写出一个超长的 Handle() 方法，
 里面对一个请求依次做 N 件不同的事，还可能提前 return ——
 拆成责任链。

八、小结

问题：一串处理步骤硬编在一个方法里，顺序死、难扩展
责任链：处理者串链，请求沿链传递，每环可处理/传递/短路
经典手写：Handler 抽象 + 持有 next + Handle 转发或短路
ASP.NET Core 中间件就是责任链：next = 下一个处理者，RequestDelegate = Handler
洋葱模型：next() 前是进站、后是出站，注册顺序决定执行顺序
核心价值：解耦、可插拔、顺序可控、短路能力
vs 装饰器/策略：责任链是"流程"，装饰器是"增强"，策略是"多选一"
这是 ASP.NET Core 管道的原理，看透了它，5 篇 ASP.NET Core 笔记里的中间件就全通了

下一篇讲观察者模式——C# 的 event 委托天生就是观察者，以及它和 DDD 领域事件的关系。

设计模式实战（五）：装饰器模式——透明地叠加功能

Thu, 18 Dec 2025 10:00:00 +0800

写在前面

需求来了：给所有数据库操作的仓储加日志、加缓存、加重试。怎么办？

新手通常去改 OrderRepository 的源码——把日志、缓存、重试塞进每个方法。这一塞就糟了：核心逻辑被淹没，加一个仓储要重抄一遍，改日志格式要动所有仓储。这篇讲装饰器模式——不动原类，把功能一层层"套"上去。

一、问题：继承爆炸

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


想给 IRepository 加：日志、缓存、重试，三种功能自由组合。
 用继承怎么做？

 Repository
 ├── LoggedRepository
 ├── CachedRepository
 └── RetryRepository
 ├── LoggedRetryRepository
 ├── CachedLoggedRepository
 ├── CachedRetryRepository
 └── CachedLoggedRetryRepository ... (组合爆炸)

 病：
 ✗ N 个功能 → 2^N 个子类，指数爆炸
 ✗ 功能组合写死在类型里，运行时不能换
 ✗ 违反"组合优于继承"

 病根：把"叠加功能"当成"特化"，硬走继承。

二、装饰器：同接口 + 包裹一个同接口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


意图：动态地给对象添加职责，不改其接口。
 装饰器和被装饰者实现同一个接口，内部持有一个被装饰者。

 结构：
 IComponent ← 共同接口
 ConcreteComponent ← 被装饰的原始对象
 Decorator ← 实现同接口，内部持有 IComponent（可嵌套）

 关键：装饰器"是一个" IComponent，又"持有一个" IComponent。
 所以可以无限套娃：A 装 B，B 装 C，对外都是 IComponent。
 调用时，每层装饰器先做自己的事，再转给内层。

三、手写：给仓储叠加日志/缓存/重试

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


// 1. 共同接口
public interface IOrderRepository
{
 Task<Order?> Find(Guid id);
}

// 2. 原始实现（只管数据库，啥装饰都不带）
public class SqlOrderRepository : IOrderRepository
{
 public Task<Order?> Find(Guid id) { /* 查库 */ }
}

// 3. 装饰器基类：持有内部 IOrderRepository，方法默认转发
public class OrderRepoDecorator(IOrderRepository _inner) : IOrderRepository
{
 public virtual Task<Order?> Find(Guid id) => _inner.Find(id);
}

// 4. 具体装饰器：加日志
public class LoggingDecorator(IOrderRepository inner, ILogger log)
 : OrderRepoDecorator(inner)
{
 public override async Task<Order?> Find(Guid id)
 {
 log.LogInformation("Find {Id}", id);
 var result = await base.Find(id); // 调内层
 log.LogInformation("Result: {Found}", result is not null);
 return result;
 }
}

// 5. 具体装饰器：加缓存
public class CachingDecorator(IOrderRepository inner, IMemoryCache cache)
 : OrderRepoDecorator(inner)
{
 public override Task<Order?> Find(Guid id)
 => cache.GetOrCreateAsync(id, _ => base.Find(id));
}

1
2
3
4
5
6
7
8


// 用：按需套，顺序自由
IOrderRepository repo =
 new LoggingDecorator( // 最外层：记日志
 new CachingDecorator( // 中间层：查缓存
 new SqlOrderRepository() // 最内层：真查库
 ), logger);
// 调用方只认 IOrderRepository，不知道套了几层
await repo.Find(id);

1
2
3
4
5


对比继承爆炸：
 ✓ 加功能 = 写一个装饰器类，不是 2^N 子类
 ✓ 运行时自由组合顺序（先缓存还是先日志，拼装时决定）
 ✓ 原始类（SqlOrderRepository）纯净，只管核心职责
 ✓ 每个 Decorator 单一职责（开闭、SRP 都满足）

四、.NET 的教科书案例：Stream

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Stream 全家桶是装饰器的经典：

 FileStream fs = File.OpenRead("a.txt");
 var buffered = new BufferedStream(fs); // 套一层缓冲
 var gzip = new GZipStream(buffered, ...); // 再套一层压缩
 var reader = new CryptoStream(gzip, ...); // 再套一层加密

 FileStream / BufferedStream / GZipStream / CryptoStream
 都继承自 Stream（同接口），每个包一个 Stream（持有一个）。
 → 你可以任意组合：加密 + 压缩 + 缓冲，顺序自由。
 → 不需要"加密缓冲流""压缩加密流"这种组合类。

 认出这个套路，装饰器就懂了一半。

五、用 DI 让装饰器自动组装

手写套娃链（new LoggingDecorator(new CachingDecorator(...))）很烦。Scrutor 库给 .NET DI 加了装饰器支持，一行注册：

1
2
3
4
5


services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.Decorate<IOrderRepository, CachingDecorator>(); // 套缓存
services.Decorate<IOrderRepository, LoggingDecorator>(); // 再套日志

// 解析 IOrderRepository 时，容器自动按注册顺序套好装饰器返回

1
2
3
4
5
6


搭配 DI：
 ✓ 声明式组装，注册顺序即装饰顺序
 ✓ 装饰器自身也能注入依赖（ILogger、IMemoryCache）
 ✓ 切换/增减装饰器 = 改注册，不改业务代码

 这就是 ASP.NET Core 里做横切关注点（日志/缓存/重试/指标）的标准姿势。

六、装饰器 vs 代理 vs 适配器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


三个结构型模式都"包一个对象"，容易混：

 装饰器（Decorator）：同接口，加职责
 → 重点：给对象增加功能（日志/缓存/重试）
 → 接口不变、行为增强

 代理（Proxy）：同接口，控制访问
 → 重点：管"能不能访问/什么时候访问"（延迟加载、权限、远程代理）
 → 接口不变、加"管控"，不是加业务功能

 适配器（Adapter）：转换接口
 → 重点：把不兼容的接口转成期望的（A 接口 → B 接口）
 → 接口变了（这才是关键区别）

 一句话：装饰器加功能，代理加管控，适配器转接口。

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


该用装饰器：
 ✓ 横切关注点（日志、缓存、重试、指标、鉴权、校验）
 ✓ 想给对象叠加功能，但不改原类
 ✓ 功能要可组合、运行时配置顺序

别用：
 ✗ 功能和对象强绑定、永远不变 → 直接写进类更简单
 ✗ 只有一层、不会扩展 → 别为了模式而模式
 ✗ 需要"按条件选不同实现" → 那是策略/工厂的活

 信号：当你发现自己在 N 个类的每个方法里
 重复写"记日志 + try 重试 + 记指标" —— 就该上装饰器。

八、小结

问题：用继承叠加功能 → 子类组合爆炸
装饰器：同接口 + 内部持有一个同接口，可无限套娃
手写：装饰器基类转发 + 子类 override 加料，链式拼装
.NET 经典：Stream（FileStream/Buffered/GZip/Crypto）全家桶
DI 整合：Scrutor 的 Decorate<T, TDeco>() 一行组装
vs 代理/适配器：装饰器加功能、代理加管控、适配器转接口
典型场景：横切关注点（日志/缓存/重试/指标）

下一篇是本系列的重头——责任链模式，看 ASP.NET Core 中间件管道是怎么把它用到极致的。

设计模式实战（四）：建造者模式——优雅地构造复杂对象

Sun, 14 Dec 2025 10:00:00 +0800

写在前面

上一篇工厂解决"造哪个"。这篇解决另一个常见痛点：对象很复杂，怎么造得清爽。

想象一个对象有十几个字段，大多可选。你见过那种构造函数吗——new Order(cust, addr, null, null, true, null, "CNY", 0, ...)，调用方数参数能数瞎。这就是伸缩构造函数反模式（Telescoping Constructor），建造者模式就是它的解药。

一、问题：伸缩构造函数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 反模式：为了覆盖各种可选组合，构造函数越开越多
public class Mail
{
 public Mail(string from, string to) { ... }
 public Mail(string from, string to, string subject) { ... }
 public Mail(string from, string to, string subject, string body) { ... }
 public Mail(string from, string to, string subject, string body, IEnumerable<string> cc) { ... }
 public Mail(string from, string to, string subject, string body, IEnumerable<string> cc, bool html) { ... }
 // ... 还能继续开
}

// 调用方噩梦：这个 true 是啥？两个 null 又是啥？
var m = new Mail("a@x.com", "b@y.com", "Hi", null, null, true);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


这坨代码的病：
 ✗ 参数多，位置易错（传反了编译器不报）
 ✗ 一堆 null 占位，可读性极差
 ✗ 新增字段 → 又要开构造函数，或改所有现有构造函数
 ✗ 难以表达"必填 vs 可选"

 另一种"病"：用无参构造 + 一堆 setter
 var m = new Mail();
 m.From = ...; m.To = ...; m.Subject = ...;
 ✗ 对象在"半成品"状态就被别人看到（多线程下尤其危险）
 ✗ 字段可变，无法做不可变对象

二、建造者：分步构造 + 链式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


意图：把复杂对象的构造与它的表示分离。
 分步设置，最后一步统一"产出"，保证产出的对象是完整、一致的。

 结构：
 Director/客户端 → 调 Builder 的一系列设置方法（链式）→ 最后 Build() 得对象
 产出过程对象不可见（半成品状态不外泄）

 好处：
 ✓ 参数有名字（.Subject("Hi") 比 null 位置清晰）
 ✓ 必填/可选分明，可在 Build() 时校验
 ✓ 产出的对象可以是不可变的
 ✓ 加字段 = 加一个方法，老调用不受影响（开闭）

三、手写一个 fluent builder

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


// 目标对象：不可变（只读字段）
public sealed class Mail
{
 public string From { get; }
 public string To { get; }
 public string Subject { get; }
 public string Body { get; }
 public IReadOnlyList<string> Cc { get; }
 public bool IsHtml { get; }

 private Mail(string from, string to, string subject, string body,
 IReadOnlyList<string> cc, bool isHtml)
 {
 From = from; To = to; Subject = subject; Body = body; Cc = cc; IsHtml = isHtml;
 }

 // 建造者（嵌套类，唯一能造 Mail 的途径）
 public class Builder
 {
 private string _from = "", _to = "", _subject = "", _body = "";
 private List<string> _cc = new();
 private bool _isHtml;

 public Builder From(string v) { _from = v; return this; }
 public Builder To(string v) { _to = v; return this; }
 public Builder Subject(string v){ _subject = v; return this; }
 public Builder Body(string v) { _body = v; return this; }
 public Builder Cc(string v) { _cc.Add(v); return this; }
 public Builder AsHtml() { _isHtml = true; return this; }

 public Mail Build()
 {
 if (string.IsNullOrEmpty(_from) || string.IsNullOrEmpty(_to))
 throw new InvalidOperationException("From/To 必填");
 return new Mail(_from, _to, _subject, _body, _cc, _isHtml);
 }
 }
}

// 用：链式调用，一目了然
var mail = new Mail.Builder()
 .From("a@x.com")
 .To("b@y.com")
 .Subject("Hi")
 .Body("正文...")
 .Cc("boss@z.com")
 .AsHtml()
 .Build(); // 校验通过才产出完整对象

1
2
3
4
5


对比开头的噩梦：
 - 每个参数有名字，传不错位置
 - 必填校验在 Build() 里，半成品不会泄漏
 - 产出的 Mail 不可变，天然线程安全
 - 加字段 = Builder 加个方法，老代码不动

四、record 让建造者更简洁

如果对象不需要复杂校验，C# record + with 能省掉一大半样板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// record 自带"with 表达式"，本质就是个轻量建造者
public record MailSettings(string From, string To, string Subject = "",
 string Body = "", bool IsHtml = false);

// 用：必填位参 + 可选命名参数 + with 覆盖
var m = new MailSettings("a@x.com", "b@y.com") with { Subject = "Hi", IsHtml = true };

// 或要链式体验，用 record 写个轻量 builder
public record MailBuilder(string From, string To)
{
 public string Subject { get; init; } = "";
 public string Body { get; init; } = "";
 public bool IsHtml { get; init; }
}
var b = new MailBuilder("a@x.com", "b@y.com") { Subject = "Hi", IsHtml = true };

1
2
3
4
5
6
7


record + with / init：
 ✓ 极少样板代码
 ✓ 不可变
 ✓ 命名清晰

 适合：对象不复杂、校验少。
 对象复杂、需要严格分步和校验时，还是用上面的经典 builder。

五、.NET 里建造者无处不在

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


你天天见 builder，认出来了吗：

 EF Core：
 modelBuilder.Entity<Order>()
 .HasKey(o => o.Id)
 .HasOne(o => o.Customer)
 .WithMany(c => c.Orders); // ModelBuilder 是 builder

 ASP.NET Core：
 var builder = WebApplication.CreateBuilder(args);
 builder.Services.AddControllers();
 builder.Services.AddSwagger();
 var app = builder.Build(); // 经典分步构造 + Build()

 配置：
 configurationBuilder.AddJsonFile("app.json")
 .AddEnvironmentVariables()
 .Build();

 字符串：
 new StringBuilder().Append("a").Append("b").ToString(); // 最朴素的 builder

 它们共同点：链式设置 + 最后一步产出。
 这就是建造者模式的"语言级习惯"。

六、建造者 vs 工厂

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


常被搞混，区别其实清楚：

 工厂：一步产出对象
 var order = OrderFactory.Create(type);
 → 关心"造哪个"，一次到位

 建造者：分步产出对象
 var order = new OrderBuilder().For(cust).With(items).Express().Build();
 → 关心"怎么配置这一个"，逐步装配

 选择：
 对象创建简单、有几种类型 → 工厂
 对象字段多、可选参数多、要分步配置 → 建造者
 两者可配合：工厂返回一个 builder，让你再细调

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


该用建造者：
 ✓ 字段多（5+），尤其大多是可选
 ✓ 构造需要分步、有顺序、要校验
 ✓ 想要产出的对象不可变
 ✓ 配置类、DSL 式 API（Fluent 接口）

别用：
 ✗ 字段少、必填为主 → 普通构造函数 + record 就够
 ✗ 对象本身就该可变、简单 → 别硬套 builder 增加样板
 ✗ 只有一两种组合 → 工厂更直接

 信号：当你写构造函数写到参数列表比方法体还长、
 调用方需要数着位置传 null —— 就该上建造者了。

八、小结

问题：伸缩构造函数（参数越开越多）和 setter 半成品泄漏
建造者模式：分步链式设置 + 最后 Build() 产出，保证完整、可校验、可不可变
手写：嵌套 Builder 类，每个字段一个返回 this 的方法，Build() 时校验
现代 C#：record + with/init 能省掉大部分样板（简单场景）
.NET 里随处可见：EF Core ModelBuilder、WebApplication、配置、StringBuilder
vs 工厂：工厂一步造"哪个"，建造者分步配"这一个"
信号：构造参数列表长到要数 null，就上建造者

下一篇讲装饰器模式——怎么不改原类、透明地给对象叠加新功能（日志/缓存/重试）。

设计模式实战（三）：工厂模式——创建对象的烦恼与 DI 容器

Wed, 10 Dec 2025 10:00:00 +0800

写在前面

上一篇策略模式解决了"选算法"。这篇讲创建型模式的代表——工厂模式，解决"造对象"。

很多新手觉得工厂模式绕：简单工厂、工厂方法、抽象工厂，三个名字像、又不一样。这篇把它们一次讲清，并落到 .NET 上——你会发现 DI 容器本身就是个超级工厂，现代 .NET 开发里，大部分时候你不用手写工厂。

一、问题：到处 new

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 反例：直接 new，和具体类型死死绑死
public class OrderService
{
 public void Place(Order order)
 {
 var repo = new SqlOrderRepository(); // 写死具体实现
 var notifier = new EmailNotifier(); // 写死
 repo.Save(order);
 notifier.Send(order);
 }
}

1
2
3
4
5
6
7
8
9


这坨代码的病：
 ✗ 依赖具体类（SqlOrderRepository），不是抽象
 → 违反依赖倒置（DIP）
 ✗ 换实现（改 Mongo、换短信通知）要改这里
 ✗ 没法注入假实现做单元测试
 ✗ 如果构造对象本身复杂（要查配置、要条件判断），new 就更难看

 病根：对象"怎么造"和对象"怎么用"搅在一起了。
 解法：把"造"的责任抽出去——这就是工厂。

二、简单工厂（静态工厂）

最朴素：一个方法，按参数决定造哪个。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public static class DiscountFactory
{
 public static IDiscountStrategy Create(string type) => type switch
 {
 "Normal" => new NormalDiscount(),
 "Vip" => new VipDiscount(),
 "Employee" => new EmployeeDiscount(),
 _ => throw new ArgumentException($"未知折扣类型: {type}")
 };
}
// 用：var d = DiscountFactory.Create("Vip");

1
2
3
4
5
6
7


特点：
 ✓ 简单，集中了创建逻辑，调用方不关心具体类
 ✗ 严格说它不是"GoF 模式"，只是个习惯用法
 ✗ 违反开闭：加新类型要改这个 switch

 适合：创建逻辑简单、类型不多、不频繁变化。
 （上一篇策略模式里的"字典派发"，其实就是简单工厂的现代版。）

三、工厂方法（Factory Method）

把"创建"推迟到子类：父类定义流程，子类决定造哪个。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 父类：定义"创建 + 使用"的流程，但"造哪个"交给子类
public abstract class NotificationSender
{
 protected abstract INotifier CreateNotifier(); // 工厂方法（抽象）

 public void Send(string msg)
 {
 var notifier = CreateNotifier(); // 用子类造的对象
 notifier.Send(msg);
 }
}

// 子类 A：决定造 EmailNotifier
public class EmailSender : NotificationSender
{
 protected override INotifier CreateNotifier() => new EmailNotifier();
}
// 子类 B：决定造 SmsNotifier
public class SmsSender : NotificationSender
{
 protected override INotifier CreateNotifier() => new SmsNotifier();
}

1
2
3
4
5
6


vs 简单工厂：
 简单工厂：一个方法里 switch（加类型改 switch）
 工厂方法：每种类型一个子类（加类型加子类，老代码不动 → 开闭）

 代价：类变多。
 适合：创建逻辑需要配合一套"使用流程"，且类型会扩展。

四、抽象工厂（Abstract Factory）

造一"族"相关对象，保证它们配套。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 工厂接口：造一族 UI 控件
public interface IUiFactory
{
 IButton CreateButton();
 ITextBox CreateTextBox();
}
// 一族：Windows 风格
public class WindowsUiFactory : IUiFactory
{
 public IButton CreateButton() => new WindowsButton();
 public ITextBox CreateTextBox() => new WindowsTextBox();
}
// 另一族：Mac 风格
public class MacUiFactory : IUiFactory
{
 public IButton CreateButton() => new MacButton();
 public ITextBox CreateTextBox() => new MacTextBox();
}

1
2
3
4
5
6
7
8
9


vs 工厂方法：
 工厂方法：造"一个"产品（一个方法）
 抽象工厂：造"一族"配套产品（多个方法）

 价值：保证造出来的一组对象是配套的（不会 Windows 按钮配 Mac 文本框）。
 典型场景：跨平台 UI、多数据库方言、多主题样式。

 注意：抽象工厂常被滥用。如果只有一种产品，用工厂方法/简单工厂就够，
 别为了"显得有体系"上抽象工厂。

五、三者对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 造什么 加新产品 复杂度 适用
─────────────────────────────────────────────────────────────
简单工厂 单个产品 改 switch 低 类型少、简单
工厂方法 单个产品 加子类 中 类型会扩展
抽象工厂 一族产品 加子类+改接口 高 多族配套、跨平台

 记忆窍门：
 简单工厂 = 一个函数 switch
 工厂方法 = 把函数变成虚方法，让子类决定
 抽象工厂 = 工厂方法升级版，一个工厂造多个配套产品

六、.NET DI 容器 = 超级工厂

现代 .NET 里，你几乎不用手写工厂——DI 容器（IServiceCollection / IServiceProvider）就是工厂的终极形态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 注册：告诉"工厂"接口对应什么实现
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddSingleton<INotifier, EmailNotifier>();
services.AddTransient<IDiscountStrategy, VipDiscount>();

// 用：从"工厂"要对象，不关心怎么造
public class OrderService(IOrderRepository _repo, INotifier _notifier)
{
 public void Place(Order o) { _repo.Save(o); _notifier.Send(o); }
}

1
2
3
4
5
6
7
8


DI 容器相比手写工厂：
 ✓ 自动接管创建，包括依赖链（A 依赖 B，B 依赖 C，容器递归造）
 ✓ 生命周期（Singleton/Scoped/Transient）集中管理
 ✓ 切换实现 = 改注册一行，不改业务代码
 ✓ 测试时换假实现 = 改注册，详见《.NET 单元测试（四）：依赖注入与可测试性》

 → 这就是为什么 ASP.NET Core 里很少看到手写 XxxFactory：
 DI 把"工厂模式"这件事彻底标准化了。

需要手写工厂的场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 场景：运行时才能决定造哪个（配置/类型/参数）
services.AddScoped<IOrderRepository>(sp =>
{
 var config = sp.GetRequiredService<IConfiguration>();
 return config["Db"] == "Mongo"
 ? new MongoOrderRepository(config["Conn"])
 : new SqlOrderRepository(config["Conn"]);
}); // 工厂 lambda：容器调用时才执行

// 场景：解析未知类型（插件/动态加载）
var handler = ActivatorUtilities.CreateInstance(sp, typeFromConfig);
// 或按 key 取一批已注册的服务（variance）

1
2
3
4
5
6


什么时候仍要手写工厂：
 - 运行时根据配置/类型决定实现（DI 注册时还不确定）
 - 动态解析、插件化、按 key 派发（容器不直接支持"按字符串取"）
 - 构造对象需要运行时参数（不能预先注册）

 其余情况，让 DI 容器当你的工厂。

七、小结

问题：到处 new 把"造"和"用"绑死，违反依赖倒置
简单工厂：一个方法 switch 决定造哪个（类型少时够用）
工厂方法：抽象方法交给子类决定（加类型加子类，开闭）
抽象工厂：造一族配套产品（跨平台/多主题）
选型：简单→简单工厂；扩展→工厂方法；多族配套→抽象工厂
.NET DI 容器是终极工厂：日常开发基本不手写工厂，改注册即可
手写工厂仍有场景：运行时决定、动态解析、运行时参数

下一篇讲建造者模式——当构造对象本身很复杂（一堆可选参数）时，怎么造得优雅。

设计模式实战（二）：策略模式——干掉那一坨 if/switch

Sat, 06 Dec 2025 10:00:00 +0800

写在前面

上一篇讲 SOLID 的开闭原则时埋了个雷：折扣逻辑别写成一坨 if/switch。怎么改？答案就是策略模式。

这是后端开发用得最多的模式，没有之一。它解决的问题极常见：同一个动作有多种做法，需要按情况选一个。

一、问题：一坨 switch

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 反例：折扣计算，每加一种活动就往这里塞
public decimal CalculateDiscount(string type, decimal price)
{
 return type switch
 {
 "Normal" => price, // 不打折
 "Vip" => price * 0.8m, // VIP 八折
 "Coupon" => price - 50m, // 满减券
 "Employee" => price * 0.5m, // 员工五折
 _ => price
 };
}

1
2
3
4
5
6
7


这坨代码的病：
 ✗ 违反开闭原则：加"双11满3件打7折"要改这个方法（动老代码）
 ✗ 越长越难维护，分支互相影响
 ✗ 算法全堆一处，没法单独复用/测试
 ✗ DiscountService 依赖了所有折扣细节

 病根：把"选择哪个算法"和"算法本身"搅在一起了。

二、策略模式：把算法拆开

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


意图：定义一系列算法，各自封装，可互相替换。
 算法的变化不影响使用它的客户端。

 结构：
 IStrategy ← 算法的抽象接口
 ConcreteStrategy ← 每个算法一个实现
 Context ← 持有某个策略，把工作委托给它

 好处：
 ✓ 新增算法 = 加一个类，老代码不动（开闭）
 ✓ 算法可单独测试、复用
 ✓ 客户端不关心算法细节，只管"调它"

三、经典 OOP 实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


// 1. 策略接口
public interface IDiscountStrategy
{
 decimal Apply(decimal price);
}

// 2. 每个算法一个实现
public class NormalDiscount : IDiscountStrategy
{
 public decimal Apply(decimal price) => price;
}
public class VipDiscount : IDiscountStrategy
{
 public decimal Apply(decimal price) => price * 0.8m;
}
public class EmployeeDiscount : IDiscountStrategy
{
 public decimal Apply(decimal price) => price * 0.5m;
}

// 3. Context：把"算折扣"委托给注入进来的策略
public class PricingService(IDiscountStrategy _discount)
{
 public decimal GetFinalPrice(decimal price) => _discount.Apply(price);
}

1
2


现在加"双11折扣"：写一个 DoubleElevenDiscount 类，
PricingService 一行不用改 → 开闭原则达成。

四、现代 C#：不必每次都建类层次

很多策略其实就是"一段逻辑"，用 Func<decimal, decimal> 或 delegate 更轻：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 策略就是一个函数
public class PricingService
{
 private readonly Func<decimal, decimal> _discount;

 public PricingService(Func<decimal, decimal> discount) => _discount = discount;

 public decimal GetFinalPrice(decimal price) => _discount(price);
}

// 注册时直接传 lambda（配合 DI）
services.AddTransient<PricingService>(_ => new PricingService(p => p * 0.8m)); // VIP

多策略按 key 选——经典的"策略 + 工厂"组合，用字典派发最干净：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public class DiscountCalculator
{
 // 字典：type → 算法函数
 private readonly Dictionary<string, Func<decimal, decimal>> _strategies = new()
 {
 ["Normal"] = p => p,
 ["Vip"] = p => p * 0.8m,
 ["Coupon"] = p => Math.Max(0, p - 50m),
 ["Employee"] = p => p * 0.5m,
 };

 public decimal Calculate(string type, decimal price)
 => _strategies.TryGetValue(type, out var fn) ? fn(price) : price;
}

1
2
3
4
5
6
7


对比开头的 switch：
 - 加新折扣 = 字典加一行，方法体不动
 - 算法集中、清晰、可测
 - 没有多余的类层次，但拿到了策略模式的所有好处

 这就是 .NET 里策略模式的现代写法——
 "意图"没变（算法族可替换），"实现"从类层次简化成函数。

五、.NET 里策略无处不在

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


你天天在用策略模式，只是没意识到：

 LINQ：
 list.OrderBy(x => x.Name) // x => x.Name 就是一个"排序策略"
 list.Where(x => x.Active) // 过滤策略
 → 同样的 OrderBy，传不同 keySelector = 不同策略，框架替你 dispatch

 集合比较：
 new SortedSet<int>(Comparer<int>.Create((a, b) => b - a)) // 降序比较策略

 ASP.NET Core：
 config.AddJsonFile() / .AddEnvironmentVariables() // 每个"配置源"都是策略
 serializer options：不同的命名策略、枚举转换策略

 Task.Run / Parallel.ForEach 的并行度策略、
 EF Core 的值比较器（IEqualityComparer<T>）……

 本质都是：把"可替换的一段逻辑"作为参数传进去。

六、经典 OOP 形态 vs 现代函数形态，怎么选

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


用类（IDiscountStrategy 接口 + 实现）：
 ✓ 算法复杂、有状态、需要注入依赖（VIP 折扣要查用户等级）
 ✓ 多处复用、需要独立测试某个算法
 ✓ 团队习惯显式类型

用函数（Func / delegate / 字典）：
 ✓ 算法简单、无状态、就几行
 ✓ 想轻量，不想为一小段逻辑建一堆类
 ✓ 动态组合（字典派发、运行时拼装）

 经验：简单用函数，复杂用类。
 别为了"显得正规"给三行 lambda 套个接口。
 （第一条讲的 YAGNI）

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


该用策略模式：
 ✓ 一组同类算法，按条件选一个（折扣/支付/排序/校验…）
 ✓ 算法会随业务不断新增
 ✓ 想把选择逻辑和算法实现分开

别用：
 ✗ 只有一两种情况，if/switch 清清楚楚 → 别过度设计
 ✗ 分支不是"选算法"，而是"按数据走不同流程" → 那是状态/责任链的活
 ✗ 算法之间共享大量状态、关系紧密 → 硬拆成策略反而更乱

 信号：当 switch 分支多到让你皱眉、新增分支让你害怕，
 就是策略模式该上场的时候。

八、小结

问题：一坨 switch 把"选算法"和"算法本身"搅一起，违反开闭
策略模式：算法各自封装、可替换，客户端只依赖抽象
经典实现：IStrategy 接口 + 多实现 + Context 委托
现代 C#：简单策略用 Func/delegate/字典派发，不必建类层次
.NET 里随处可见：LINQ 的 OrderBy/Where、配置源、比较器都是策略
选择：算法简单用函数，复杂/有状态用类
信号：switch 开始让你皱眉，就上策略

下一篇讲工厂模式——创建对象的烦恼，以及 .NET DI 容器怎么把"工厂"这件事彻底接管。

设计模式实战（一）：总览——模式的本质与 SOLID

Tue, 02 Dec 2025 10:00:00 +0800

写在前面

我写了 DDD 系列，里面反复出现"策略"“工厂"“观察者"这些词——它们都是设计模式。这篇开一个新坑：「设计模式实战（.NET 视角）」。

市面上讲 23 个 GoF 模式的文章海了去了，这个系列的差异化有三点：用 现代 C#（Func/record/模式匹配）写，而不是 1998 年的 Java 式类层次；用 ASP.NET Core / .NET 源码做案例；回链你已有的内容（SOLID 接整洁架构、责任链接中间件、观察者接领域事件…）。

第一篇不急着讲具体模式，先把地基打好：模式到底是什么，以及它们共同的底座——SOLID。

一、模式到底是什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


常见误解：模式是"必须照着写的标准答案"
真相： 模式是"已被验证的、有名字的设计经验"

 - 它首先是"词汇"：你说"这里用策略模式"，对方秒懂你在说什么
 → 沟通效率 >> 代码本身
 - 其次是"经验浓缩"：前人踩过的坑、试过的解法，给它起个名
 - 它有"适用场景"和"代价"，不是万能解

 类比：模式之于编程，像"套路"之于棋手。
 背套路不是为了死套，是为了不在低级地方浪费时间。

1
2
3
4
5
6
7


学模式的三个层次：
 1. 知道有这个名字（能听懂别人说）
 2. 会写出来（能照着实现）
 3. 知道什么时候用、什么时候不用（真正会用）← 目标

 最高境界：忘了模式名，但写出来的代码天然符合模式。
 因为好设计的归宿就那几种，殊途同归。

二、模式的代价（别滥用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


模式不是免费的：
 ✗ 引入抽象 → 代码变多、间接层变多
 ✗ 增加理解成本（读代码的人要认识这个模式）
 ✗ 用错地方 → 过度设计，比没用更糟

 铁律：模式应对的是"真实存在、反复出现的复杂度"，
 而不是"想象中、将来可能"的复杂度（YAGNI）。

 一次 if/switch 能解决的事，别上策略模式。
 等真的"第三个算法"出现、switch 开始膨胀，再重构不迟。

三、SOLID：所有模式的底座

23 个 GoF 模式，骨子里都在贯彻五条原则——SOLID。理解了 SOLID，模式就是它的具体应用。

1
2
3
4
5


S — Single Responsibility Principle 单一职责
O — Open/Closed Principle 开闭原则
L — Liskov Substitution Principle 里氏替换
I — Interface Segregation Principle 接口隔离
D — Dependency Inversion Principle 依赖倒置

3.1 单一职责（SRP）

1
2
3
4
5
6
7
8


一个类/函数，只有一个变化的理由。

 反例：一个 OrderService 又算价格、又发邮件、又写日志、又管权限
 → 任何一个需求变化（改邮件模板、改权限规则）都要动这个类
 → 改一处怕牵连，测试爆炸

 正解：拆。算价归 PricingService，发邮件归 Notifier，各管一摊。
 "变化的理由" = "谁会来要求改它"。

3.2 开闭原则（OCP）

1
2
3
4
5
6
7
8
9


对扩展开放，对修改关闭。
→ 加新功能时，加新代码，不改老代码。

 反例：折扣逻辑写在一串 if/switch 里
 新增"满减"活动要往 switch 里塞分支 → 改老代码（有回归风险）

 正解：抽象出 IDiscount，每种折扣一个实现
 新增满减 = 加一个类，老代码一行不动
 （这就是策略模式，下一篇讲）

3.3 里氏替换（LSP）

1
2
3
4
5
6
7
8
9


子类必须能无感替换父类，不破坏程序正确性。

 经典反例：正方形继承长方形
 Rectangle.SetWidth(5).SetHeight(3).Area() == 15
 Square 重写 SetWidth 同时改高 → Area != 15 → 行为变了

 规矩：子类可以"更强"，但不能"违约"。
 覆写方法不能抛父类没声明的异常、不能改预期能接受的入参范围。
 "is-a" 关系一旦在行为上不成立，继承就是错的。

3.4 接口隔离（ISP）

1
2
3
4
5
6
7
8


不要强迫调用方依赖它用不到的方法。
→ 接口要小而专，不要胖接口。

 反例：一个 IBird 既有 Fly() 又有 Walk()
 企鹅实现 IBird 就得写个抛异常的 Fly() → 别扭

 正解：拆成 IBird(Walk)、IFlyingBird(Fly)，各取所需
 → 客户端只依赖它真正用的接口

3.5 依赖倒置（DIP）—— 最重要的一条

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


高层模块不该依赖低层模块，二者都该依赖抽象。
抽象不依赖细节，细节依赖抽象。
→ "依赖方向永远指向抽象"

 反例：OrderController 直接 new SqlOrderRepository()
 → Controller 依赖了具体的 SQL 实现
 → 换 Mongo、换内存测试，都要改 Controller

 正解：OrderController 依赖 IOrderRepository（抽象）
 具体的 SqlOrderRepository 实现 IOrderRepository
 由 DI 容器注入

 这就是 DDD 第六篇「整洁架构」的核心——
 领域层定义接口（抽象），基础设施层实现，依赖方向向内。
 SOLID 的 D，几乎是现代框架（ASP.NET Core DI）的立身之本。

四、SOLID 一张图串起来

1
2
3
4
5
6
7
8
9


SRP：一个类一个变化理由 → 控制"改起来怕牵连"
OCP：加功能不改老代码 → 控制"扩展的代价"
LSP：子类不违约 → 控制"继承的安全性"
ISP：接口要小 → 控制"依赖的纯洁度"
DIP：依赖抽象不依赖细节 → 控制"解耦程度"

 五条本质就一句话：
 把"变化"圈起来、关进笼子，让它只影响该影响的地方。
 23 个 GoF 模式，全是这条原则的具体套路。

五、23 个模式分类速览

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


创建型（Creational）—— 怎么造对象
 单例、工厂方法、抽象工厂、建造者、原型

结构型（Structural）—— 怎么组合对象
 适配器、装饰器、代理、外观、组合、桥接、享元

行为型（Behavioral）—— 对象怎么协作
 策略、责任链、观察者、命令、状态、模板方法、
 迭代器、中介者、备忘录、访问者

 本系列挑后端最常用的讲（不追求 23 个全覆盖）：
 策略 / 工厂 / 建造者 / 装饰器 / 责任链 / 观察者 / 单例 / 命令 / 状态

六、.NET 里模式的"现代形态”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


很多模式在 .NET 里已经"融化"进语言/框架，不用手写类层次了：

 策略 → Func<T> / delegate / 字典派发（下一篇详讲）
 工厂 → DI 容器（IServiceProvider）天然就是
 观察者 → event / 委托 / IObservable<T> 内置
 迭代器 → foreach + IEnumerable<T>，语言级支持
 单例 → DI 的 Singleton 生命周期，一行注册
 建造者 → 链式 API（EF Core ModelBuilder 等）随处可见

 启示：学模式时，要分清"模式的意图"和"模式的经典实现"。
 意图不变（解耦算法、封装创建、订阅变化…），
 实现可以很现代、很简洁。
 死记 UML 类图没用，懂了意图，C# 三行就能写出来。

七、小结

模式 = 有名字的设计经验，首先是沟通词汇，不是必须照抄的答案
别滥用：模式应对真实反复的复杂度，不是想象中的（YAGNI）
SOLID 是底座：SRP/OCP/LSP/ISP/DIP——本质都是"把变化关进笼子”
DIP 最重要：依赖抽象不依赖细节，是整洁架构和 DI 的根基
23 个模式分创建/结构/行为三类；本系列挑后端最常用的 9 个（+SOLID）
.NET 里模式常已融化进语言：学意图，别死记 UML

下一篇从最常用的策略模式开始——看它怎么把一坨 if/switch 变成干净的算法族。