白话设计模式之（3）中介者模式：对象交互的“智能中枢”

大家好！在技术学习的漫漫长路上，我始终相信分享能让我们共同进步，收获更多知识。今天，咱们深入探讨设计模式中的中介者模式，它就像是代码世界里对象交互的“智能中枢”，能让复杂混乱的对象关系变得有序清晰。希望通过这篇博客，大家都能轻松掌握这个实用的设计模式。

一、中介者模式的引入

（一）实际场景中的对象交互难题

在软件开发过程中，我们经常会遇到多个对象之间复杂的交互场景。就像文档里提到的电脑系统，如果没有主板这个“协调者”，CPU、内存、显卡、硬盘等各个配件之间就需要直接相互交互来传输数据。但由于每个配件的接口和功能都不一样，这种直接交互会变得异常复杂，不仅要处理各种数据格式的转换，而且一旦某个配件的接口或功能发生变化，其他所有与之交互的配件都得跟着调整，这无疑大大增加了系统的复杂性和维护成本。这就好比在一场大型演出中，演员、灯光师、音响师、舞台工作人员等众多人员如果没有导演统一协调，每个人都直接和其他所有人沟通工作，那整个演出过程将会混乱不堪，任何一个人的变动都可能导致整个演出出现问题。

（二）传统交互方式的弊端

传统的对象直接交互方式会导致对象之间的耦合度极高。在软件系统中，这意味着一个类的变动可能会引发一系列相关类的连锁反应。例如，在一个电商系统里，订单模块、库存模块、支付模块和物流模块之间存在紧密的交互关系。要是订单模块的某个功能发生改变，比如订单状态的更新逻辑变化，那么库存模块、支付模块和物流模块都可能需要相应地修改代码来适应这种变化。这种高度耦合的设计使得系统的维护和扩展变得异常困难，开发成本大幅增加，而且很容易引入新的错误。

二、中介者模式的概念

（一）中介者模式的定义

中介者模式的定义是用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。简单来说，就像在一个社区里，居民们（各个对象）之间原本各自沟通，关系复杂且混乱。现在有了社区服务中心（中介者），居民们只需要和社区服务中心联系，社区服务中心负责协调居民之间的各种事务，比如组织活动、解决纠纷等。这样一来，居民之间的直接联系减少了，关系变得更加有序。在代码世界里，中介者就像这个社区服务中心，它负责管理和协调其他对象之间的交互，让对象之间的关系变得松散，便于维护和扩展。

（二）中介者模式的结构

中介者模式主要包含四个角色：

1. Mediator（中介者）：这是一个接口，定义了各个同事之间交互需要的方法。它类似于社区服务中心的服务章程，规定了在协调居民事务时应该具备的各种方法。在电脑配件交互的场景中，中介者接口可以定义像“传递数据”“协调配件工作”等方法。
2. ConcreteMediator（具体中介者）：实现了中介者接口的具体对象，它了解并维护各个同事对象，负责具体协调同事对象的交互关系。就像真正的社区服务中心，熟悉每一位居民的情况，并且能够根据实际情况协调居民之间的关系。在电脑配件的例子中，具体中介者就好比主板，它清楚每个配件的接口和功能，能够协调CPU、内存、显卡等配件之间的数据传输和工作协同。
3. Colleague（同事类）：通常是一个抽象类，负责约束同事对象的类型，并实现一些具体同事类之间的公共功能。比如每个具体同事类都应该知道中介者对象，也就是具体同事类都会持有中介者对象。这就好比社区居民都知道社区服务中心的存在，并且有一些和社区服务中心沟通的基本方式是共有的。在代码中，同事类定义了一些通用的行为和属性，为具体同事类提供了一个基础框架。
4. ConcreteColleague（具体同事类）：实现自己的业务，在需要与其他同事通信的时候，就与持有的中介者通信，中介者会负责与其他的同事交互。就像每个居民专注于自己的生活，当需要和其他居民协作时，就通过社区服务中心来协调。在电脑配件场景中，CPU、内存、显卡等就是具体同事类，它们各自有自己的功能，当需要与其他配件交互时，就通过主板（中介者）来进行。

三、中介者模式的代码示例

为了让大家更直观地理解，我们以一个简单的在线游戏组队系统为例。在这个系统中，有多个玩家（具体同事类）需要组队进行游戏，而组队管理系统（中介者）负责协调玩家之间的组队请求。

首先定义中介者接口：

// 组队中介者接口
public interface TeamMediator {
    void addPlayer(Player player);
    void matchPlayers(Player player);
}

接着创建具体中介者类：

// 组队管理系统，具体中介者
import java.util.ArrayList;
import java.util.List;

public class TeamSystem implements TeamMediator {
    private List<Player> players = new ArrayList<>();

    @Override
    public void addPlayer(Player player) {
        players.add(player);
        System.out.println(player.getName() + " 加入了组队系统。");
    }

    @Override
    public void matchPlayers(Player player) {
        for (Player p : players) {
            if (p != player && p.getLevel() >= player.getLevel() - 5 && p.getLevel() <= player.getLevel() + 5) {
                System.out.println(player.getName() + " 与 " + p.getName() + " 成功组队！");
                return;
            }
        }
        System.out.println(player.getName() + " 暂时没有匹配到合适的队友。");
    }
}

然后定义同事类的抽象类：

// 玩家抽象类，同事类
public abstract class Player {
    protected TeamMediator mediator;
    protected String name;
    protected int level;

    public Player(TeamMediator mediator, String name, int level) {
        this.mediator = mediator;
        this.name = name;
        this.level = level;
    }

    public abstract void requestMatch();
}

最后创建具体同事类：

// 具体玩家类，具体同事类
public class ConcretePlayer extends Player {
    public ConcretePlayer(TeamMediator mediator, String name, int level) {
        super(mediator, name, level);
    }

    @Override
    public void requestMatch() {
        System.out.println(name + " 发起组队匹配请求。");
        mediator.matchPlayers(this);
    }
}

在客户端代码中使用中介者模式：

public class GameClient {
    public static void main(String[] args) {
        TeamSystem teamSystem = new TeamSystem();

        Player player1 = new ConcretePlayer(teamSystem, "玩家A", 30);
        Player player2 = new ConcretePlayer(teamSystem, "玩家B", 32);
        Player player3 = new ConcretePlayer(teamSystem, "玩家C", 40);

        teamSystem.addPlayer(player1);
        teamSystem.addPlayer(player2);
        teamSystem.addPlayer(player3);

        player1.requestMatch();
        player3.requestMatch();
    }
}

通过这个示例可以看到，在在线游戏组队系统中，玩家之间不需要直接了解其他玩家的情况，只需要向组队管理系统（中介者）发起组队请求。组队管理系统负责协调玩家之间的匹配，判断是否有合适的队友，并给出相应的结果。这样就实现了玩家之间的解耦，使得系统更加易于维护和扩展。比如，如果要添加新的玩家，只需要创建新的具体玩家类并注册到组队管理系统中即可，不会影响到其他玩家的代码。

四、中介者模式的应用场景

（一）多对象交互复杂的场景

当系统中存在多个对象，且它们之间的交互关系错综复杂时，中介者模式非常适用。比如在一个航空订票系统中，涉及到航班信息、乘客信息、座位信息、支付系统、票务系统等多个对象之间的交互。如果这些对象直接相互交互，代码会变得极其复杂，难以维护和扩展。使用中介者模式，引入一个中介对象来管理这些交互，就可以简化系统的结构，提高系统的可维护性。

（二）降低对象耦合度的场景

如果希望降低对象之间的耦合度，使对象之间的依赖关系更加松散，中介者模式是一个很好的选择。例如在一个游戏开发中，角色、场景、道具等对象之间存在着各种交互关系。使用中介者模式，让这些对象通过中介者进行交互，可以降低它们之间的直接依赖，使得每个对象的修改和扩展不会对其他对象产生太大的影响，提高了系统的灵活性。

（三）便于集中管理和控制交互的场景

在一些需要集中管理和控制对象交互的场景中，中介者模式能够发挥很大的作用。比如在一个智能家居系统中，各种智能设备（如灯光、空调、窗帘等）之间需要进行交互和协同工作。通过引入一个中介者（如智能家居控制器），可以方便地对这些设备之间的交互进行管理和控制，实现更加智能化的家居体验。

五、中介者模式的优缺点

（一）优点

1. 降低耦合度：中介者模式通过将对象之间的交互封装到中介者对象中，使得对象之间不需要直接相互引用，降低了对象之间的耦合度。这就像在一个大型组织中，各个部门通过一个协调中心进行沟通，部门之间不需要直接联系，减少了相互之间的依赖，使得每个部门的变动对其他部门的影响最小化。
2. 提高可维护性和扩展性：由于对象之间的耦合度降低，当某个对象的功能或行为发生变化时，只需要修改中介者对象或者该对象本身，而不需要对其他大量相关对象进行修改。这使得系统的维护和扩展变得更加容易，就像在一个软件系统中，如果某个模块的功能发生变化，只需要调整中介者和该模块的代码，而不会影响到其他模块，提高了开发效率。
3. 便于集中控制和管理：中介者模式将对象之间的交互集中到一个中介者对象中，便于对交互进行统一的控制和管理。就像在一个交通枢纽中，通过交通信号灯（中介者）来管理车辆（对象）之间的通行，使得交通更加有序，便于管理和调度。

（二）缺点

1. 中介者对象可能会过于复杂：随着系统中对象数量的增加和交互关系的复杂化，中介者对象可能会变得非常复杂，包含大量的逻辑和代码。这就像一个大型企业的协调中心，如果业务过于复杂，协调中心的工作压力会很大，管理和维护起来也会变得困难。
2. 可能会出现性能问题：在一些情况下，中介者对象可能会成为系统的性能瓶颈。因为所有对象之间的交互都要通过中介者来进行，如果交互频繁，中介者可能会处理不过来，导致系统性能下降。这就好比在一个网络通信系统中，如果所有的数据包都要经过一个中心节点进行转发，当数据量过大时，这个中心节点可能会出现拥堵，影响整个系统的通信效率。

六、总结

中介者模式是一种非常实用的设计模式，它在处理多个对象之间的复杂交互方面有着独特的优势。在实际开发中，我们要根据具体的业务需求和场景，合理运用中介者模式，充分发挥它的优势，同时注意避免其带来的问题。

写作不易，如果这篇文章对你有所帮助，希望大家能关注我的博客，点赞评论支持一下！你的每一个点赞、评论和关注都是对我最大的鼓励，我会持续为大家带来更多设计模式相关的优质内容，咱们下次再见！