中介者模式
定义
用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显示的相互引用,从而是其耦合松散,而且可以独立地改变他们的交互。
举例
其实这个中介者模式也相对来说比较好理解。重点就是在中介者者三个字上。
还是举现实中的例子进行分析,最直观的就是现实中的房产中介。通过房产中介,我们可以去看到一系列的房子的信息,即使我们并不了解这些个房子之后真正的售卖者。我们只需要通过这些个房产中介,就可以完成对于一个房产信息的了解,一个房子的购买等。总的来说,这个其实就是对于买房和卖房者这俩方之间的一处解耦合。这种解耦合的目的也十分明确,就是我们想让我们买房是不必依赖于卖房的一方。
通过房产中介这一角色,卖房一方可以将其的信息交由中介来进行管理,只需要付出相应的代价即可。同时,买房的一方也不再需要去直接联系卖房的一方,省去了很多寻找的功夫,只需要去了解中介提供的统一接口即可。同时,对应的也需要付出相应的代价。在现实生活中,这些个代价一般都是钱,那么在程序设计中,这个代价对应的就是我们的类的一定的访问权限。
如果我们对于这些角色间的关系使用连线来表示的话你应该就能够很清晰的了解这个关系的作用,在使用中介者模式之前,我们每个卖房者和买房者之间都有一条联系进行连接,这样的情况下双方角色一多就会出现一个非常复杂的关系网。如果改用中介者模式呢。在中介者模式下,我们在卖房者和买房者之间添加了一层缓冲,双方都可以通过这一层去进行与另一方的联系而不必要去直接联系,可以预见的是,在这种情况下,我们的结构图将会变得更加简洁明了。双方的联系只会连接到中介者这一端,有中介者这个节点进行各个连线之间的调度,控制连线之间的双边关系。
在这种架构下,双方不需要去了解相互之间到底应该怎么进行沟通,只需要了解这个中介公司的要求即可,通过这个中介的接口,可以实现对于自身的一定程度上的委托,有这个中介来进行自身的一定的管理。
缺陷
当然,这种架构本身也存在着一些缺陷,这个我们应该也能够简单的理解。就现实情况而言,当你想要通过一个中介想把自己的一定信息挂上,你需要考虑什么?最直接的就是我要做的手续吧,然后呢,就是我使用这个中介平台的代价吧。这个手续在程序中的直观体现就是我们实现中介功能的这个类吧。如果一个类绑定到对应的中介类中的步骤太麻烦,那么是否绑定就需要斟酌一下了。
除此之外,还有什么?我们是否需要考虑一下我们使用这个中介类的代价,在程序中的体现就是我们这个中介类对于其所管理的类的访问权限,如果这个中介类需要的权限太多,那我们是否进行托管也需要考虑考虑吧。在程序设计中,这个的直观体现就是我们的中介类的设计复杂度,当我们的中介类包含了很多操作的时候,势必就需要使用对应的信息,但是是否暴露这些信息是由对应的角色决定的。
总的来说,中介模式的使用,需要权衡当前需要的功能及对应的中介类的代价,选择符合自己当前需求的方案,当然,这句话说了就等于没说,自己用用才能体会。
UML类图
这里的UML类图其实很清晰了,我们来进行一下简单的分析
首先,我们需要明确一下再这个类图。在这个类图中,存在着俩个抽象基类,这俩个抽象基类代表的就是我们前面说过的使用中介的对象和作为中介的对象。这里的抽象Country就是我们的抽象使用者,而MediatorOrg就是我们的抽象中介者类对象。
抽象使用者Country类
这个类中其实很经典,主要就是定义了一些我们的具体使用者的一些接口,定义了一些接口规范,本质上其实也没有什么好说的。可以看到的是,在这个抽象对象中,保留了一个对于我们中介类的一个指针获取对应的中介类的接口使用权限(这里打错了,将就着看就行)。
通过这个接口,我们可以去看到对应的中介者类给我们提供的行为,接下来就看这个类。
抽象中介者MediatorOrg类
这个类也没什么好说的,主要就是包含了一个成员用于使用当前中介类的成员的注册,这个map包含了所有的成员相关信息,没什么好说的。这里主要的就是一个通知函数,但是在UML类图中去看一个函数的实现是不现实的,这个留到等下的代码实例中去分析。只需要注意的是,在这些个中介者类中,包含了一些用于连接的双方进行通信的一些方法。
代码实例
中介者模式的代码其实很简单,我也没有什么分析的欲望,自己看一遍也基本了解架构了,毕竟已经到了设计模式的相对后期了,一些简单的我就不想再进行一遍遍的分析了,之后碰到有意思的再来吧。
抽象类
1 | // 抽象中介者 |
具体类
1 | // 具体中介者 |
客户端
1 | // 客户端 |
可以看到其实真的是没有什么意思的,风紧扯呼,主要是很多的其实之前都有接触过,就不再赘述了。
总结
中介者模式(Mediator Pattern) 是一种行为型设计模式,通过引入一个中介对象来封装多个对象之间的交互,从而降低对象之间的直接耦合性。对象不再直接引用或依赖彼此,而是通过中介者协调和管理它们的交互逻辑。
核心要点
- 解耦:中介者模式将对象间的交互集中到中介者,避免了对象之间的直接依赖。
- 灵活性:通过修改中介者,可以改变交互规则而不需要影响具体对象。
- 复杂性转移:系统交互的复杂性由对象转移到了中介者,中介者可能会变得复杂。
适用场景
- 系统中对象之间存在复杂的多对多交互。
- 希望通过一个中心化的管理者来简化对象之间的关系。
优缺点
- 优点:
- 降低类间耦合,提升系统可维护性和可扩展性。
- 将交互逻辑集中到中介者,便于管理。
- 缺点:
- 中介者可能变得复杂,容易成为“上帝对象”。
例子
- 聊天室(所有用户通过聊天室交流)。
- MVC 模式中,控制器作为中介者协调视图和模型的交互。