以下文章内容来源:微信公众号(Java知音)文章,设计模式是什么鬼(中介)
中介,作用于多个事物之间充当交互沟通的媒介。我们的生活中有各种各样的媒介,比如一些传统媒体,书刊杂志,报纸,把信息传递给读者。再比如利用电子信息技术的互联网,作为一种新媒体,不单可以更高效地把信息传递给用户,而且可以反向地获得用户反馈评论,用户与用户之间亦可以进行沟通,这种全终端双向互通是传统媒体所不能及的。
除此之外,再如婚介所、房产中介、交换机组网、现代电子商务、C2C购物平台、手机、即时通软件等等,这些都与我们的生活息息相关,离开它们我们将举步维艰。其实不管是任何中介,其本质都是相同的,都是充当中间媒介的角色,并达成多方业务互通的目的。
首先我们以最简单的模型来解决问题,以两个人交谈为例,其实他们之间并不需要任何第三方媒介,而是一对一直接沟通,看代码。
public class People { |
一切就绪,两人开始沟通。
public class Main { |
从People类中我们可以看到,沟通只只能在两人之间进行,而且各自都持有对方对象的引用,以便把消息传递给对方的监听方法。这种模式虽然简单,但耦合性太强,你中有我,我中有你,谁也离不开谁。试想如果再有多个人加入交谈,那每个人都要持有其他所有人的引用了,这时会陷入一种多对多的关联陷阱,对象关系变得复杂不堪,如蛛网般难以维护。
我们就拿群聊天室举例,每当有人加入或离开,都要把每个人持有的其他人的引用关系更新一遍,发消息时更是繁琐不堪,重复工作显得非常多余。那么如何解决这个问题呢?我们开始进行思考,为何不把重复的部分抽离出来呢,也就是把对方的引用放在一个中介类里面去统一维护起来,于是设计更改如下。
可以看到,每个用户不再所持有其他所有用户的引用了,取而代之的是聊天室的引用,这样引用关系瞬间变得明朗起来,开始我们的代码重构。
public class User { |
可以看到第14行,用户登陆聊天室时不再是连接对方了,而是连接通知聊天室并告知:“有人进来了请进行注册”,然后记录下来用户当前所在聊天室的引用。第19行,用户发言时也不是直接找对方了,而是把消息扔给聊天室处理。第23行,聆听方法同样也是,将来会接受来自聊天室的声音。很显然,一切沟通都与是中介聊天室进行,这样用户之间就实现了解耦的目的。接着写聊天室中介类:
public class ChatRoom { |
这里我们新建一个聊天室作为中介类,所有参与者登陆时调用第10行的connect方法进入聊天室,并记录其引用到users列表中。第17行,当用户发消息到平台我们再转发给其他人,这里利用Java8的流和Lambda表达式进行过滤(User类的equals方法请自行加入),并循环调用所有接收方的listen方法即可。
为了说明问题,我们这里只是保持最简单的方式,如果某天情况变得复杂,有了不同的用户,或是聊天室也各不相同并加入了各自的特性,那我们就需要继续重构,抽象聊天室类,抽象用户类,读者可以灵活运用,这里就不做赘述了。
其实中介模式不止是在生活中广泛应用,在软件架构中也非常常见,当下流行的微服务分布式软件架构所用到的注册中心,例如最常用到的云组件Eureka Server,其作用就是为众多分布式服务提供注册发现服务,它正是充当像中介一样的角色。
中介模式更像是网络拓扑中的星型结构,它描述了众节点与中心点的关系。
对像之间显式地互相引用越多,意味着依赖性越强,独立性越差,不利于代码维护与扩展,同时多方沟通的任务也应交由中间平台来完成,每个类应只具备各自该有的功能,这便是高内聚低耦合的设计标准。中介模式符合迪米特法则,它解决了对象间过度耦合、复杂频繁交互的问题,打破了你中有我,我中有你的相互依赖,第三方的介入有助于双方调停,打破如胶似漆、纠缠不休的关系,让他们之间变得松散、自由、独立。