前几天嗓子不舒服，去校医院买药。

到校医院，看挂号那没开门（里面有人的），就直接到取药的地方去拿药。谁知人家就是不给拿。无奈之下

只好去挂号那，A说明要来一盒西瓜霜，然后又跑过去拿药，我给钱人家说不行，这边不管收费，B到收费室去吧。（汗~），只好又去收费室，把钱给了，C然后又拿着盖好章的药单过去，这才拿到药。我想亏着我不是急诊，要是急诊也这么着，还真得把人给急死。

下面用图形来描述整件事：

然后再通过vb.net再讲故事讲一遍：

Module FacadeDemo2 Sub Main() '我去买西瓜霜 '让我先挂号，说明要什么药 Dim R As New Regedit R.GetDragName() '然后又到收费室缴费 Dim PF As New PayFor PF.Pay() '最后拿到西瓜霜 Dim GD As New GetDrag GD.GetaDrag() Console.WriteLine("哎，取个药真是烦死了。。。。") Console.ReadKey() End Sub End Module '挂号类 Public Class Regedit Public Sub GetDragName() Console.WriteLine("给我来一盒西瓜霜。。。。") End Sub End Class '缴费类 Public Class PayFor Public Sub Pay() Console.WriteLine("给你钱，三块一。。。。。。") End Sub End Class Public Class GetDrag Public Sub GetaDrag() Console.WriteLine("好了，我拿药走人了。。。。。") End Sub End Class

通过这么一折腾，心情很不好，我不就是拿个药吗，给钱，拿药，走人，不就得了吗？干嘛这么麻烦。刚好今天有深一步理解了外观模式，我就充当依次校领导，把这个校医院给整治一下。且看好了……

我在门口单独再来这么一个不门叫做“外观部门”，来得客户想要买药，把钱给她，一会她经过一系列工作，把药拿回来。多简单的事，这样又不会破坏原来的那些流程，又减少了客户的麻烦。那么我来试试这个效果怎么样。

先看图：

再通过图来将故事，表现形式为vb.net代码：

Module FacadeDemo2 Sub Main() '我去买西瓜霜，把钱给外观MM Dim FMM As New FacadeMM FMM.GetMoney() FMM.GiveDrag() Console.WriteLine("恩，还不错，还能欣赏风景。。。。") Console.ReadKey() End Sub End Module '外观部门 Public Class FacadeMM '定义相关类 Dim R As New Regedit Dim PF As New PayFor Dim GD As New GetDrag Public Sub GetMoney() 'MM收钱 Console.WriteLine("MM说：把钱给我。。。。") End Sub Public Sub GiveDrag() R.GetDragName() PF.Pay() GD.GetaDrag() Console.WriteLine("嘿，给你的药。。。。。") End Sub End Class '挂号类 Public Class Regedit Public Sub GetDragName() Console.WriteLine("。。。来一盒西瓜霜。。。。") End Sub End Class '缴费类 Public Class PayFor Public Sub Pay() Console.WriteLine("。。。钱，三块一。。。。。。") End Sub End Class Public Class GetDrag Public Sub GetaDrag() Console.WriteLine("。。。拿药 。。。。。。。") End Sub End Class

这样一来，又欣赏了风景又拿了药，病好的也就快了。不过作为“校领导”的我，还是得要求工作效率再提高些的。（ok.It’s the time to get up. ）

最后再来看一下具体的定义以及使用范围：

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

那么什么时候可以使用这个模式呢 ?

( 大话设计模式 ) 说：

何时使用外观模式：

分三个阶段来说，

首先在设计初期阶段 ，应该要有意识的将不同的两个层分离。比如经典的三层架构 ，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观 Façade ，则这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。

其次，在开发阶段 ，子系统往往因为不断地重构演化而变得越来越复杂 ，大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观 Façade 可以提供一个简单的接口，减少它们之间的依赖。

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