Facade 模式

外观模式（Facade），为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一个系统更加容易使用。

类图

说明

• Facade（窗口）

  Facade角色是代表构成系统的许多其他角色”简单窗口“。Facade角色向系统外部提供高层接口（API）。

• 构成系统的许多其他角色

  这些接口各自完成自己的工作，它们并不知道Facade角色。Facade角色调用其他角色进行工作，但是其他角色不会调用Facade角色。

• Client（请求者）

  Client角色负责调用Facade角色（Client角色不包含在Facade模式中）

何时使用

首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构。在层与层之间建立外观Facade，为复杂的子系统提供一个简单的接口。

其次，在开发阶段，子系统往往因为不断的重构演化变得越来越复杂，这时增加外观Facade可以提供一个简单的接口，减少客户程序与子系统中各种类之间的依赖。

最后，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖它。可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

Mediator 模式

中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。中介者使个对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

类图

说明

• Mediator(中介者，仲裁者)

  Mediator角色负责定义与Colleague角色进行通信和做出决定的接口（API）。

• ConcreteMediator（具体的中介者、仲裁者）

  ConcreteMediator角色负责实现Mediator角色的接口（API），负责实际做出决定。

• Colleague（同事）

  Colleague角色负责定义与Mediator角色进行通信的接口（API）。

• ConcreteColleague（具体的同事）

  ConcreteColleague角色负责实现Colleague角色的接口（API）

何时使用

中介者模式很容易在系统中应用，也很容易在系统中吴用。当系统出现‘多对多’交互复杂的对象群时，不要急于使用中介者模式，而是反思系统上设计是不是合理。

优点：Mediator的出现减少了各个Colleague的耦合，使得可以独立的该变和复用各个Colleague类和Mediator。由于把对象如何协作进行了抽象，将中介作为一个独立的概念并封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统。

缺点：由于ConcreteMediator控制集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。