结构型设计模式: 外观模式(Facade Pattern)

结构型设计模式: 外观模式(Facade Pattern)

CSDN专栏: 设计模式(UML/23种模式)

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

外观模式(Facade Pattern)属于结构型模式。结构型模式涉及到如何组合类和对象以获得更大的结构;结构型类模式采用继承机制来组合接口或实现。结构型模式主要包括:Adapter模式、Bridge模式、Composite模式、Decorator模式、Facade模式、Flyweight模式和Proxy模式。结构型类模式在某种程度上具有相关性。

模式简介

GOF的《设计模式》指出Facade模式的意图是:
为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

将一个系统划分成为若干个子系统有利于降低系统的复杂性,设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个外观(Fecade)对象,它能为子系统提供简单的缺省视图。

Facade模式适用于以下场景:

  • 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。
  • 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Fecade将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性。
  • 当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过Fecade进行通讯,从而简化了它们之间的依赖关系。

模式图解

Facade模式的UML示例如下:

结构型设计模式: 外观模式(Facade Pattern)_第1张图片

Facade模式的工作过程如下:

  • Facade类知道哪些子系统类负责处理请求,将客户的请求代理给适当的子系统对象。
  • Subsystem包内的类实现子系统的功能,并负责处理由Facade对象指派的任务,禁止访问Facade类。
  • Client通过发送请求给Facade的方式与子系统通讯,Facade将这些消息转发给适当的子系统对象。
  • 使用Facade的客户程序不需要直接访问子系统对象。

Facade模式的有益效果如下:

  • 它对客户屏蔽子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
  • 它实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。
  • Facade模式有助于建立层次结构系统和建立对象间的分层依赖关系,并消除循环依赖关系。
  • 如果应用需要,它并不限制它们使用子系统类,可以在系统易用性和通用性之间灵活选择。

Abstract Factory模式可以与Facade模式一起使用以提供一个接口,这一接口可用来以一种子系统独立的方式创建子系统对象。 Abstract Factory也可以代替Facade模式隐藏那些与平台相关的类。Mediator模式和Facade模式均抽象了一些已有的类的功能。但是Mediator的目的协调若干个同事对象之间的通信,充当中介者和仲裁者的角色。Facade模式仅对子系统对象的接口进行抽象,简化原始子系统的接口的使用,原始子系统是外部系统或难于维护的子系统,不允许对原始子系统做任何修改。

模式实例

Android框架中大量使用了Facade模式,诸如:

  • ${android_sdk_root/frameworks/opt/net/wifi/service/java/com/android/server/wifi/FrameworkFacade.java

系列文章

  • CSDN专栏: 设计模式(UML/23种模式)
  • Github专栏: 设计模式(UML/23种模式)

参考文献

  • GOF的设计模式:可复用面向对象软件的基础
  • 设计模式之禅
  • 图说设计模式

你可能感兴趣的:(设计模式专题,设计模式(UML/23种模式),外观模式,Facade,Pattern,设计模式,结构型模式)