.NET Core设计模式实战：观察者、装饰器与中介者模式在复杂业务系统中的应用

设计模式是软件开发中对常见问题的可重用解决方案模板。它们帮助开发者编写更灵活、可维护且可扩展的代码。本文将以 .NET Core 为例，深度解析观察者模式 (Observer)、装饰器模式 (Decorator)和中介者模式 (Mediator)，并通过一个综合的订单处理系统实战，展示如何将它们组合应用以应对复杂业务场景。

第1章：设计模式概述与 .NET Core 环境搭建

1.1 什么是设计模式？

设计模式的概念最早由“四人组”（Gang of Four, GoF）在其著作中系统化提出，定义了23种经典模式，分为三大类：

1. 创建型模式：处理对象创建机制，如单例、工厂等。
2. 结构型模式：处理类或对象的组合，如适配器、装饰器等。
3. 行为型模式：处理对象间的职责分配和通信，如观察者、中介者等。

本文将重点探讨后两者中的观察者、装饰器和中介者模式。

1.2 为什么在 .NET Core 中使用设计模式？

.NET Core（现为 .NET 5+）是一个跨平台、高性能的开源框架。应用设计模式能带来显著优势：解耦以提升可测试性，增强可扩展性以遵循开闭原则，提高代码复用性，并且与 .NET 框架本身大量使用设计模式（如事件机制、依赖注入）的生态高度契合。

1.3 开发环境准备

确保已安装最新版 .NET SDK，并选择熟悉的 IDE（如 Visual Studio, VS Code 或 Rider）。通过以下命令创建项目结构：

mkdir DesignPatterns.Core
cd DesignPatterns.Core
dotnet new sln -n DesignPatterns.Core
dotnet new classlib -n DesignPatterns.Core.Patterns
dotnet new console -n DesignPatterns.Core.Demo
dotnet sln add DesignPatterns.Core.Patterns
dotnet sln add DesignPatterns.Core.Demo
dotnet add DesignPatterns.Core.Demo reference DesignPatterns.Core.Patterns

第2章：观察者模式 (Observer Pattern) 深度解析

观察者模式定义了对象间的一对多依赖关系，当一个对象（主题）状态改变时，所有依赖它的对象（观察者）都会自动收到通知。其核心思想是发布-订阅机制。

2.1 .NET Core 中的原生支持：事件与委托

在 .NET 中，观察者模式最直接的体现是事件和委托。event关键字基于委托，提供了安全的“发布-订阅”功能。

2.2 经典实现：自定义观察者模式

为了更好地理解模式本质，我们先手动实现一个经典示例：天气站与多个显示设备。

1. 定义接口 (ISubject, IObserver)
2. 实现具体主题 (WeatherStation) 和观察者 (PhoneDisplay, TVDisplay)
3. 演示代码：主题状态更新，自动通知所有注册的观察者。

2.3 .NET 风格实现：使用事件与委托

更符合 .NET 习惯的实现是直接使用 event 和 EventHandler<T>，代码更简洁、安全。

第3章：装饰器模式 (Decorator Pattern) 深度解析

装饰器模式允许动态地将行为添加到对象中，而无需改变其类。它通过组合而非继承来扩展功能，遵循开闭原则。

3.1 经典实现：咖啡店订单系统

通过“咖啡店”例子理解该模式：基础咖啡（组件）可以被牛奶、糖等调料（装饰器）动态装饰，每种装饰都增加价格和描述。

1. 定义组件接口 (IBeverage)
2. 实现具体组件 (Coffee) 和装饰器基类 (BeverageDecorator)
3. 实现具体装饰器 (MilkDecorator, SugarDecorator等)
4. 演示代码：动态组合出一杯带有多种调料的咖啡。

3.2 .NET Core 实战：使用装饰器模式增强服务

在实际项目中，装饰器模式常用于为服务添加缓存、日志等横切关注点。

1. 定义服务接口 (ICustomerService)
2. 实现基础服务 (CustomerService) 和缓存装饰器 (CachingCustomerService)
3. 演示代码：装饰器包装基础服务，首次调用查询数据库并缓存，后续调用直接返回缓存结果，这类似于为服务层引入 Redis 等缓存中间件的思想。

第4章：中介者模式 (Mediator Pattern) 深度解析

中介者模式通过一个中介者对象来封装一系列对象间的复杂交互，从而使其耦合松散，交互逻辑可以独立变化。

4.1 经典实现：聊天室系统

在聊天室中，用户不能直接通信，必须通过聊天室（中介者）转发消息，从而解耦了用户对象。

1. 定义中介者接口 (IChatMediator) 和同事类 (ChatUser)
2. 实现具体中介者 (ChatRoom)
3. 演示代码：用户发送消息至聊天室，由聊天室广播给其他所有用户。

4.2 .NET Core 实战：使用中介者模式协调服务

在复杂应用（如微服务）中，可使用中介者协调订单、支付、物流等多个服务。

1. 定义服务接口与实现
2. 实现中介者 (SimpleMediator) 并注册事件处理器
3. 配置协调逻辑：定义“订单处理完成 -> 发起支付 -> 支付成功 -> 安排发货 -> 发送通知”的工作流。
4. 演示代码：订单服务触发事件，中介者按预定义流程协调后续所有服务调用，完美体现了在 云原生 架构中解耦服务间调用的思想。

第5章：综合项目实战——基于设计模式的订单处理系统

我们将构建一个综合系统，融合三种模式：

• 中介者模式 (OrderProcessingMediator)：协调订单创建、支付、发货的主流程。
• 观察者模式 (ObservableOrderService 事件)：当订单状态变更时，自动触发邮件和短信通知。
• 装饰器模式 (LoggingPaymentService, RetryPaymentService)：为支付服务动态添加日志记录和失败重试功能。

核心组装与演示：

// 1. 创建基础服务
var paymentService = new PaymentService();
// 2. 使用装饰器增强支付服务（日志+重试）
IPaymentService decoratedPaymentService = new LoggingPaymentService(paymentService);
decoratedPaymentService = new RetryPaymentService(decoratedPaymentService, maxRetries: 2);
// 3. 创建可观察的订单服务
var orderService = new ObservableOrderService(inventoryService, decoratedPaymentService);
// 4. 创建中介者并协调流程
var mediator = new OrderProcessingMediator(orderService, inventoryService);
// 5. 订阅通知
var emailObserver = new EmailNotificationObserver();
emailObserver.Subscribe(orderService);
// 6. 处理订单
await mediator.ProcessOrderAsync(order);

该系统展示了如何通过设计模式的组合，构建出高内聚、低耦合、易扩展的 .NET Core 应用程序。

第6章：总结与最佳实践

• 观察者模式：适用于事件驱动场景，在.NET中优先使用 event/EventHandler<T>。
• 装饰器模式：适合动态添加功能，可与.NET Core依赖注入容器良好集成。
• 中介者模式：用于解耦复杂交互，避免“上帝对象”，可考虑使用 MediatR 等成熟库。
  模式组合的威力在于它们各司其职：中介者协调主干流程，观察者处理异步通知，装饰器增强单一组件功能。在实践中应避免过度设计，根据实际复杂性和维护需求合理引入模式。