中介模式(mediator pattern)是一种“平台式”或“管家式”委派方式。
中介模式中,中介是各个希望相互交互的参与者的共同且唯一代理,它完成消息的转发或处理。
平台式中介
现实生活中有集市、股票交易所、婚姻介绍所、房屋中介等形形色色的中介(mediator)组织,它们有效地将参与者(participator)的两两交互转化为参与者与中介的交互。但是,这些中介正好是GoF中介模式的错误例子。网上有许多人用QQ为例引入中介模式,显然没有从代码的角度分析,纯属想当然。
这里说一个现实的场景。一场Party,有男生/Boy、女生/Girl参加,每个人都可以与其他对象交互。请问,实现这一场景的代码有多复杂?只有当你真正写出代码时,你会发现10万个对象的彼此交谈,也不过两个类的代码要写。
例程 5 9 不需要中介
package delegate.mediator.party;
public abstract class Actor{
String name;
public abstract void send(String message,Actor to);
public abstract void receive(String message,Actor from);
}
package delegate.mediator.party;
import static tool.Print.*;
public class Boy extends Actor{
private int count;
public Boy(String name){
this.name =name;
}
@Override public void send(String message,Actor to){
pln(this.name+" To "+to.name+":\""+message+"\"");
to.receive(message,this);
}
@Override public void receive(String message,Actor from){
char c = (char)(Math.random()*4+'a');
if(c!='b'){
String msg = message+" "+c;
send(msg,from);
}
}
}
package delegate.mediator.party;
public class Party{
public static void main(){
Actor[] alist = new Actor[]{
new Boy("B1"),new Boy("B2"),new Boy("B3"),new Boy("B4"),
new Girl("G1"),new Girl("G2"),new Girl("G3")
};
for(int i=0;i<alist.length;i++){
int rand= (int)(Math.random()*alist.length);
alist[i].send("hi",alist[rand]);
}
}
}
测试代码中,每一个Party参与者发起一次对话,对话的对象是随机的。对话的内容为随机字符,对话必须持续直到随机字符为b(bay)才结束。某一次运行结果(”//结束“不是程序的输出):
B1 To B4:"hi"
B4 To B1:"hi d"
B1 To B4:"hi d d"
B4 To B1:"hi d d a"
B1 To B4:"hi d d a a" //结束
B2 To B3:"hi" //结束
B3 To G2:"hi"//结束
B4 To B1:"hi"//结束
G1 To G2:[hi]
G2 To G1:[hi d]
G1 To G2:[hi d d]
G2 To G1:[hi d d d]
G1 To G2:[hi d d d a]
G2 To G1:[hi d d d a d]
G1 To G2:[hi d d d a d c]
G2 To G1:[hi d d d a d c a]
G1 To G2:[hi d d d a d c a a]
G2 To G1:[hi d d d a d c a a a]
G1 To G2:[hi d d d a d c a a a a]
G2 To G1:[hi d d d a d c a a a a c] //居然聊了这么多 //结束
G2 To B2:[hi]
B2 To G2:"hi c"
G2 To B2:[hi c a]
B2 To G2:"hi c a a"
G2 To B2:[hi c a a a]
B2 To G2:"hi c a a a c"
G2 To B2:[hi c a a a c a]
G3 To G1:[hi]
在讨论中介模式时,许多人看到对象的交互呈现网状结构,几乎每个对象都需要与其他对象发生相互作用。[GoF]中介者模式:“定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用,从而使其耦合性松散,而且可以独立地改变他们之间的交互”。事实上,上述代码告诉了一个事实,这里不需要中介模式:
①各对象之间并不需要“显式”持有彼此的引用。Boy和Girl是Actor的子类,即使Party中出现了Boy和Girl等具体类型,Boy和Girl的类体中依赖Actor即可。②多个类(Boy、Girl)的大量对象的交互,并不一定会导致类之间的过度耦合。Boy和Girl之间就不存在任何耦合。类似的,让家长、老师等参加Party,只要他们是Actor,彼此之间不存在任何耦合。
所以,上面的例子并不是我们需要 中介(这里不是 中介模式)的原因。然而,如果有一个对象需要找一个女朋友,他一个个地与每一个Girl对象交互,就显得非常低效和不现实。此时,他需要一个能够广播的“平台”。平台式的中介中,不管参与者如何形形色色,中介的作用如同一个公告牌。所以非常容易地联想到观察者模式,事实上,作为公告牌的“中介模式”就是观察者模式。
于是,由于中介者Party现在作为交互平台,它被所有感兴趣的参与者观察!再次不同于[GoF]中介者模式。[GoF]中,它写道“将Mediator实现为一个观察者,各Colleague作为Subject”。而此时,我们的代码是:Mediator实现为一个Subject,各Colleague作为Observer。
这一“平台式中介的代码,网上随处可见。
对象和类
[GoF]中介者模式:“定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用,从而使其耦合性松散..."
这也给我们带来一个问题:这里的”对象“是什么东西?
在Java等面向对象的语言中,yqj2065一直强调:类是第一性的。程序员编程针对的都是类而非对象。事实上,[GoF]的中介者模式——“管家式”委派方式中,才体现了一个类(的对象)发生状态改变,将导致许多其他类(的对象)发生相应的变化。和股票交易所、婚姻介绍所等不同,后者虽然参与者有诸多对象,真正的类不多而且交互简单。
有人说了:Party中有的男女对上眼了,会一直聊到Party结束;有的男生可以一直聊篮球;有的女生只和女生聊,有的女生只和名字好听的人聊……你怎么处理这些对象?
还是一句话:我将处理的不是对象而是类——匿名类!你可以用匿名类或λ表达式为客户留下无限的扩展空间。
总之,股票交易所、婚姻介绍所、聊天室的例子,都不是[GoF]中介者模式。