中介者模式：如何通过中间层来解决耦合过多的问题？

中介者模式理解起来并不难，代码实现简单，学习难度也很小，只要合理充分地应用这个模式，往往就能够解决一些意想不到的问题。那这到底是怎样一个模式？多用于什么场景中？为什么使用？该怎么使用？下面我们一起来看看吧。

一、模式原理分析

中介者模式的原始定义是：中介者对象封装了一组对象之间的交互，这组对象会将它们的交互委托给中介者对象，而不是直接交互。

可以看到，这个定义是难得的简单和明确，中介者对象就是用于处理对象与对象之间的直接交互，封装了多个对象之间的交互细节。

我们还是先来看看中介者模式的 UML 图：

从这个 UML 图中，我们能看出中介者模式包含了四个关键角色。

• 抽象中介者（Mediator）：定义中介者需要执行的方法操作。

• 具体中介者（MediatorImpl）：实现抽象中介者定义的方法操作，同时可以包含更多逻辑。

• 抽象组件类（Component）：定义组件需要执行的方法操作。

• 具体组件类（ComponentA、ComponentB）：继承自抽象组件类，实现具体的组件业务逻辑。

下面我们再来看看 UML 对应的代码实现：

public interface Mediator {
    void apply(String key);
}
public class MediatorImpl implements Mediator{
    @Override
    public void apply(String key) {
        System.out.println("最终中介者执行操作，key为："+key);
    }
}
public abstract class Component {
    private Mediator mediator;
    public Component(Mediator mediator) {
        this.mediator = mediator;
    }
    public abstract void exec(String key);
    public Mediator getMediator() {
        return mediator;
    }
}
public class ComponentA extends Component{
    public ComponentA(Mediator mediator) {
        super(mediator);
    }
    @Override
    public void exec(String key) {
        System.out.println("===在组件A中，通过中介者执行");
        getMediator().apply(key);
    }
}
public class ComponentB extends Component{
    public ComponentB(Mediator mediator) {
        super(mediator);
    }
    @Override
    public void exec(String key) {
        System.out.println("===在组件B中，通过中介者的操作");
        getMediator().apply(key);
    }
}
public class Demo {
    public static void main(String[] args) {
        Mediator mediator = new MediatorImpl();
        Component componentA = new ComponentA(mediator);
        componentA.exec("key-A");
        Component componentB = new ComponentB(mediator);
        componentB.exec("key-B");
    }
}
//输出结果
===在组件A中，通过中介者执行
最终中介者执行操作，key为：key-A
===在组件B中，通过中介者的操作
最终中介者执行操作，key为：key-B

从上面的代码实现中，可以发现中介者模式的关键点就在于在组件与组件之间加入一个中间对象来进行间接通信。虽然多了“一层”会更烦琐些，但是这样就可以在中介者里进行其他的一些操作。

二、使用场景分析

中介者模式常见的使用场景有以下几种：

• 系统中对象之间存在复杂的引用关系时，比如，聊天系统；

• 通过一个中间对象来封装多个类中的共有行为时，比如，在分层架构中的 DAO 层和数据库 DB 层中间再引入一个读写分离和读写均衡的中间层；

• 不想生成太多的子类时。

为了快速理解中介者的适用场景，下面我们还是通过一个简单的例子来讲解和演示。

假设我们要设计一个可以让多人参与进去的聊天室，该怎么去实现呢？首先，定义聊天室的接口 ChatRoom，其中包含两个方法 sendMessage 和 addUser，分别代表发送消息和新增用户。这里的 ChatRoom 就是抽象的中介者类。

public interface ChatRoom {
    void sendMessage(String msg, String userId);
    void addUser(User user);
}

然后，创建一个 ChatRoom 的实现类ChatRoomImpl，使用 addUser 来添加需要聊天的用户对象，同时这里再使用一个Map来保存添加时需要用来进行通信的对象列表，在发送消息 sendMessage 的方法中，我们通过 userId 指定某个对象来接收消息。

public class ChatRoomImpl implements ChatRoom {
    private Map<String, User> usersMap = new HashMap<>();
    @Override
    public void sendMessage(String msg, String userId) {
        User u = usersMap.get(userId);
        u.receive(msg);
    }
    @Override
    public void addUser(User user) {
        this.usersMap.put(user.getId(), user);
    }
}

接下来我们再定义一个抽象组件类 User，如下所示：

public abstract class User {
    private ChatRoom mediator;
    private String id;
    private String name;
    public User(ChatRoom room, String id, String name){
        this.mediator = room;
        this.name = name;
        this.id = id;
    }
    public abstract void send(String msg, String userId);
    public abstract void receive(String msg);
    public ChatRoom getMediator() {
        return mediator;
    }
    public String getId() {
        return id;
    }
    public String getName() {
        return name;
    }
}

继承User实现一个具体的组件类 ChatUser，并实现发送消息 send 和接收消息 receive 的方法。

public class ChatUser extends User {
    public ChatUser(ChatRoom room, String id, String name) {
        super(room, id, name);
    }
    @Override
    public void send(String msg, String userId) {
        System.out.println(this.getName() + " :: Sending Message : " + msg);
        getMediator().sendMessage(msg, userId);
    }
    @Override
    public void receive(String msg) {
        System.out.println(this.getName() + " :: Received Message : " + msg);
    }

}

最后，我们同样还是运行一段单元测试代码：

public class Client {
    public static void main(String[] args) {
        ChatRoom chatroom = new ChatRoomImpl();
        User user1 = new ChatUser(chatroom,"1", "Spike");
        User user2 = new ChatUser(chatroom,"2", "Mia");
        User user3 = new ChatUser(chatroom,"3", "Max");
        User user4 = new ChatUser(chatroom,"4", "Mick");
        chatroom.addUser(user1);
        chatroom.addUser(user2);
        chatroom.addUser(user3);
        chatroom.addUser(user4);
        user1.send("Hello man", "2");
        user2.send("Hey", "1");
    }
}
//输出结果
Spike :: Sending Message : Hello man
Mia :: Received Message : Hello man
Mia :: Sending Message : Hey
Spike :: Received Message : Hey

到此，我们就完成了一个简单的聊天室程序。从代码实现中能看出，中介者在使用时需要知道对象之间的交互关系，然后通过封装这些交互关系的变化让对象在使用中介者时变得更简单。

三、为什么使用中介者模式？

分析完中介者模式的原理和使用场景后，我们再来说说使用中介者模式的原因，可总结为以下三个。

第一个，解决对象之间直接耦合的问题，避免“一处修改多处”的连锁反应出现。比如，在上面聊天室的例子中，如果用户与用户之间是直连通信的，那么任何一个用户对象发生变化都会影响到直接聊天的那个用户，而那个用户可能又在跟别的用户聊天，以此类推，用户之间的关系会变得越来越复杂。这样，当我们再修改代码时，就很容易造成“一处修改又引起多处修改”的连锁反应。而使用中介者模式时，用户会通过聊天室和别的用户通信，避免了直接与对方通信，这样修改某个用户对象时并不会影响到其他对象。

第二个，在结构上作为中转，解耦两个服务或系统之间的直接耦合关系。在分层架构中，我们都知道视图层一般不会直接使用 DAO 层，因为一旦直接使用，DAO 层任何一个微小的变动都可能引起视图层的变化，这时通常会引入 Service 层作为中介者来进行请求的转发，以达到解耦的目的，避免了相互之间的直接影响，同时也能在中间层里加入一些特定的逻辑，如性能监控、埋点数据记录等。

第三个，为了更便捷地统一协同对象之间的通信。我们知道在对远程服务器进行调用时，协调网络通信是一件异常复杂和烦琐的事情，这时如果有一个中介者来统一协调，则会大大提升效率，比如，Dubbo 一类的 RPC 框架就是一个完整的中介者模式的体现。对于所有的 Java RPC 调用来说，只需要通过这个中间层来进行通信即可，而不需要知道对方服务器地址以及如何发起网络调用。

四、中介者模式的优缺点是什么？

通过以上分析，我们可以得出中介者模式主要有这样几个优点。

• 减少对象之间的直接交互，间接解耦过多依赖。比如，Maven 就是 Java 中引用 jar 包时的中介者，如果我们手动直接引用 jar 包，会容易造成非常混乱的引用关系，而使用 Maven 则能很方便地减少代码直接依赖 jar 包的问题。

• 减少子类的创建数量。比如，在多个用户的会话请求中，我们可以使用一个通用的上下文的中介者来保存会话中一些不变的静态数据，这样就不需要每新增一个会话都需要新增一些静态数据。

• 简化各系统的设计和实现。由于中介者能够处理一些共用的通信逻辑，所以其他对象在进行自身业务的处理时可以不用关心共用的通信逻辑，这样就大大减少了系统的实现逻辑。

• 通过新建中间层快速扩展新功能，提升代码扩展性。比如，对象通过中间层调用时，我们可以在中间层加入对每一次请求或方法调用的耗时统计，这样就能快速扩展功能。

同样，中介者模式也有一些缺点。

• 中介者类中的交互逻辑可能变得非常复杂且难以维护。当中介者类中包含了太多对象之间的交互细节后，中介者就变成了新的复杂对象，使得系统维护成本变高。

• 中介者变成了新的重度依赖对象。一旦中介者对象变得复杂后，势必会增加与其他对象之间的耦合度，而这时如果中介者对象发生故障，则依赖的相关对象也会受到影响，修改中介者也会影响关联对象。

• 中介者需要知道所有对象交互的逻辑。由于中介者对象承担了交互对象的传输渠道，所以就需要知道对象交互的详细细节，这样无疑增加了中介者对象的学习成本。

总结来讲，中介者模式提供了一种减少对象之间耦合度的思路。对于一些维护性的旧项目来说，直接修改已有代码通常都会导致系统出现问题，而通过引入中间层，能够起到过渡的作用，同时还能够逐渐解耦原有的强耦合关系，让系统的扩展性变得更强。不过，中介者也可能因此变得异常复杂，一旦中介者出现问题，就会导致所有系统都出现问题，所以在使用时也需要注意设计的度。

文章（专栏）将持续更新，欢迎关注公众号：服务端技术精选。欢迎点赞、关注、转发。