相信大家都去超市买过东西,非常方便,而且超市货架上的货源不会断货,为了保证这一点,超市一定有自己的一个仓库,以便随时补货。既然有了仓库,就要有专门的人员从外面采购物品来存到仓库,针对这个场景,我们抽取出三个角色部门:销售部门、仓库苦闷、采购部门。这三个部门之间是相互依赖的。采购部门要根据销售部门的销售情况确定是否采购,也需要根据仓库的库存量决定是否采购,而销售部门只有在仓库部门有库存的情况下才能正常销售。我们大致画个图来表示三者之间的关系:
根据上面的分析,我们可以设计出如下类图:
代码清单如下。采购部门:
仓库部门:
销售部门:
场景类:
运行结果为:
程序功能达到了我们的期望,也能正常进行运转,不管怎么说,任务算是完成了。
我们重新看一下我们的程序,每个类都与其他两个类产生了关联,根据迪米特法则,每个类只和朋友类交流,这个朋友类,并不是越多越好,朋友类越多,耦合性越大,想要修改一个类就得修改一大片,这不是面向对象设计所期望的,况且这里还是只有三个部门的情况,现实中,一个公司可能会有几十个部门,并且各个部门之间也都是存在关联的,形成了一个蜘蛛网的结构,如果按照上面方式进行编码的话,单单维护起来就已经让人头大了。所以,我们必须对上面的代码进行重新设计。
针对这个问题,我们可以引入一个中介者,各个部门只与这个中介者对象进行交互,与自己无关的活动都丢给这个中介者去处理,这就是所谓的中介者模式。
中介者模式:用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其松耦合,而且可以独立地改变他们之间的交互。
中介者模式由以下几个部分组成:
1. Mediator抽象中介者角色
抽象中介者角色定义统一的接口,用于各同事角色之间的通信。
2. Concrete Mediator具体中介者角色
具体中介者角色通过协调各同事角色实现协作行为,因此,他必须依赖于各个同事角色。
3. Colleague同事角色
每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作。每个同事类的行为分为两种:一种是同事本身的行为,比如改变对象本身的状态,处理自己的行为等,这种行为叫做自发行为,与其他的同事类或者中介者没有任何的依赖;第二种是必须依赖中介者才能完成的行为,叫做依赖方法。
它们之间的关系如下图:
代码清单如下,抽象同事类:
它只持有一个抽象中介者的对象,交给子类去调用。
具体同事类:
抽象中介者:
它持有各个同事类的对象,并且在自己的业务逻辑处理中调用这些同事类对象的方法。
具体的中介者:
中介者所具有的方法都是比较复杂的业务逻辑,为同事类服务,其实现是依赖各个同事类来完成的。
学习了中介者模式后,我们现在来对上面例子中的代码进行改造。首先设计如下类图:
建立了两个抽象类AbstractMediator和AbstractColleague,每个对象只是与中介者Mediator之间产生依赖,与其他对象之间没有直接关系。代码清单如下:
抽象中介者:
具体的中介者,我们可以根据业务的要求产生出多个中介者,并划分各中介者的职责:
抽象同事类:
修改后的采购部门:
修改后的仓库部门:
修改后的销售部门:
修改后的场景类:
最后运行程序,结果是相同的。
中介者模式的优点就是减少了类间的依赖,把原有的一对多的依赖变成了一对一的依赖,降低了类间的耦合。
中介者模式的缺点就是中介者会膨胀的很大,而且逻辑复杂,同事类越多,中介者的逻辑就越复杂。
中介者模式适用于多个对象之间紧密耦合的情况,紧密耦合的标准是:在类图中出现了蜘蛛网状结构。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。