Mediator Pattern中介者模式,作为行为型设计模式的一种。其通过中介者实现了对各对象之间复杂的调用、关联关系的解耦,使之整体表现为松耦合的状态
现实世界的指引
就租房这件事来说,一般会有若干个租房者、若干个出租者。之前租房市场还不发达,每个租房者需要亲自和各个出租者进行对接、沟通。显然这种模式效率并不高。租房者和出租者需要两两之间建立连接。两个群体(租房群体、出租群体)的联系呈现出一种复杂的网状结构。后来房屋中介应运而生,租房者和出租者相互不再需要直接建立连接、沟通,而是都只和房屋中介进行沟通。这样就大大减轻了租房者、出租者各自的沟通成本。从而形成了以房屋中介为中心的星型结构
模式思想
在上面租房的例子中,我们通过引入房屋中介实现了将原有复杂的网状结构转换为以中介为中心的星型结构。这一宝贵的历史经验对于我们软件工程领域同样具有重大的历史意义。当系统中存在多个对象之间存在复杂的调用、关联关系、彼此之间存在复杂的网状关系时,即可以考虑通过引入中介者这一角色实现系统的松耦合。此举将一改原有对象需要持有其他各对象实例引用的复杂局面,使得各对象只需要持有中介者的引用即可,即只和中介者进行交互。而在中介者实例中,一方面其会持有所有对象实例的引用;另一方面其负责统一描述、封装各对象之间的交互关系。这一历史经验被总结为Mediator Pattern中介者模式 。在中介者模式下,其有以下几个角色
- 抽象同事角色:其是对具体同事角色的抽象定义,定义了一些通用的方法接口
- 具体同事角色:其是抽象同事角色的具体实现。其内部通过持有具体中介者角色的实例,实现与具体中介者角色的交互
- 抽象中介者角色:其定义了具体同事角色与中介者之间进行交互的方法
- 具体中介者角色:该角色则是抽象中介者角色的具体实现,其内部会持有所有具体同事角色的实例,以实现某个具体同事角色实例与其他同事角色实例的交互、联系
实现
一般项目中,我们通常会同时使用多种数据库,比如用于存储的MySQL,用于缓存服务的Redis,用于检索的ElasticSearch等等(严格来说ElasticSearch应该是一种数据检索中间件)。出于数据一致性的考虑,当某个数据库数据变动时(添加、删除数据),其他数据库需要进行同步操作,这里我们规定此三种数据库之间的数据同步规则
- 当某数据库添加数据时,其他各数据库均需添加相应数据
- 当MySQL删除数据时,Redis、ElasticSearch均需删除相应数据
- 当Redis删除数据时,ElasticSearch需删除相应数据
- 当ElasticSearch删除数据时,Redis需删除相应数据
如果不使用中介者模式,则数据同步操作就需要各数据库之间两两建立联系,相互持有引用来实现。非常不利于后期维护、拓展。而引入中介者模式就可以很好的解决这个问题,各数据库之间无需知道对方的存在,他们只负责和中介者打交道。而将数据同步操作统一在中介者中。当然中介者是需要知道各数据库的
好了,现在让我们来实现这个例子。以便大家更好的理解该模式的精髓。首先,我们定义一个抽象同事角色——即Database数据库类,其中定义各数据库通用的添加、移除、查看数据的操作
1 | /** |
然后来实现各个具体同事角色——即MySQL、Redis、ElasticSearch等数据库。可以看到,当某个数据库自己的数据发生变动时,会请求中介者进行同步操作(调用syncAddData、syncRemoveData方法)
1 | /** |
现在,就轮到我们的中介者角色登场了。首先定义一个抽象中介者角色——Mediator类
1 | /** |
然后实现一个用于数据同步的具体中介者,即DataSyncMediator类。可以看到,其内部持有各数据库的实例引用,并在syncAddData、syncRemoveData方法中统一实现具体的数据同步规则
1 | /** |
好了,现在让我们来实际测试下这个Demo
1 | /** |
测试结果如下,符合预期。当然对于中介者模式而言,其缺点也是显然易见的。由于中介者负责实现、维护各对象实例之间的交互规则,所以会导致中介者类代码急剧膨胀复杂
参考文献
- Head First 设计模式 弗里曼著