实际生活中的例子：
现在流行炒股，股民一般都手持好多个股票，而股民每天需要关注手中N个股票的动向，随时针对不同的股票作出不同的决策，这样感觉心好累；于是有的人选择买基金。基金本质上还是炒股票，只不过基金机构拿了投资人的钱买了N个股票，而我们只要购买一个基金就够了，对N个股票的管理就交给基金机构去折腾了，我们瞬间感觉好轻松。
代码世界也是一样，每个股票都是一个类，每个基金都是一个类，股民就是这些类的使用者。如果股民直接操作多个股票类，那会导致股民类中的操作非常复杂，那么股民类和整个系统的藕合度也就很高。如果引入一个基金类，对股票类的操作全都由基金类来完成，股民类只需要与基金类交互即可，这样就大大降低了股民类的复杂度，降低了股民类和系统之间的藕合度。
外观模式的类图：
现在有好多个子系统，他们都有对外的接口，如果让客户端直接与这些子系统交互，那么客户端代码会过于复杂；这时候引入一个外观类，用于处理与各个子系统之间的交互，客户端只需调用外观类简单的接口即可操作各个子系统。
外观模式在MVC中的运用：
MVC模式将整个系统分成Action层、Service层、DAO层。Action层就相当于客户端，Service层就相当于外观类，DAO层就相当于各个子系统。
如果没有Service层，那么Action要直接与DAO交互；我们知道，一个功能可能需要多个DAO中的函数实现，那么这会导致Action中的代码过于复杂。所以我们在Action层和DAO层中间引入了Service层，将DAO层复杂的功能封装在Service层的函数中，Service层给Action层提供一系列简单的接口，这使得Action层的代码简单清晰。
何时使用外观模式？
1.在系统设计的阶段，就要使用MVC模式，将Action、Service、DAO层分离开，这样可以为复杂的DAO层的操作提供一个简单的接口，使得Action与DAO之间的藕合度大大降低。
2.在开发阶段，子系统会因不断地重构演化而变的越来越复杂；并且大多数的设计模式也会产生很多小类，这是好事，但也给外部调用他们的用户程序带来了使用上的困难。增加外观类可以给用户程序提供一个简单的接口，减少他们之间的依赖。
3.在维护时期，如果维护一个遗留的大型系统时，可能这个系统已经到了非常难以扩展和维护的地步了，但这个系统中包含了重要的功能我们必须使用它，如果直接调用这些功能可能会导致客户程序非常复杂，所以我们可以使用一个外观类，给复杂的遗留代码提供一个简单清晰的外部接口。
外观模式的官方定义：
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
外观模式的官方定义：
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/u010425776/article/details/48102515
