前言
本文介绍中介者模式。
正文
概念
中介者模式属于行为型模式,是用在多个对象之间的通信,这种模式提供一个中介类,这个类处理不同类之间的通信,使代码松耦合易维护。
这个模式解决的问题是类与类之间关联性较大,系统呈网状结构,而这个模式就是将网状结构分离成星型结构,来减少类之间的依赖程度。
常用实例有:
- 网络通信,例如QQ群的通信。
- MVC框架中C(Controller)就是M(Model)和V(View)之间的中介者。
实现
就拿网络聊天来说,聊天室可以同时有多个人聊天,而这些聊天的人不必关心其他人是否能收到消息,而是只要将消息发往聊天室,而在线的人就可以从聊天室中看到其他人的消息。
我们就拿这个例子来看。
先创建一个聊天室类:
1 | public class ChatRoom { |
这里我们设为静态方法,接收一个User对象,以及消息msg,为了方便,我直接打印在控制台中。不然应该是发送到其他对象中。
其次我们创建User类
1 | public class User { |
我们直接在本地调用试试
1 | public class Client { |
如此我们实现了一个简单的中介者模式。
后续思考
那其实真正的聊天室并不是这样,这里我谈谈自己的见解吧,不一定对,只是我个人的思考。
在服务端,我们需要初始化聊天室类,其中内部维护一个列表,列表中存放着在此聊天室的人员。
之后初始化用户后,加入这个聊天室,例如ChatRoom.join(user,roomId),让这个用户加入这个聊天室。join方法可以是static的,因为需要网络通信,不可能在本地生成聊天室实例。之后返回是否成功加入,以及房间的具体信息。
加入之后调用user.sendMsg(msg,roomId),然后通过ChatRoom类中的方法将消息发送到服务端,服务端接收到之后,将该条消息转发给除该用户以外的所有用户。
至于服务端实现,则可以设计一个总服务端,并维护一个map,map中存放所有存活的聊天室,然后不设计小服务端,而是收到消息后转发给聊天室实例,这种设计对服务端要求较高。
而另外一种服务端设计则是在加入房间时与总服务端通信,之后服务端返回聊天室的地址,转而向聊天室服务端进行通信,这种设计减少了中控的压力。
以上就是一个聊天室的流程,由于涉及网络io,这里就不写代码了,大概原理了解一下。
但不管如何,这个模型依旧是一个中介者模式的模型。
优缺点
中介者模式降低类与类之间的耦合程度,并且由一对多关系转换成一对一关系。
而缺点在于中介者会很庞大,不利于维护,当中介者失效后,所有类则无法工作。
总结
本文介绍了中介者模式,以及实现了一个简单例子,中介者模式与代理模式还有外观模式有点相似,其相同点与不同点就留到外观模式之后再讲吧。