【IT168专稿】 Mediator模式有一种本事，就是可以让本身需要互相协作的对方，可以不用知道彼此，而把两者之间的联系，转交给Mediator来处理。换句 话说，Mediator模式解除了需要互相协调的对象之间的依赖。这也是Mediator（调停者）模式名字的由来。一个颇为形象的例子是聊天室。进入聊 天室的用户总是要彼此通信的，这些对象如果直接进行交互，就会彼此连接，最后织成一张纷繁复杂的大网。要分清彼此之间的关系，真可以说是“剪不断理还乱” 了。所以，引入一个聊天室对象来管理用户间的交流，就势成必然。

   Mediator模式与Facade模式都是管理复杂对象的行家里手，不过 二者在运用上还是有本质的不同。Facade是门面，通过它隔断了客户端与复杂对象之间的直接关系。Mediator是仲裁者，哪里出现纠纷哪里就有它的 身影。Facade对象对于客户端来说是可见的，而隐藏了复杂对象；Mediator对象对于客户端来说则是隐藏的，客户端直接调用复杂对象，而复杂对象 之间的关系，则转交给了Mediator。

   MVC模式则是职责分离的典范，就好似三权分立一般，各司其职。Model负责提供数 据，View则负责显示数据，Controller则负责控制Model与View之间的交互，封装了领域逻辑。这样的职责分离形式，能够有效地解除数据、业务逻辑与UI界面之间的耦合关系。但是，在MVC模式中，由于业务逻辑的问题，很有可能在Controller之间还需要进行交互。这种交互一旦增 多，就可能出现在一个Controller中出现不同的Controller，导致代码出现分散，形成霰弹式修改的坏味道。

   Marlon在其博客上发表了一篇文章，有效地将MVC模式与Mediator模式两者结合，创造出一种称之为MVC+M的模式，有效地解决了Controller对象之间相互依赖的问题。Marlon实现了一个文件浏览器来展示这一模式。运行程序，当我们点击左边的目录树时，在右边就会显示当前目录下的所有文件。UI如图所示：