• 中介者模式


    一、定义

    中介者模式(Mediator Pattern) 又称为调解者模式或调停者模式。用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互。属于行为型模式。中介者模式包装了一系列对象相互作用的方式,使得这些对象不必相互明显作用。从而使它们可以松散耦合。当某些对象之间的作用发生改变时,不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。其核心思想是,通过中介者解耦系统各层次对象的直接耦合,层次对象的对外依赖通信统统交由中介者转发。

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

    • 抽象中介者(Mediator) :定义统一的接口, 用于各同事角色之间的通信;
    • 具体中介者(Concrete Mediator) :从具体的同事对象接收消息, 向具体同事对象发出命令,协调各同事间的协作;
    • 抽象同事类(Colleague) :每一个同事对象均需要依赖中介者角色, 与其他同事间通信时,交由中介者进行转发协作;
    • 具体同事类(Concrete Colleague) :负责实现自发行为(Self-Method) , 转发依赖方法(Dep-Method) 交由中介者进行协调。

    二、中介者模式的案例

     在现实生活中,中介者的存在是不可缺少的,如果没有了中介者,我们就不能与远方的朋友进行交流了。各个同事对象将会相互进行引用,如果每个对象都与多个对象进行交互时,将会形成如下图所示的网状结构。

     从上图可以发现,每个对象之间过度耦合,这样的既不利于信息的复用也不利于扩展。如果引入了中介者模式,那么对象之间的关系将变成星型结构,采用中介者模式之后会形成如下图所示的结构:

     

    从上图可以发现,使用中介者模式之后,任何一个类的变化,只会影响中介者和类本身,不像之前的设计,任何一个类的变化都会引起其关联所有类的变化。这样的设计大大减少了系统的耦合度。

    中介者模式是用来降低多个对象和类之间的通信复杂性。这种模式通过提供一个中介类,将系统各层次对象间的多对多关系变成一对多关系,中介者对象可以将复杂的网状结构变成以调停者为中心的星形结构,达到降低系统的复杂性,提高可扩展性的作用。若系统各层次对象之间存在大量的关联关系,即层次对象呈复杂的网状结构,如果直接让它们紧耦合通信,会造成系统结构变得异常复杂,且其中某个层次对象发生改变,则与其紧耦合的相应层次对象也需进行修改,系统很难进行维护。而通过为该系统增加一个中介者层次对象,让其他各层次需对外通信的行为统统交由中介者进行转发,系统呈现以中介者为中心进行通讯的星形结构,系统的复杂性大大降低。简单的说就是多个类相互耦合,形成了网状结构,则考虑使用中介者模式进行优化。中介者模式适用于以下场景:

    • 系统中对象之间存在复杂的引用关系,产生的相互依赖关系结构混乱且难以理解;
    • 交互的公共行为,如果需要改变行为则可以增加新的中介者类。

    1、群聊场景

    假设我们要构建一个聊天室系统,用户可以向聊天室发送消息,聊天室会向所有的用户显示消息,实际上就是用户发信息与聊天室显示的通信过程,不过用户无法直接将信息发给聊天室,而是需要将信息先发到服务器上,然后服务器再将该消息发给聊天室进行显示。具体代码如下。创建User类:

    public class User {
        private String name;
        private ChatRoom chatRoom;
    
        public User(String name, ChatRoom chatRoom) {
            this.name = name;
            this.chatRoom = chatRoom;
        }
    
        public String getName() {
            return name;
        }
    
        public void sendMessage(String msg){
            this.chatRoom.showMsg(this,msg);
        }
    }

    然后是ChatRoom:

    public class ChatRoom {
        public void showMsg(User user,String msg){
            System.out.println("[" + user.getName() + "] : " + msg);
        }
    }

    测试:

    public class Test {
        public static void main(String[] args) {
            ChatRoom chatRoom = new ChatRoom();
    
            User zs = new User("张三",chatRoom);
            User ls = new User("李四",chatRoom);
    
            zs.sendMessage("您好");
            ls.sendMessage("有啥事");
        }
    }

    上面这么写估计也很简单,下面按中介者定义来写一个

    // 抽象中介者
    public abstract class Mediator {
        protected ConcreteColleagueA colleagueA;
        protected ConcreteColleagueB colleagueB;
    
        public void setColleageA(ConcreteColleagueA colleague) {
            this.colleagueA = colleague;
        }
    
        public void setColleageB(ConcreteColleagueB colleague) {
            this.colleagueB = colleague;
        }
    
        // 中介者业务逻辑
        public abstract void transferA();
    
        public abstract void transferB();
    }
    // 具体中介者
    public class ConcreteMediator extends Mediator {
        @Override
        public void transferA() {
            // 协调行为:A 转发到 B
            this.colleagueB.selfMethodB();
        }
    
        @Override
        public void transferB() {
            // 协调行为:B 转发到 A
            this.colleagueA.selfMethodA();
        }
    }
    // 抽象同事类
    public abstract class Colleague {
        protected Mediator mediator;
    
        public Colleague(Mediator mediator) {
            this.mediator = mediator;
        }
    }
    // 具体同事类
    public class ConcreteColleagueA extends Colleague {
        public ConcreteColleagueA(Mediator mediator) {
            super(mediator);
            this.mediator.setColleageA(this);
        }
    
        // 自有方法
        public void selfMethodA() {
            // 处理自己的逻辑
            System.out.println(String.format("自有方法", this.getClass().getSimpleName()));
        }
    
        // 依赖方法
        public void depMethodA() {
            // 处理自己的逻辑
            System.out.println(String.format("依赖方法", this.getClass().getSimpleName()));
            // 无法处理的业务逻辑委托给中介者处理
            this.mediator.transferA();
        }
    }
    // 具体同事类
    public class ConcreteColleagueB extends Colleague {
        public ConcreteColleagueB(Mediator mediator) {
            super(mediator);
            this.mediator.setColleageB(this);
        }
    
        // 自有方法
        public void selfMethodB() {
            // 处理自己的逻辑
            System.out.println(String.format("自有方法", this.getClass().getSimpleName()));
        }
    
        // 依赖方法
        public void depMethodB() {
            // 处理自己的逻辑
            System.out.println(String.format("依赖方法", this.getClass().getSimpleName()));
            // 无法处理的业务逻辑委托给中介者处理
            this.mediator.transferB();
        }
    }
    public class Test {
        public static void main(String[] args) {
            Mediator mediator = new ConcreteMediator();
            ConcreteColleagueA colleagueA = new ConcreteColleagueA(mediator);
            ConcreteColleagueB colleagueB = new ConcreteColleagueB(mediator);
            colleagueA.depMethodA();
            System.out.println("-------------------------");
            colleagueB.depMethodB();
        }
    }

    三、中介者模式在源码中的体现

    在JDK的Timer类中有很多的schedule()重载方法,如下图:

     随便点开一个方法,会发现所有的方法最终都是调用了私有的sched()方法,下面看下Timer源码

    public class Timer {
         ......
    
        public void schedule(TimerTask var1, long var2) {
            if (var2 < 0L) {
                throw new IllegalArgumentException("Negative delay.");
            } else {
                this.sched(var1, System.currentTimeMillis() + var2, 0L);
            }
        }
        ......
        private void sched(TimerTask var1, long var2, long var4) {
            if (var2 < 0L) {
                throw new IllegalArgumentException("Illegal execution time.");
            } else {
                if (Math.abs(var4) > 4611686018427387903L) {
                    var4 >>= 1;
                }
    
                synchronized(this.queue) {
                    if (!this.thread.newTasksMayBeScheduled) {
                        throw new IllegalStateException("Timer already cancelled.");
                    } else {
                        synchronized(var1.lock) {
                            if (var1.state != 0) {
                                throw new IllegalStateException("Task already scheduled or cancelled");
                            }
    
                            var1.nextExecutionTime = var2;
                            var1.period = var4;
                            var1.state = 1;
                        }
    
                        this.queue.add(var1);
                        if (this.queue.getMin() == var1) {
                            this.queue.notify();
                        }
    
                    }
                }
            }
        }
    
        public void cancel() {
            synchronized(this.queue) {
                this.thread.newTasksMayBeScheduled = false;
                this.queue.clear();
                this.queue.notify();
            }
        }
    
        public int purge() {
            int var1 = 0;
            synchronized(this.queue) {
                for(int var3 = this.queue.size(); var3 > 0; --var3) {
                    if (this.queue.get(var3).state == 3) {
                        this.queue.quickRemove(var3);
                        ++var1;
                    }
                }
    
                if (var1 != 0) {
                    this.queue.heapify();
                }
    
                return var1;
            }
        }
    }

    从中可以看到,不管是什么样的任务都被加到一个queue队列中顺序执行,可以把这个队列中的所有对象当成“同事”,同事之间的通信都是通过Timer来协调完成的,Timer就承担了中介者的角色。

    四、总结

    优点:

    • 减少类间依赖,将多对多依赖转化成了一对多,降低了类间耦合;
    • 类间各司其职,符合迪米特法则。

    缺点:

      中介者模式中将原本多个对象直接的相互依赖变成了中介者和多个同事类的依赖关系。当同事类越多时,中介者就会越臃肿,变得复杂且难以维护。

    补充:服务治理用的也是这个思路,将多条链路的访问进行拉平,调用同一个服务中心调用 

    git源码:https://gitee.com/TongHuaShuShuoWoDeJieJu/design_pattern.git

    这短短的一生我们最终都会失去,不妨大胆一点,爱一个人,攀一座山,追一个梦
  • 相关阅读:
    说说VNode节点(Vue.js实现)
    从Vue.js源码角度再看数据绑定
    《Cloud Native Infrastructure》CHAPTER 7(3)
    《Cloud Native Infrastructure》CHAPTER 7(2)
    《Cloud Native Infrastructure》CHAPTER 7 (1)
    《Cloud Native Infrastructure》CHAPTER 4(2)
    《Cloud Native Infrastructure》CHAPTER 4(1)
    《Cloud Native Infrastructure》CHAPTER 2(1)
    《Cloud Native Infrastructure》CHAPTER 1(2)
    《Cloud Native Infrastructure》CHAPTER 1(1)
  • 原文地址:https://www.cnblogs.com/xing1/p/15170205.html
Copyright © 2020-2023  润新知