為了防止被“殺”了祭天，學點設計模式，并總結下還是有必要的。
一：理解
- 對象之間相互依賴調用會導致結構混亂。在中介者模式中，對象發起調用后，首先會經過中介者對象的路由，然后才將消息發送給被調用者。
- 中介者模式實現了調用者和被調用者的解耦，特別是在調用關系復雜的情況下，中介者的效果更為明顯。
- 中介者模式可以將對象間復雜的網狀調用關系重構成清晰的星型關系。
- 就像租房子的時候，房客可以直接找到中介，中介幫房客去和房東交流。房客可以通過中介和多個房東取得聯系，同樣的，房東可以通過中介和多個房客取得聯系。
二：例子
你是個富二代。
你家有很多仆人，為了方便，只例舉司機和廚師。
你家特別大，你和仆人們之間的交流基本靠高科技通信。
當你發消息時，仆人們都應該收到。
當司機發消息時，只有你會收到，因為其他仆人沒有這個權利。
當廚師發消息時，你和其他仆人都會收到，畢竟各位吃貨都不想錯過用餐時間。
由于仆人實在太多，你叫來了程序員小菜幫忙抽象一下。
小菜考慮到：
- 可以使用觀察者模式，當你發消息的時候，仆人們都會收到。但這樣你需要持有所有仆人的對象，而且在這個需求中，仆人們也能發送消息，所以你們之間必然會有相互引用。
- 可以使用中介者模式，所有人都把消息發送給中介者，然后再由中介者進行消息轉發。
小菜上來就是一頓敲。
他首先抽象出一個中介者接口，含有一個接受消息方法acceptMessageFromRole，其中參數msg表示消息內容，role表示發送的角色，如你，司機等。
public interface MediatorI {
void acceptMessageFromRole(String msg, Role role);
}
接著，他寫了一個角色抽象類。
@Data
public abstract class Role {
protected MediatorI mediator;
public abstract void sendMessageToMediator(String msg);
public abstract void acceptMessageFromMediator(String msg);
}
在該類中，包含一個中介者mediator屬性，因為角色需要將消息發送到中介者。
還包含發送消息給中介者方法sendMessageToMediator和從中介者接受消息方法acceptMessageFromMediator。
接著，小菜分別抽象了富二代類，司機類和廚師類。
// 富二代類
public class FuErDai extends Role {
@Override
public void sendMessageToMediator(String msg) {
System.out.println("富二代發送消息了,內容是: " + msg);
mediator.acceptMessageFromRole(msg, this);
}
@Override
public void acceptMessageFromMediator(String msg) {
System.out.println("富二代接到消息了,內容是: " + msg);
}
}
// 司機類
public class Driver extends Role {
@Override
public void sendMessageToMediator(String msg) {
System.out.println("司機發送消息了,內容是: "+msg);
mediator.acceptMessageFromRole(msg, this);
}
@Override
public void acceptMessageFromMediator(String msg) {
System.out.println("司機接到消息了,內容是: "+msg);
}
}
// 廚師類
public class Cook extends Role {
@Override
public void sendMessageToMediator(String msg) {
System.out.println("廚師發送消息了,內容是: " + msg);
mediator.acceptMessageFromRole(msg, this);
}
@Override
public void acceptMessageFromMediator(String msg) {
System.out.println("廚師接到消息了,內容是: " + msg);
}
}
三個角色都繼承自角色抽象類Role，又各自實現了抽象方法。
其中發消息方法sendMessageToMediator調用了中介者的接受消息方法，而收消息方法acceptMessageFromMediator只是簡單地打印消息。
在中介者模式中，需要有一個類來扮演中介者的角色，如同路由器在網絡傳輸中的角色。
在你家，你希望這個角色由管家來擔任。
于是小菜寫了管家類Housekeeper。
public class Housekeeper implements MediatorI {
private FuErDai fuErDai;
private Driver driver;
private Cook cook;
public Housekeeper(FuErDai fuErDai, Driver driver, Cook cook) {
this.fuErDai = fuErDai;
this.driver = driver;
this.cook = cook;
}
@Override
public void acceptMessageFromRole(String msg, Role role) {
if (role instanceof FuErDai) {
driver.acceptMessageFromMediator(msg);
cook.acceptMessageFromMediator(msg);
} else if (role instanceof Driver) {
fuErDai.acceptMessageFromMediator(msg);
} else if (role instanceof Cook) {
fuErDai.acceptMessageFromMediator(msg);
driver.acceptMessageFromMediator(msg);
}
}
}
管家類繼承自MediatorI接口，持有富二代，司機，廚師對象屬性。
在acceptMessageFromRole方法中，管家會判斷消息的來源，如果是來自富二代，就需要轉發給司機和廚師，即分別調用司機和廚師的acceptMessageFromMediator方法。
測試代碼：
public class Client {
public static void main(String[] args) {
FuErDai fuErDai = new FuErDai();
Driver driver = new Driver();
Cook cook = new Cook();
Housekeeper housekeeper = new Housekeeper(fuErDai, driver, cook);
fuErDai.setMediator(housekeeper);
driver.setMediator(housekeeper);
cook.setMediator(housekeeper);
//
fuErDai.sendMessageToMediator("寶寶不開心了!");
System.out.println();
driver.sendMessageToMediator("寶寶要開車了!");
System.out.println();
cook.sendMessageToMediator("吃飯了!");
}
}
可以看到，角色之間不用再相互引用，只需要持有相同的中介者對象即可，對象之間的調用變得非常清晰。
輸入/輸出：
富二代發送消息了,內容是: 寶寶不開心了!
司機接到消息了,內容是: 寶寶不開心了!
廚師接到消息了,內容是: 寶寶不開心了!司機發送消息了,內容是: 寶寶要開車了!
富二代接到消息了,內容是: 寶寶要開車了!廚師發送消息了,內容是: 吃飯了!
富二代接到消息了,內容是: 吃飯了!
司機接到消息了,內容是: 吃飯了!
三：再理解
- 在例子中，角色在接受消息之后只是簡單的打印消息。如果需要返回值，則被調用者需要給調用者發送一個消息，并且需要記錄發送者的信息。
- 雖然調用者和被調用者之間的關系變得清晰，但中介者的邏輯并不清晰。中介者需要判斷消息發送者并做出不同的響應，并且持有所有調用者對象。
- 當需要加入新的角色時，需要對中介者代碼進行修改。
