## 引入
在閻宏博士的《JAVA與模式》一書中開頭是這樣描述調停者(Mediator)模式的:
> 中介者模式又稱為調停者模式。調停者模式是對象的行為模式。調停者模式包裝了一系列對象相互作用的方式,使得這些對象不必相互明顯引用。從而使它們可以較松散地耦合。當這些對象中的某些對象之間的相互作用發生改變時,不會立即影響到其他的一些對象之間的相互作用。從而保證這些相互作用可以彼此獨立地變化。
**為什么需要調停者**
如下圖所示,這個示意圖中有大量的對象,這些對象既會影響別的對象,又會被別的對象所影響,因此常常叫做同事(Colleague)對象。這些同事對象通過彼此的相互作用形成系統的行為。從圖中可以看出,幾乎每一個對象都需要與其他的對象發生相互作用,而這種相互作用表現為一個對象與另一個對象的直接耦合。這就是過度耦合的系統。

通過引入調停者對象(Mediator),可以將系統的網狀結構變成以中介者為中心的星形結構,如下圖所示。在這個星形結構中,同事對象不再通過直接的聯系與另一個對象發生相互作用;相反的,它通過調停者對象與另一個對象發生相互作用。調停者對象的存在保證了對象結構上的穩定,也就是說,系統的結構不會因為新對象的引入造成大量的修改工作。

一個好的面向對象的設計可以使對象之間增加協作性(Collaboration),減少耦合度(Couping)。一個深思熟慮的設計會把一個系統分解為一群相互協作的同事對象,然后給每一個同事對象以獨特的責任,恰當的配置它們之間的協作關系,使它們可以在一起工作。
## 定義
所謂中介者模式就是用一個中介對象來封裝一系列的對象交互,中介者使各對象不需要顯式地相互引用,從而使其耦合松散,而且可以獨立地改變它們之間的交互。
通過定義我們可以看出中介者主要是通過中介對象來封裝對象之間的關系,使之各個對象在不需要知道其他對象的具體信息情況下通過中介者對象來與之通信。同時通過引用中介者對象來減少系統對象之間關系,提高了對象的可復用和系統的可擴展性。
但是就是因為中介者對象封裝了對象之間的關聯關系,導致中介者對象變得比較龐大,所承擔的責任也比較多。它需要知道每個對象和他們之間的交互細節,如果它出問題,將會導致整個系統都會出問題。所以它比較容易應用也很容易誤用。故當系統中出現了“多對多”交互復雜的關系群時,千萬別急著使用中介者模式,你首先需要做的就是反思你的系統在設計上是不是合理。
## 結構
調停者模式的示意性類圖如下所示:

調停者模式包括以下角色:
* 抽象調停者(Mediator)角色:定義出同事對象到調停者對象的接口,其中主要方法是一個(或多個)事件方法。
* 具體調停者(ConcreteMediator)角色:實現了抽象調停者所聲明的事件方法。具體調停者知曉所有的具體同事類,并負責具體的協調各同事對象的交互關系。
* 抽象同事類(Colleague)角色:定義出調停者到同事對象的接口。同事對象只知道調停者而不知道其余的同事對象。
* 具體同事類(ConcreteColleague)角色:所有的具體同事類均從抽象同事類繼承而來。實現自己的業務,在需要與其他同事通信的時候,就與持有的調停者通信,調停者會負責與其他的同事交互。
在中介者模式中中介者對象處于核心地位,因為它定義了整個系統中所有具體同事類之間的關系。在整個系統中它主要承擔兩個方面的責任。
1、 結構上起到中轉作用。通過中介者對象對關系的封裝,使得具體的同事類不再需要顯示的引用其他對象,它只需要通過中介者就可以完成與其他同事類之間的通信。
2、 行為上起到協作作用。中介者對同事類之間的關系進行封裝,同事類在不需要知道其他對象的情況下通過中介者與其他對象完成通信。在這個過程中同事類是不需要指明中介者該如何做,中介者可以根據自身的邏輯來進行協調,對同事的請求進一步處理,將同事成員之間的關系行為進行分離和封裝。
同時由于中介者對對象的關系進行了封裝,使得各個同事類之間的耦合減少了,使得他們可以獨立改變和復用。
## 代碼實現
**使用電腦來看電影**
在日常生活中,我們經常使用電腦來看電影,把這個過程描述出來,簡化后假定會有如下的交互過程:
(1)首先是光驅要讀取光盤上的數據,然后告訴主板,它的狀態改變了。
(2)主板去得到光驅的數據,把這些數據交給CPU進行分析處理。
(3)CPU處理完后,把數據分成了視頻數據和音頻數據,通知主板,它處理完了。
(4)主板去得到CPU處理過后的數據,分別把數據交給顯卡和聲卡,去顯示出視頻和發出聲音。
要使用調停者模式來實現示例,那就要區分出同事對象和調停者對象。很明顯,主板是調停者,而光驅、聲卡、CPU、顯卡等配件,都是作為同事對象。

抽象同事類
```
public abstract class Colleague {
//持有一個調停者對象
private Mediator mediator;
/**
* 構造函數
*/
public Colleague(Mediator mediator){
this.mediator = mediator;
}
/**
* 獲取當前同事類對應的調停者對象
*/
public Mediator getMediator() {
return mediator;
}
}
```
同事類——光驅
```
public class CDDriver extends Colleague{
//光驅讀取出來的數據
private String data = "";
/**
* 構造函數
*/
public CDDriver(Mediator mediator) {
super(mediator);
}
/**
* 獲取光盤讀取出來的數據
*/
public String getData() {
return data;
}
/**
* 讀取光盤
*/
public void readCD(){
//逗號前是視頻顯示的數據,逗號后是聲音
this.data = "One Piece,海賊王我當定了";
//通知主板,自己的狀態發生了改變
getMediator().changed(this);
}
}
```
同事類——CPU
```
public class CPU extends Colleague {
//分解出來的視頻數據
private String videoData = "";
//分解出來的聲音數據
private String soundData = "";
/**
* 構造函數
*/
public CPU(Mediator mediator) {
super(mediator);
}
/**
* 獲取分解出來的視頻數據
*/
public String getVideoData() {
return videoData;
}
/**
* 獲取分解出來的聲音數據
*/
public String getSoundData() {
return soundData;
}
/**
* 處理數據,把數據分成音頻和視頻的數據
*/
public void executeData(String data){
//把數據分解開,前面是視頻數據,后面是音頻數據
String[] array = data.split(",");
this.videoData = array[0];
this.soundData = array[1];
//通知主板,CPU完成工作
getMediator().changed(this);
}
}
```
同事類——顯卡
```
public class VideoCard extends Colleague {
/**
* 構造函數
*/
public VideoCard(Mediator mediator) {
super(mediator);
}
/**
* 顯示視頻數據
*/
public void showData(String data){
System.out.println("您正在觀看的是:" + data);
}
}
```
同事類——聲卡
```
public class SoundCard extends Colleague {
/**
* 構造函數
*/
public SoundCard(Mediator mediator) {
super(mediator);
}
/**
* 按照聲頻數據發出聲音
*/
public void soundData(String data){
System.out.println("畫外音:" + data);
}
}
```
抽象調停者類
```
public interface Mediator {
/**
* 同事對象在自身改變的時候來通知調停者方法
* 讓調停者去負責相應的與其他同事對象的交互
*/
public void changed(Colleague c);
}
```
具體調停者類
```
public class MainBoard implements Mediator {
//需要知道要交互的同事類——光驅類
private CDDriver cdDriver = null;
//需要知道要交互的同事類——CPU類
private CPU cpu = null;
//需要知道要交互的同事類——顯卡類
private VideoCard videoCard = null;
//需要知道要交互的同事類——聲卡類
private SoundCard soundCard = null;
public void setCdDriver(CDDriver cdDriver) {
this.cdDriver = cdDriver;
}
public void setCpu(CPU cpu) {
this.cpu = cpu;
}
public void setVideoCard(VideoCard videoCard) {
this.videoCard = videoCard;
}
public void setSoundCard(SoundCard soundCard) {
this.soundCard = soundCard;
}
@Override
public void changed(Colleague c) {
if(c instanceof CDDriver){
//表示光驅讀取數據了
this.opeCDDriverReadData((CDDriver)c);
}else if(c instanceof CPU){
this.opeCPU((CPU)c);
}
}
/**
* 處理光驅讀取數據以后與其他對象的交互
*/
private void opeCDDriverReadData(CDDriver cd){
//先獲取光驅讀取的數據
String data = cd.getData();
//把這些數據傳遞給CPU進行處理
cpu.executeData(data);
}
/**
* 處理CPU處理完數據后與其他對象的交互
*/
private void opeCPU(CPU cpu){
//先獲取CPU處理后的數據
String videoData = cpu.getVideoData();
String soundData = cpu.getSoundData();
//把這些數據傳遞給顯卡和聲卡展示出來
videoCard.showData(videoData);
soundCard.soundData(soundData);
}
}
```
客戶端類
```
public class Client {
public static void main(String[] args) {
//創建調停者——主板
MainBoard mediator = new MainBoard();
//創建同事類
CDDriver cd = new CDDriver(mediator);
CPU cpu = new CPU(mediator);
VideoCard vc = new VideoCard(mediator);
SoundCard sc = new SoundCard(mediator);
//讓調停者知道所有同事
mediator.setCdDriver(cd);
mediator.setCpu(cpu);
mediator.setVideoCard(vc);
mediator.setSoundCard(sc);
//開始看電影,把光盤放入光驅,光驅開始讀盤
cd.readCD();
}
}
```
運行結果如下:
```
您正在觀看的是:One Piece
畫外音:海賊王我當定了
```
## 優點
* 松散耦合
調停者模式通過把多個同事對象之間的交互封裝到調停者對象里面,從而使得同事對象之間松散耦合,基本上可以做到互補依賴。這樣一來,同事對象就可以獨立地變化和復用,而不再像以前那樣“牽一處而動全身”了。
* 集中控制交互
多個同事對象的交互,被封裝在調停者對象里面集中管理,使得這些交互行為發生變化的時候,只需要修改調停者對象就可以了,當然如果是已經做好的系統,那么就擴展調停者對象,而各個同事類不需要做修改。
* 多對多變成一對多
沒有使用調停者模式的時候,同事對象之間的關系通常是多對多的,引入調停者對象以后,調停者對象和同事對象的關系通常變成雙向的一對多,這會讓對象的關系更容易理解和實現。
## 缺點
調停者模式的一個潛在缺點是,過度集中化。如果同事對象的交互非常多,而且比較復雜,當這些復雜性全部集中到調停者的時候,會導致調停者對象變得十分復雜,而且難于管理和維護。
## 適用場景
* 1、 系統中對象之間存在比較復雜的引用關系,導致他們之間的依賴關系結構混亂而且難以復用該對象。
* 2、 想通過一個中間類來封裝多個類中的行為,而又不想生成太多的子類。
## 總結
* 1、 在中介者模式中通過引用中介者對象,將系統中有關的對象所引用的其他對象數目減少到最少。它簡化了系統的結構,將系統由負責的網狀結構轉變成簡單的星形結構,中介者對象在這里起到中轉和協調作用。
* 2、 中介者類是中介者模式的核心,它對整個系統進行控制和協調,簡化了對象之間的交互,還可以對對象間的交互進行進一步的控制。
* 3、 通過使用中介者模式,具體的同事類可以獨立變化,通過引用中介者可以簡化同事類的設計和實現。
* 4、 就是由于中介者對象需要知道所有的具體同事類,封裝具體同事類之間相互關系,導致中介者對象變得非常復雜,系統維護起來較為困難。
- java
- 設計模式
- 設計模式總覽
- 設計原則
- 工廠方法模式
- 抽象工廠模式
- 單例模式
- 建造者模式
- 原型模式
- 適配器模式
- 裝飾者模式
- 代理模式
- 外觀模式
- 橋接模式
- 組合模式
- 享元模式
- 策略模式
- 模板方法模式
- 觀察者模式
- 迭代子模式
- 責任鏈模式
- 命令模式
- 備忘錄模式
- 狀態模式
- 訪問者模式
- 中介者模式
- 解釋器模式
- 附錄
- JVM相關
- JVM內存結構
- Java虛擬機的內存組成以及堆內存介紹
- Java堆和棧
- 附錄-數據結構的堆棧和內存分配的堆區棧區的區別
- Java內存之Java 堆
- Java內存之虛擬機和內存區域概述
- Java 內存之方法區和運行時常量池
- Java 內存之直接內存(堆外內存)
- JAVA內存模型
- Java內存模型介紹
- 內存模型如何解決緩存一致性問題
- 深入理解Java內存模型——基礎
- 深入理解Java內存模型——重排序
- 深入理解Java內存模型——順序一致性
- 深入理解Java內存模型——volatile
- 深入理解Java內存模型——鎖
- 深入理解Java內存模型——final
- 深入理解Java內存模型——總結
- 內存可見性
- JAVA對象模型
- JVM內存結構 VS Java內存模型 VS Java對象模型
- Java的對象模型
- Java的對象頭
- HotSpot虛擬機
- HotSpot虛擬機對象探秘
- 深入分析Java的編譯原理
- Java虛擬機的鎖優化技術
- 對象和數組并不是都在堆上分配內存的
- 垃圾回收
- JVM內存管理及垃圾回收
- JVM 垃圾回收器工作原理及使用實例介紹
- JVM內存回收理論與實現(對象存活的判定)
- JVM參數及調優
- CMS GC日志分析
- JVM實用參數(一)JVM類型以及編譯器模式
- JVM實用參數(二)參數分類和即時(JIT)編譯器診斷
- JVM實用參數(三)打印所有XX參數及值
- JVM實用參數(四)內存調優
- JVM實用參數(五)新生代垃圾回收
- JVM實用參數(六) 吞吐量收集器
- JVM實用參數(七)CMS收集器
- JVM實用參數(八)GC日志
- Java性能調優原則
- JVM 優化經驗總結
- 面試題整理
- 面試題1
- java日志規約
- Spring安全
- OAtuth2.0簡介
- Spring Session 簡介(一)
- Spring Session 簡介(二)
- Spring Session 簡介(三)
- Spring Security 簡介(一)
- Spring Security 簡介(二)
- Spring Security 簡介(三)
- Spring Security 簡介(四)
- Spring Security 簡介(五)
- Spring Security Oauth2 (一)
- Spring Security Oauth2 (二)
- Spring Security Oauth2 (三)
- SpringBoot
- Shiro
- Shiro和Spring Security對比
- Shiro簡介
- Session、Cookie和Cache
- Web Socket
- Spring WebFlux