23种设计模式之中介者模式（Mediator）

文章目录

• 概述
• 中介者模式的优缺点
• 中介者模式的使用场景
• 中介者模式的结构和实现
• • 模式结构
  • 模式实现
• 总结

概述

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

中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。

中介者模式的优缺点

• 优点

  1. 遵守单一职责原则，各个组件的职责都可以保持克制和单一
  2. 遵守开闭原则，各个组件的代码不需要修改，但是他们的行为的可以通过实现中介类来做扩展
  3. 遵守迪米特法则，各个组件之间无需知晓对方的知识，只需要关注和中介的基础交互即可

• 缺点

  组件的可扩展、可维护，是将复杂度转移到中介对象上为代价，因此如果不加控制和设计，中介对象很容已成为一个“上帝对象”，啥都要管，谁都不敢改动

中介者模式的使用场景

至于使用场景如图所示：

中介者模式的结构和实现

模式结构

• Component：需要进行解耦的对象，上图各个Component最好继承自一个基类，这样会便于中介类做一些抽象和统一管控；每个Component都持有中介对象的引用，有事情发生时，调用notify就好，参数就是Component对象自己就好
• Meditator：中介，一般来讲中介类只有一个notify方法就足够了。中介对象持有所有Component的引用，他会收到各个Component对象发来的通知（notify），他知道该怎么协调，下一步该做什么。某种角度，它就是“上帝”，至于说怎么让上帝不至于变得过于复杂，是另外一个需要讨论的命题
• ConcreteMediator：具体的中介实现，不同的背景和目的下，实现也会有所不同，比如上面的表单例子中，不同的表单，需要调度的组件、校验、联动规则、提交后的去向等，都会有所不同

模式实现

通过聊天室实例来演示中介者模式。

实例中，多个用户可以向聊天室发送消息，聊天室向所有的用户显示消息。我们将创建两个类 ChatRoom 和 User。User 对象使用 ChatRoom 方法来分享他们的消息。

MediatorPatternDemo，我们的演示类使用 User 对象来显示他们之间的通信。

ChatRoom.java

public class ChatRoom {
   public static void showMessage(User user, String message){
      System.out.println(new Date().toString()
         + " [" + user.getName() +"] : " + message);
   }
}

User.java

public class User {
   private String name;
 
   public String getName() {
      return name;
   }
 
   public void setName(String name) {
      this.name = name;
   }
 
   public User(String name){
      this.name  = name;
   }
 
   public void sendMessage(String message){
      ChatRoom.showMessage(this,message);
   }
}

MediatorPatternDemo.java

public class MediatorPatternDemo {
   public static void main(String[] args) {
      User robert = new User("Robert");
      User john = new User("John");
 
      robert.sendMessage("Hi! John!");
      john.sendMessage("Hello! Robert!");
   }
}

输出结果：

Thu Jan 31 16:05:46 IST 2013 [Robert] : Hi! John!
Thu Jan 31 16:05:46 IST 2013 [John] : Hello! Robert!

总结

Mediator的出现，减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator。由于把对象如何协作做了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统。

由于ConcreteMediator控制了集中化，于是把交互复杂性变为了中介者的复杂性，这就使得中介这会变得比任何一个ConcreteColleague都复杂。

优点： 1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。

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

使用场景： 1、系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。

**注意事项：**不应当在职责混乱的时候使用。

更多更好内容请看这里。。。

---

🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽
本文作者：Java技术债务
原文链接：https://www.cuizb.top/myblog/article/1661429839
版权声明： 本博客所有文章除特别声明外，均采用 CC BY 3.0 CN协议进行许可。转载请署名作者且注明文章出处。

🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽🔽

---

JVM内存泄漏和内存溢出的原因
JVM常用监控工具解释以及使用
Redis 常见面试题（一）
ClickHouse之MaterializeMySQL引擎（十）
三种实现分布式锁的实现与区别
线程池的理解以及使用

---

最近面试BAT，整理一份面试资料，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。想获取吗？如果你想提升自己，并且想和优秀的人一起进步，感兴趣的朋友，可以在扫码关注下方公众号。资料在公众号里静静的躺着呢。。。

---

• 喜欢就收藏
• 认同就点赞
• 支持就关注
• 疑问就评论

一键四连，你的offer也四连