设计模式解密（15）- 中介者模式（调停者模式）

于 2017-07-31 16:59:00 发布
阅读量283 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 设计模式 《设计模式解密》 文章标签： 设计模式 中介者模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Json_wangqiang/article/details/85276194
本文详细介绍了中介者模式的概念、类图、应用场景以及优缺点，并通过一个微信群聊的例子展示了该模式的具体实现过程。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 

1、简介

别名：调停者模式

定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互引用。从而使其耦合松散，而且可以独立地改变它们之间的交互。

主要解决：对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。

何时使用：多个类相互耦合，形成了网状结构。

如何解决：将上述网状结构分离为星型结构。

核心思想：1、就是将网状结构处理成星型结构            

　　    　　2、将多对多处理成一对多

本质：封装对象间的交互

英文：Mediator

类型：行为型

PS：附图示解决的问题

     

2、类图及组成

（引）类图：

组成：

　　● 抽象中介者(Mediator)角色：定义统一的接口用于各同事角色之间的通信，其中主要方法是一个（或多个）事件方法。

　　● 具体中介者(ConcreteMediator)角色：实现了抽象中介者所声明的事件方法。具体中介者知晓所有的具体同事类，并负责具体的协调各同事对象的交互关系。

　　● 抽象同事类(Colleague)角色：定义出中介者到同事角色的接口。同事角色只知道中介者而不知道其余的同事角色。与其他的同事角色通信的时候，一定要通过中介者角色协作。

　　● 具体同事类(ConcreteColleague)角色：所有的具体同事类均从抽象同事类继承而来。实现自己的业务，在需要与其他同事通信的时候，就与持有的中介者通信，中介者会负责与其他的同事交互。

 

代码结构：

//抽象中介者类
public interface Mediator {
    /**
     * 同事对象在自身改变的时候来通知中介者的方法
     * 让中介者去负责相应的与其他同事对象的交互
     */
    public void changed(Colleague c);
}

//抽象同事类
public abstract class Colleague {
    //持有一个中介者对象
    private Mediator mediator;
    /**
     * 构造函数
     */
    public Colleague(Mediator mediator){
        this.mediator = mediator;
    }
    /**
     * 获取当前同事类对应的中介者对象
     */
    public Mediator getMediator() {
        return mediator;
    }
}

//具体中介者类
public class ConcreteMediator implements Mediator {
    //持有并维护同事A
    private ConcreteColleagueA colleagueA;
    //持有并维护同事B
    private ConcreteColleagueB colleagueB;    

    public void setColleagueA(ConcreteColleagueA colleagueA) {
        this.colleagueA = colleagueA;
    }

    public void setColleagueB(ConcreteColleagueB colleagueB) {
        this.colleagueB = colleagueB;
    }

    @Override
    public void changed(Colleague c) {
        /**
         * 某一个同事类发生了变化，通常需要与其他同事交互
         * 具体协调相应的同事对象来实现协作行为
         */
    }
}

//具体同事类
public class ConcreteColleagueA extends Colleague {

    public ConcreteColleagueA(Mediator mediator) {
        super(mediator);
    }
    /**
     * 示意方法，执行某些操作
     */
    public void operation(){
        //在需要跟其他同事通信的时候，通知中介者对象
        getMediator().changed(this);
    }
}
public class ConcreteColleagueB extends Colleague {

    public ConcreteColleagueB(Mediator mediator) {
        super(mediator);
    }
    /**
     * 示意方法，执行某些操作
     */
    public void operation(){
        //在需要跟其他同事通信的时候，通知中介者对象
        getMediator().changed(this);
    }
}

3、实例引入

假设现在有A、B、C建立了一个微信讨论组，他们有什么问题就在这里讨论，A在犹豫今天中午吃什么，A同学只要在讨论组里问一声就可以了，不必要直接去和B、C同学打交道，省去了很多麻烦事。怎么实现呢？

抽象中介者：

package com.designpattern.Mediator;

/**
 * 抽象中介者类
 * @author Json<<json1990@foxmail.com>>
 */
public interface Mediator {
    /**
     * 发送消息
     */
    public void chat(People p,String message);
}

抽象同事类：

package com.designpattern.Mediator;

/**
 * 抽象同事类  -- 聊天人员
 * @author Json<<json1990@foxmail.com>>
 */
public abstract class People { 
    //人员昵称
    private String name;
    //持有一个中介者对象
    private Mediator mediator;
    
    /**
     * 构造函数
     */
    public People(Mediator mediator,String name){
        this.mediator = mediator;
        this.name = name;
    }
    /**
     * 获取中介者对象
     */
    public Mediator getMediator() {
        return mediator;
    }
    /**
     * 获取昵称
     */
    public String getName() {
        return name;
    }
    
    /**
     * 接收消息
     */
    public abstract void receive(String message);
    
    /**
     * 发送消息
     */
    public abstract void send(String message);
}

3个具体同事类：

package com.designpattern.Mediator;

/**
 * 具体同事类  -- 人员a
 * @author Json<<json1990@foxmail.com>>
 */
public class PeopleA extends People {

    public PeopleA(Mediator mediator,String name) {
        super(mediator, name);
    }
    
    /**
     * 接收消息
     */
    public void receive(String message){
        System.out.println("【A】收到消息：【"+message+"】");
    }
    
    /**
     * 发送消息
     */
    public void send(String message){
        System.out.println("【A】发出消息：【"+message+"】");
    }
}
package com.designpattern.Mediator;

/**
 * 具体同事类  -- 人员b
 * @author Json<<json1990@foxmail.com>>
 */
public class PeopleB extends People {

    public PeopleB(Mediator mediator,String name) {
        super(mediator, name);
    }
    
    /**
     * 接收消息
     */
    public void receive(String message){
        System.out.println("【B】收到消息：【"+message+"】");
    }
    
    /**
     * 发送消息
     */
    public void send(String message){
        System.out.println("【B】发出消息：【"+message+"】");
    }
}
package com.designpattern.Mediator;

/**
 * 具体同事类  -- 人员c
 * @author Json<<json1990@foxmail.com>>
 */
public class PeopleC extends People {

    public PeopleC(Mediator mediator,String name) {
        super(mediator, name);
    }
    
    /**
     * 接收消息
     */
    public void receive(String message){
        System.out.println("【C】收到消息：【"+message+"】");
    }
    
    /**
     * 发送消息
     */
    public void send(String message){
        System.out.println("【C】发出消息：【"+message+"】");
    }
}

具体中介者实现：

package com.designpattern.Mediator;

/**
 * 具体中介者类
 * @author Json<<json1990@foxmail.com>>
 */
public class MessageMediator implements Mediator {
    //持有并维护人员A
    private PeopleA A;
    //持有并维护人员B
    private PeopleB B;    
    //持有并维护人员C
    private PeopleC C;    

    public void setPeopleA(PeopleA A) {
        this.A = A;
    }

    public void setPeopleB(PeopleB B) {
        this.B = B;
    }
    
    public void setPeopleC(PeopleC C) {
        this.C = C;
    }

    /**
     * 发送消息
     */
    @Override
    public void chat(People p,String message) {
        if (p instanceof PeopleA) {
            A.send(message);
            B.receive(message);
            C.receive(message); 
        } else if (p instanceof PeopleB) {
            B.send(message);
            A.receive(message);
            C.receive(message);
        } else if (p instanceof PeopleC) {
            C.send(message);
            A.receive(message);
            B.receive(message);
        } 
    }
}

测试：

package com.designpattern.Mediator;

/**
 * 测试
 * @author Json<<json1990@foxmail.com>>
 */
public class Client {

    public static void main(String[] args) {
        MessageMediator mediator = new MessageMediator();
        
        PeopleA a = new PeopleA(mediator,"A");
        PeopleB b = new PeopleB(mediator,"B");
        PeopleC c = new PeopleC(mediator,"C");
        
        mediator.setPeopleA(a);
        mediator.setPeopleB(b);
        mediator.setPeopleC(c);
        
        mediator.chat(a, "中午吃啥饭？");
        System.out.println();
        
        mediator.chat(b,"我想吃刀削面");
        System.out.println();

        mediator.chat(c,"我也想吃刀削面");
        System.out.println();
        
        mediator.chat(a, "行，那中午一起去吃刀削面吧");
        System.out.println();
    }
}

结果：

【A】发出消息：【中午吃啥饭？】
【B】收到消息：【中午吃啥饭？】
【C】收到消息：【中午吃啥饭？】

【B】发出消息：【我想吃刀削面】
【A】收到消息：【我想吃刀削面】
【C】收到消息：【我想吃刀削面】

【C】发出消息：【我也想吃刀削面】
【A】收到消息：【我也想吃刀削面】
【B】收到消息：【我也想吃刀削面】

【A】发出消息：【行，那中午一起去吃刀削面吧】
【B】收到消息：【行，那中午一起去吃刀削面吧】
【C】收到消息：【行，那中午一起去吃刀削面吧】

4、优缺点

优点：

　　 简化了对象之间的交互：它用中介者和同事的一对多交互代替了原来同事之间的多对多交互，一对多关系更容易理解、维护和扩展，将原本难以理解的网状结构转换成相对简单的星型结构。

　　各同事对象之间解耦：中介者有利于各同事之间的松耦合，我们可以独立的改变和复用每一个同事和中介者，增加新的中介者和新的同事类都比较方便，更好地符合“开闭原则”。

　　减少子类生成：中介者将原本分布于多个对象间的行为集中在一起，改变这些行为只需生成新的中介者子类即可，这使各个同事类可被重用，无须对同事类进行扩展。

缺点：

　　中介者会庞大，变得复杂难以维护。

5、使用场景

　　1、对象间的交互虽定义明确然而非常复杂，导致一组对象彼此相互依赖而且难以理解。

　　2、因为对象引用了许多其他对象并与其通信，导致对象难以复用。

　　3、想要定制一个分布在多个类中的逻辑或者行为，又不想生成太多子类。

　　实际应用：

　　　　Mediator模式在事件驱动类应用中比较多，例如聊天、消息传递等等，需要有一个MessageMediator，专门负责request/reponse之间任务的调节。

　　　　MVC模式中，Controller是一种Mediator。

　　　　JDK的具体应用：

　　　　　　　　java.util.Timer

　　　　　　　　java.util.concurrent.Executor#execute()

　　　　　　　　java.util.concurrent.ExecutorService#submit()

　　　　　　　　java.lang.reflect.Method#invoke()

　　　　.......

6、中介者模式和外观模式

　　1、外观模式是结构型模式，中介者模式是行为型模式；

　　2、中介者模式主要用来封装多个平等对象之间相互的交互，多用在系统内部的多个模块之间；

　　　  外观模式旨在提供一个高层次的接口，封装的是单向的交互，是从客户端访问系统的调用，没有从系统中来访问客户端的调用；

　　　  外观模式协议是单向，中介者模式协议是双向；

　　3、中介者模式的实现里面，是需要实现具体的交互功能的；而外观模式的实现里面，一般是组合调用或是转调内部实现的功能，通常外观模式不添加额外的功能；

　　4、中介者模式的目的主要是松散多个模块之间的耦合，把这些耦合关系全部放到中介者中去实现；而外观模式的目的是简化客户端的调用；

7、总结

　　中介者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群，不要急于使用中介者模式，而先要思考在设计上是不是合理↓↓↓

　　PS：不应当在职责混乱的时候使用；

 

PS：源码地址   https://github.com/JsonShare/DesignPattern/tree/master 

   

PS：原文地址 https://blog.youkuaiyun.com/Json_wangqiang/article/details/85276194

   

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值