定义
外观模式提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易访问。
封装交互，简化调用
问题
假设必须在代码中使用某个复杂的库或框架中的众多对象。正常情况下，需要负责所有对象的初始化工作、管理其依赖关系并按正确的顺序执行方法等。
最终，程序中类的业务逻辑将与第三方类的实现细节紧密耦合，使得理解和维护代码的工作很难进行。
解决方案
外观类为包含许多活动部分的复杂子系统提供一个简单的接口。与直接调用子系统相比，外观提供的功能可能比较有效，但却包含了客户端真正关心的功能。
如果程序需要与包含几十种功能的复杂库整合，但只需要使用其中部分功能，那么使用外观模式会比较方便。
例如，上传猫咪搞笑短视频到社交媒体网站的应用可能会用到专业的视频转换库，但它只需使用一个包含 encode(filename, format) 方法（以文件名与文件格式为参数进行编码的方法）的类即可。在创建这个类并将其连接到视频转换库后，一个外观模式就完成了。
案例
当通过电话给商店下达订单时，接线员就是该商店的所有服务和部门的外观。接线员提供了一个同购物系统、支付网关和各种送货服务进行互动的简单语音接口。
结构
-
外观（Facade）提供了一种访问特定子系统功能的便捷方式，其了解如何重定向客户端请求，知晓如何操作一切活动部件。
-
复杂子系统（Complex Subsystem）由数十个不同对象构成。如果要用这些对象完成有意义的工作，你必须深入了解子系统的实现细节，比如按照正确顺序初始化对象和为其提供正确格式的数据。
子系统类不会意识到外观的存在，它们在系统内运作并且相互之间可直接进行交互。
-
客户端（Client）使用外观代替对子系统对象的直接调用。
示例
创建一个封装所需功能并隐藏其他代码的外观类，从而无需使全部代码直接与数十个框架类进行交互。该结构还能将未来框架升级或更换所造成的影响最小化，因为你只需修改程序中外观方法的实现即可。
// 这里有复杂第三方视频转换框架中的一些类。我们不知晓其中的代码，因此无法
// 对其进行简化。
class VideoFile
// ...
class OggCompressionCodec
// ...
class MPEG4CompressionCodec
// ...
class CodecFactory
// ...
class BitrateReader
// ...
class AudioMixer
// ...
// 为了将框架的复杂性隐藏在一个简单接口背后，我们创建了一个外观类。它是在
// 功能性和简洁性之间做出的权衡。
class VideoConverter is
method convert(filename, format):File is
file = new VideoFile(filename)
sourceCodec = new CodecFactory.extract(file)
if (format == "mp4")
destinationCodec = new MPEG4CompressionCodec()
else
destinationCodec = new OggCompressionCodec()
buffer = BitrateReader.read(filename, sourceCodec)
result = BitrateReader.convert(buffer, destinationCodec)
result = (new AudioMixer()).fix(result)
return new File(result)
// 应用程序的类并不依赖于复杂框架中成千上万的类。同样，如果你决定更换框架，
// 那只需重写外观类即可。
class Application is
method main() is
convertor = new VideoConverter()
mp4 = convertor.convert("funny-cats-video.ogg", "mp4")
mp4.save()
适用范围
- 为复杂子系统提供一个简单接口。满足大多数需求的同时，也可以越过外观类直接访问子系统。
- 客户程序与复杂子系统间存在很大依赖性。外观类可将客户与子系统解耦，提高子系统的独立性和可移植性。
- 层次化结构中，使用外观模式定义每一层入口，层与层间通过外观类建立联系，降低层之间的耦合度。
优缺点
优点：
- 将客户与复杂子系统解耦。提高子系统的独立性和可移植性。
- 减少客户端调用代码，使子系统更容易使用。
- 只提供了一个新的统一入口，不影响直接调用子系统类。
缺点：
- 不能很好限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
- 不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”
与其他模式关系
- 适配器模式意图是将接口转换成不同的接口，外观模式的意图简化接口。
- 当只需对客户端代码隐藏子系统创建对象的方式时，可以使用抽象工厂模式来代替。
- 享元模式展示了如何生成大量的小型对象，外观模式则展示了如何用一个对象来代表整个子系统。
- 外观模式和中介者模式的职责类似：它们都尝试在大量紧密耦合的类中组织起合作。
- 外观为子系统中的所有对象定义了一个简单接口，但是它不提供任何新功能。子系统本身不会意识到外观的存在。子系统中的对象可以直接进行交流。
- 中介者将系统中组件的沟通行为中心化。各组件只知道中介者对象，无法直接相互交流。
- 外观类通常可以转换为单例类，因为在大部分情况下一个外观对象就足够了。
- 外观模式与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口，使得自己和服务对象可以互换，在这一点上它与外观不同。
扩展
一个系统有多个外观类
在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。
不要试图通过外观类为子系统增加新行为
不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
外观模式与迪米特法则
外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
抽象外观类的引入
外观模式最大的缺点在于违背了“开闭原则”，当增加新的子系统或者移除子系统时需要修改外观类，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。
Article by wuhb
