为了防止被“杀”了祭天，学点设计模式，并总结下还是有必要的。
一：理解
- 对象之间相互依赖调用会导致结构混乱。在中介者模式中，对象发起调用后，首先会经过中介者对象的路由，然后才将消息发送给被调用者。
- 中介者模式实现了调用者和被调用者的解耦，特别是在调用关系复杂的情况下，中介者的效果更为明显。
- 中介者模式可以将对象间复杂的网状调用关系重构成清晰的星型关系。
- 就像租房子的时候，房客可以直接找到中介，中介帮房客去和房东交流。房客可以通过中介和多个房东取得联系，同样的，房东可以通过中介和多个房客取得联系。
二：例子
你是个富二代。
你家有很多仆人，为了方便，只例举司机和厨师。
你家特别大，你和仆人们之间的交流基本靠高科技通信。
当你发消息时，仆人们都应该收到。
当司机发消息时，只有你会收到，因为其他仆人没有这个权利。
当厨师发消息时，你和其他仆人都会收到，毕竟各位吃货都不想错过用餐时间。
由于仆人实在太多，你叫来了程序员小菜帮忙抽象一下。
小菜考虑到：
- 可以使用观察者模式，当你发消息的时候，仆人们都会收到。但这样你需要持有所有仆人的对象，而且在这个需求中，仆人们也能发送消息，所以你们之间必然会有相互引用。
- 可以使用中介者模式，所有人都把消息发送给中介者，然后再由中介者进行消息转发。
小菜上来就是一顿敲。
他首先抽象出一个中介者接口，含有一个接受消息方法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("吃饭了!");
}
}
可以看到，角色之间不用再相互引用，只需要持有相同的中介者对象即可，对象之间的调用变得非常清晰。
输入/输出：
富二代发送消息了,内容是: 宝宝不开心了!
司机接到消息了,内容是: 宝宝不开心了!
厨师接到消息了,内容是: 宝宝不开心了!司机发送消息了,内容是: 宝宝要开车了!
富二代接到消息了,内容是: 宝宝要开车了!厨师发送消息了,内容是: 吃饭了!
富二代接到消息了,内容是: 吃饭了!
司机接到消息了,内容是: 吃饭了!
三：再理解
- 在例子中，角色在接受消息之后只是简单的打印消息。如果需要返回值，则被调用者需要给调用者发送一个消息，并且需要记录发送者的信息。
- 虽然调用者和被调用者之间的关系变得清晰，但中介者的逻辑并不清晰。中介者需要判断消息发送者并做出不同的响应，并且持有所有调用者对象。
- 当需要加入新的角色时，需要对中介者代码进行修改。
