JAVA23种设计模式——中介者模式

中介者模式，我觉得也可以称之为平台、调度等等。
局域网里一个最原始的聊天室，两个人（A和B），无需加入一个消息中间平台，直接两个人你按ip发给我，我按ip回复你就行了，但是这时候这俩人的交际圈扩大了，又增加了四个人（简称CDEF），这时候就有点复杂了，A必须要维护另外五个人（BCDEF）的ip地址，如果他们某些人更换了ip，还要重新修改A的聊天工具客户端，来使下一次发送消息到他们新的ip地址，其他五个人也是面临着同样的情况。

此时真是一言难尽，没有人愿意维护这种代码，更别提以后人会越来越多，这时候就想到我们在中间加一个平台，或者说调度中心，我们把消息发到平台，并告诉发送目标是谁，由平台来维护其他人的ip地址，不就容易多了。

此时消息平台只需维护六个人的ip地址就可以了，以后进来新的朋友直接添加就可以了。
A再发消息给C：只需要发送【发给C , “A给C说的悄悄话”】到消息中转平台就可以了，消息中转平台获取第一个参数，知道是发给C，从自己维护的最新ip列表里找到对应的C的地址，把第二个参数发送给C，即使C更换了ip地址，只需要在中转平台更新一下就可以了，另外五个人完全感知不到，套用到代码上，这就是对代码的解耦。
讲到这里，对中介者模式也基本了解差不多了，剩下的就是上代码：
1.首先定义一个接口，拥有发送和接收消息两种行为

public abstract class Students{
	public abstract void send(String name,String massage,Mediator mediator);//发送消息的行为，参数为（接收者名称，发送的消息，中转平台的对象）
	public abstract void receive(String massage);//接收消息的行为
}

2.所有聊天室成员（ABCDEF）继承这个抽象类，实现抽象方法，也就是拥有这两种行为

public class A extends Students{
	@Override
	public void receive(String message) {
		System.out.println("我是A，我现在收到了一条消息，内容是："+message);
	}
	@Override
	public void send(String name, String message,Mediator mediator) {
		System.out.println("我是A，我现在开始往"+name+"发送消息，内容是："+message);
		mediator.sendMessage(name,message);//给消息中转站发送消息，包含了目标名称和消息内容，无需知道目标ip（这里是无需获取对方实例）
	}
}
//其他的BCDEF的实现和这个基本相同，不再贴出

3.然后是中介类，本来应该先写个中介抽象类，方便以后扩展，这里为了减少初次理解中介者模式的复杂度，直接写一个中介类
中介类就是上面说的消息中转平台，里面存储了所有人员的地址（这里也就是成员的引用，在实例化时利用构造方法传进来）

public class Mediator{
	private Students A;//类似聊天室的ip地址
	private Students B;
	private Students C;
	//省略DEF...
	public Mediator(Students A,Students B,Students C){
		this.A = A;
		this.B = B;
		this.C = C;
		//省略DEF...
	}
	public void sendMessage(String name,String message){//发送消息给name，消息为message
		switch(name){
		case "A":
			A.receive(message);break;
		case "B":
			B.receive(message);break;
		case "C":
			C.receive(message);break;
		default:
			System.out.println("查无此人，请重新输入！");
		//省略DEF...
		}
	}
}

4.调用

public class Test {
	public static void main(String[] args){
		Students A = new A();//获取几位同学的ip地址
		Students B = new B();
		Students C = new C();
		//省略DEF的实例化
		Mediator mediator = new Mediator(A,B,C);//将ip地址更新到中转站
		A.send("B", "我是A，我有秘密告诉你，巴拉巴拉巴拉", mediator);//A向B发送消息
		A.send("C", "中午去吃黄焖鸡", mediator);//A向C发送消息
		B.send("C", "晚自习帮我给老师请个假", mediator);
		B.send("W", "晚自习帮我给老师请个假", mediator);//B向未加入的成员发送消息
	}
}
结果：
我是A，我现在开始往B发送消息，内容是：我是A，我有秘密告诉你，巴拉巴拉巴拉
我是B，我现在收到了一条消息，内容是：我是A，我有秘密告诉你，巴拉巴拉巴拉

我是A，我现在开始往C发送消息，内容是：中午去吃黄焖鸡
我是C，我现在收到了一条消息，内容是：中午去吃黄焖鸡

我是B，我现在开始往C发送消息，内容是：晚自习帮我给老师请个假
我是C，我现在收到了一条消息，内容是：晚自习帮我给老师请个假

我是B，我现在开始往W发送消息，内容是：晚自习帮我给老师请个假
查无此人，请重新输入！

最后说一下流程：

• 以前是直接向对方发送消息（实例化对方，然后调用对方的方法），
• 需要维护很多好友的ip地址（类里有很多其他类的实例，添加一个新类都需要在其他类里添加这个类的实例），
• 现在是直接把对方的名字和要发的消息发送到消息中转站就可以了，具体怎么找到对方就是消息中转站的事情了（在A的send方法里调用中介类的sendMessage(String name , String message)方法）
• 中转站从自己维护的最新ip地址列表里找到对方，并把消息发给对方（使用对方的实例，调用对方的receive(String massage)方法接收消息）

优点：
对其他实例的引用，从原来每个人各自保管，变成由中转站集中保管，简化了代码，提高了效率，降低了逻辑的复杂性。
缺点：
如果没架构好反而会变成灾难，越来越多的复杂逻辑会导致中介类变得难以维护，庞大臃肿，所以每个模式都有其适用的场景，先理解透彻再使用