外观模式 - Facade Patterns

定义

外观模式提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易访问。

封装交互，简化调用

问题

假设必须在代码中使用某个复杂的库或框架中的众多对象。正常状况下，须要负责全部对象的初始化工做、管理其依赖关系并按正确的顺序执行方法等。

最终，程序中类的业务逻辑将与第三方类的实现细节紧密耦合，使得理解和维护代码的工做很难进行。

解决方案

外观类为包含许多活动部分的复杂子系统提供一个简单的接口。与直接调用子系统相比，外观提供的功能可能比较有效，但却包含了客户端真正关心的功能。

若是程序须要与包含几十种功能的复杂库整合，但只须要使用其中部分功能，那么使用外观模式会比较方便。

例如，上传猫咪搞笑短视频到社交媒体网站的应用可能会用到专业的视频转换库，但它只需使用一个包含 encode(filename, format) 方法（以文件名与文件格式为参数进行编码的方法）的类便可。在建立这个类并将其链接到视频转换库后，一个外观模式就完成了。

案例

当经过电话给商店下达订单时，接线员就是该商店的全部服务和部门的外观。接线员提供了一个同购物系统、支付网关和各类送货服务进行互动的简单语音接口。

结构

1. 外观（Facade）提供了一种访问特定子系统功能的便捷方式，其了解如何重定向客户端请求，知晓如何操做一切活动部件。

2. 复杂子系统（Complex Subsystem）由数十个不一样对象构成。若是要用这些对象完成有意义的工做，你必须深刻了解子系统的实现细节，好比按照正确顺序初始化对象和为其提供正确格式的数据。

   子系统类不会意识到外观的存在，它们在系统内运做而且相互之间可直接进行交互。

3. 客户端（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()
复制代码

适用范围

• 为复杂子系统提供一个简单接口。知足大多数需求的同时，也能够越过外观类直接访问子系统。
• 客户程序与复杂子系统间存在很大依赖性。外观类可将客户与子系统解耦，提升子系统的独立性和可移植性。
• 层次化结构中，使用外观模式定义每一层入口，层与层间经过外观类创建联系，下降层之间的耦合度。

优缺点

优势：

1. 将客户与复杂子系统解耦。提升子系统的独立性和可移植性。
2. 减小客户端调用代码，使子系统更容易使用。
3. 只提供了一个新的统一入口，不影响直接调用子系统类。

缺点：

1. 不能很好限制客户使用子系统类，若是对客户访问子系统类作太多的限制则减小了可变性和灵活性。
2. 不引入抽象外观类的状况下，增长新的子系统可能须要修改外观类或客户端的源代码，违背了“开闭原则”

与其余模式关系

• 适配器模式意图是将接口转换成不一样的接口，外观模式的意图简化接口。
• 当只需对客户端代码隐藏子系统建立对象的方式时，可使用抽象工厂模式来代替。
• 享元模式展现了如何生成大量的小型对象，外观模式则展现了如何用一个对象来表明整个子系统。
• 外观模式和中介者模式的职责相似：它们都尝试在大量紧密耦合的类中组织起合做。
  • 外观为子系统中的全部对象定义了一个简单接口，可是它不提供任何新功能。子系统自己不会意识到外观的存在。子系统中的对象能够直接进行交流。
  • 中介者将系统中组件的沟通行为中心化。各组件只知道中介者对象，没法直接相互交流。
• 外观类一般能够转换为单例类，由于在大部分状况下一个外观对象就足够了。
• 外观模式与代理模式的类似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口，使得本身和服务对象能够互换，在这一点上它与外观不一样。

扩展

一个系统有多个外观类

在外观模式中，一般只须要一个外观类，而且此外观类只有一个实例，换言之它是一个单例类。在不少状况下为了节约系统资源，通常将外观类设计为单例类。固然这并不意味着在整个系统里只能有一个外观类，在一个系统中能够设计多个外观类，每一个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。

不要试图经过外观类为子系统增长新行为

不要经过继承一个外观类在子系统中加入新的行为，这种作法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增长应该经过修改原有子系统类或增长新的子系统类来实现，不能经过外观类来实现。

外观模式与迪米特法则

外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协做伙伴的数量减到最少，使得客户端与子系统内部的对象的相互做用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，下降了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。

抽象外观类的引入

外观模式最大的缺点在于违背了“开闭原则”，当增长新的子系统或者移除子系统时须要修改外观类，能够经过引入抽象外观类在必定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增长一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时经过修改配置文件来达到不修改源代码并更换外观类的目的。

Article by wuhb