【大话设计模式】——行为型模式之“中介模式”

行为型模式的最后一个“中介模式”——命令模式，中介者模式和访问者模式。

下面就这三个模式进行一下简单的介绍。

命令模式——记录人

吃羊肉串的实例引出了命令模式。本来感觉卖羊肉串是小本买卖，所以老板可能不会雇人给专门记录什么的，但

志，以及支持可撤销的操作。 是也正是因为这样的想法，所以他们的买卖做不大！因为老板和顾客的联系太紧密了，

如果人一多，人多口杂，老板一个人根本记不过来这么多人的需求。所以有了我们的命令模式。

命令模式，将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日

志，以及支持可撤销的操作。再看看它的结构图：

命令模式它的作用有6个：

1、较容易设计一个命令队列

2、较容易将命令记入日志

3、允许接收请求的一方决定是否要否决请求

4、容易实现对请求的撤销和重做

5、增加新的具体命令类很容易

6、把请求一个操作的对象与知道怎么执行一个操作的对象分割开

中介者模式——就是中介

与命令模式不同的是，中介者模式又叫调停者模式。它的出现是为了解决对象的大量连接使得一个对象不可能在

没有其他对象的支持下工作，系统表现为一个不可能在没有其他对象的支持下工作，不可分割的整体，对系统的行为

进行任何较大的改动都十分困难。

就如书上的例子，如果没有联合国安理会，那么国家间的摩擦会增加，稍不注意就会发生战争。联合国的作用就

是中间调停的作用。

看看中介者模式的定义：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从

而使其耦合松散，而且可以独立地改变它们之间的交互。

它的结构图如下：

中介者模式主要应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分部在多个类中的

行为，而又不想生成太多的子类的场合。

它的优点：减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague和Mediator；能站在宏观的

角度看待系统。

缺点是：由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会

变得比任何一个ConcreteColleague都复杂。

访问者模式——解耦

（这是设计模式的最后一个模式，看完之后没有感觉，所以如果总结的不到位，还请指教哦！）

它的定义：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下，定义作用

于这些元素的新操作。

结构如如下：

Visitor的作用是为该对象结构中的ConcreteElement的每一个类生命一个Visit操作。

ConcreteVisitor实现每个有Visitor声明的操作。

ObjectStructure能枚举它的元素，提供一个高层的接口以允许访问者访问它的元素。

Element（元素）定义一个Accept操作，以一个访问者为参数。

访问者模式有点像我们平时发邮件，需要邮箱做中间的处理过程，根据发件人姓名的不同，达到群发单显的功

能。

它适用于数据结构相对稳定的系统，把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相

对自由地演化。

它的缺点是使增加新的数据结构变的困难了。

总结

上述这就是行为型模式中的“中介模式”的总结了。感觉访问者模式的总结有点生硬，因为了解的可能比较浅，

所以感觉总结出来之后没什么东西。这样，我的设计模式的技术博客总结就差不多了，接下来是我整个设计模式学习

的大总结了，期待吧！