中介者模式：解耦复杂对象交互的设计模式实践-代码聚汇网

中介者模式：解耦复杂对象交互的设计模式实践

不吃章鱼烧

1. 中介者模式：解决复杂交互的利器

在软件开发中，我们经常会遇到多个对象之间需要相互通信的场景。当这些交互关系变得复杂时，代码就会像一团乱麻，难以维护和扩展。中介者模式正是为了解决这个问题而生的。

想象一下机场的塔台控制系统。如果没有塔台，每架飞机都需要直接与其他所有飞机通信，协调飞行路线和高度，这将导致混乱和危险。塔台作为中介者，集中管理所有通信，让飞行员只需与塔台对话，大大简化了交互过程。

中介者模式的核心思想就是引入一个中介对象，封装一组对象之间的交互。这样对象之间不再直接引用，而是通过中介者进行通信，从而降低耦合度。

2. 问题场景：模块间的蜘蛛网式调用

2.1 直接调用的痛点

让我们看一个典型的场景：三个模块（Module1、Module2、Module3）需要相互调用。在不使用设计模式的情况下，代码会是这样：

java复制public class Module1 {
    public void execute() {
        Module2 module2 = new Module2();
        Module3 module3 = new Module3();
        module2.execute("模块1");
        module3.execute("模块1");
    }
    
    public void execute(String invoker) {
        System.out.println(invoker + "在调用模块1功能");
    }
}

// Module2和Module3也有类似的实现

这种实现方式存在几个严重问题：

高耦合：每个模块都需要知道其他所有模块的存在和接口
难以维护：修改一个模块可能影响其他所有模块
扩展困难：添加新模块需要修改所有现有模块

2.2 电商系统的现实案例

在电商系统中，订单、库存和配送中心之间需要频繁交互：

创建订单需要检查库存
库存变化需要通知配送中心
配送状态更新需要反馈给订单系统

如果不使用中介者模式，这些组件之间会形成复杂的网状依赖关系，任何修改都可能引发连锁反应。

3. 中介者模式的实现

3.1 类结构与角色

中介者模式包含以下几个关键角色：

Mediator（中介者接口）：定义各个同事对象通信的接口
ConcreteMediator（具体中介者）：实现中介者接口，协调各同事对象
Colleague（同事类）：各个需要交互的对象，它们只知道中介者

3.2 代码实现

让我们重构前面的例子，引入中介者：

java复制// 中介者类
public class Mediator {
    private Module1 module1;
    private Module2 module2;
    private Module3 module3;
    
    public void module1Invoke() {
        module2.execute("模块1通过中介者");
        module3.execute("模块1通过中介者");
    }
    
    // 其他模块的调用方法...
    
    // setter方法...
}

// 模块实现
public class Module1 {
    private Mediator mediator;
    
    public Module1(Mediator mediator) {
        this.mediator = mediator;
        mediator.setModule1(this);
    }
    
    public void execute() {
        mediator.module1Invoke();
    }
    
    public void execute(String invoker) {
        System.out.println(invoker + "调用模块1功能");
    }
}

3.3 调用流程

创建中介者实例
创建各个模块，并注册到中介者
模块通过调用中介者的方法间接与其他模块通信

4. 中介者模式的优势与适用场景

4.1 核心优势

降低耦合度：模块之间不再直接依赖
集中控制：交互逻辑集中在中介者中，便于维护
简化对象设计：各对象只需关注自身功能
提高灵活性：可以独立修改交互逻辑而不影响各模块

4.2 典型应用场景

GUI开发：各种控件之间的交互
聊天应用：用户之间的消息传递
航空管制系统：飞机与地面控制中心的通信
电商系统：订单、库存、物流的协调

4.3 性能考量

虽然中介者模式带来了结构上的优势，但也需要考虑：

中介者可能成为性能瓶颈
过度使用会导致中介者过于复杂
需要权衡解耦带来的好处与额外抽象层的成本

5. 实战建议与注意事项

5.1 实现技巧

合理划分职责：中介者应该只负责协调，不包含业务逻辑
接口设计：定义清晰的通信接口，避免过度耦合
模块注册：使用依赖注入等方式管理模块注册
异常处理：在中介者中统一处理通信异常

5.2 常见陷阱

上帝对象：中介者变得过于庞大，承担太多职责
过度设计：简单交互不需要中介者模式
循环依赖：中介者和模块之间要避免循环引用
性能问题：高频交互场景可能需要优化中介者实现

5.3 与其他模式的关系

与观察者模式：常结合使用，模块通过事件通知中介者
与门面模式：都提供统一接口，但目的不同
与命令模式：可以将请求封装为命令对象传递

6. 电商系统案例详解

让我们深入分析电商系统中中介者模式的应用。

6.1 系统组件

订单服务：处理订单创建、查询
库存服务：管理商品库存
配送服务：安排商品配送
支付服务：处理支付流程

6.2 中介者设计

java复制public class OrderMediator {
    private OrderService orderService;
    private InventoryService inventoryService;
    private DeliveryService deliveryService;
    private PaymentService paymentService;
    
    public void placeOrder(Order order) {
        // 检查库存
        if (!inventoryService.checkStock(order)) {
            throw new RuntimeException("库存不足");
        }
        
        // 扣减库存
        inventoryService.reduceStock(order);
        
        // 创建支付
        paymentService.createPayment(order);
        
        // 安排配送
        deliveryService.scheduleDelivery(order);
        
        // 更新订单状态
        orderService.confirmOrder(order);
    }
    
    // 其他协调方法...
}

6.3 交互流程

前端调用中介者的placeOrder方法
中介者按顺序协调各服务完成订单流程
任何步骤失败都会触发回滚操作
最终返回订单处理结果

7. 性能优化与高级用法

7.1 异步处理

对于耗时操作，可以使用异步中介者：

java复制public CompletableFuture<Void> asyncPlaceOrder(Order order) {
    return CompletableFuture.runAsync(() -> {
        inventoryService.checkStock(order);
        // 其他操作...
    });
}

7.2 事件驱动架构

结合事件总线实现更松散的耦合：

java复制public class EventMediator {
    private EventBus eventBus;
    
    public void registerHandlers() {
        eventBus.register(new OrderEventHandler());
        eventBus.register(new InventoryEventHandler());
        // 其他处理器...
    }
}

7.3 分布式中介者

在微服务架构中，可以使用消息队列作为中介者：

java复制public class MessageQueueMediator {
    private MessageProducer producer;
    private MessageConsumer consumer;
    
    public void sendOrderEvent(OrderEvent event) {
        producer.send("order-topic", event);
    }
    
    // 其他消息处理方法...
}

8. 测试策略

8.1 单元测试重点

测试各模块与中介者的交互
验证中介者的协调逻辑
检查异常处理流程

8.2 集成测试要点

验证完整业务流程
测试系统在部分服务不可用时的行为
性能测试中介者的吞吐量

8.3 测试替身使用

可以使用Mock对象隔离测试各组件：

java复制@Test
public void testOrderProcessing() {
    // 创建mock对象
    InventoryService mockInventory = mock(InventoryService.class);
    when(mockInventory.checkStock(any())).thenReturn(true);
    
    // 创建中介者并注入mock
    OrderMediator mediator = new OrderMediator();
    mediator.setInventoryService(mockInventory);
    
    // 测试订单处理
    mediator.placeOrder(testOrder);
    
    // 验证交互
    verify(mockInventory).checkStock(testOrder);
}

9. 重构现有系统

9.1 识别重构时机

模块间调用关系复杂难以理解
修改一个模块影响多个其他模块
添加新功能需要修改大量现有代码

9.2 重构步骤

创建中介者接口
将直接调用改为通过中介者
逐步迁移功能，保持系统可用
最终移除模块间的直接依赖

9.3 重构示例

将直接调用：

java复制// 旧代码
public class OrderService {
    public void createOrder(Order order) {
        // 直接调用库存服务
        inventoryService.checkStock(order);
        // ...
    }
}

重构为通过中介者：

java复制// 新代码
public class OrderService {
    private OrderMediator mediator;
    
    public void createOrder(Order order) {
        mediator.placeOrder(order);
    }
}

10. 设计思考与权衡

10.1 何时不使用中介者模式

对象间交互简单直接
性能是关键考量
系统规模较小

10.2 架构决策因素

系统复杂度
变更频率
团队规模
性能要求
长期维护成本

10.3 扩展性设计

使用接口而非具体类
支持动态注册组件
考虑插件式架构

在实际项目中，我经常发现开发者在初期低估了系统复杂度，导致后期不得不进行大规模重构。中介者模式虽然引入了一定复杂性，但对于中等以上复杂度的系统，这种前期投入通常会带来长期的维护收益。关键在于把握好度，既不要过度设计，也不要等到系统变成"大泥球"才考虑重构。