Facade(外观)模式

1. 概述

外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性。
例子1:一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计。

2. 问题

为了降低复杂性,常常将系统划分为若干个子系统。但是如何做到各个系统之间的通信和相互依赖关系达到最小呢?

3. 解决方案

外观模式:为子系统中的一组接口提供一个一致的界面, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。引入外观角色之后,用户只需要直接与外观角色交互,用户与子系统之间的复杂关系由外观角色来实现,从而降低了系统的耦合度。

4.
适用性

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

5.
结构

6.构建模式的组成

外观角色(Facade):是模式的核心,他被客户client角色调用,知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合\
子系统角色(Subsystem classes):实现子系统的功能,并处理由Facade对象指派的任务。对子系统而言,facade和client角色是未知的,没有Facade的任何相关信息;即没有指向Facade的实例。
客户角色(client):调用facade角色获得完成相应的功能。

7.
效果

Facade模式有下面一些优点:

1)对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。

2)实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。

3)降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。

4)只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类。

Facade模式的缺点

1) 不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。

2) 在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

8.
实现

我们使用开关的例子;

  1. <?php
  2. /**
  3. * 外观模式
  4. *
  5. */
  6. class SwitchFacade
  7. {
  8. private $_light     = null;     //电灯
  9. private $_ac        = null;     //空调
  10. private $_fan       = null;     //电扇
  11. private $_tv        = null;     //电视
  12. public function __construct()
  13. {
  14. $this->_light = new Light();
  15. $this->_fan = new Fan();
  16. $this->_ac = new AirConditioner();
  17. $this->_tv = new Television();
  18. }
  19. /**
  20. * 晚上开电灯
  21. *
  22. */
  23. public function method1($isOpen =1) {
  24. if ($isOpen == 1) {
  25. $this->_light->on();
  26. $this->_fan->on();
  27. $this->_ac->on();
  28. $this->_tv->on();
  29. }else{
  30. $this->_light->off();
  31. $this->_fan->off();
  32. $this->_ac->off();
  33. $this->_tv->off();
  34. }
  35. }
  36. /**
  37. * 白天不需要电灯
  38. *
  39. */
  40. public function method2() {
  41. if ($isOpen == 1) {
  42. $this->_fan->on();
  43. $this->_ac->on();
  44. $this->_tv->on();
  45. }else{
  46. $this->_fan->off();
  47. $this->_ac->off();
  48. $this->_tv->off();
  49. }
  50. }
  51. }
  52. /******************************************子系统类 ************/
  53. /**
  54. *
  55. */
  56. class Light
  57. {
  58. private $_isOpen = 0;
  59. public function on() {
  60. echo ‘Light is open‘, ‘<br/>‘;
  61. $this->_isOpen = 1;
  62. }
  63. public function off() {
  64. echo ‘Light is off‘, ‘<br/>‘;
  65. $this->_isOpen = 0;
  66. }
  67. }
  68. class Fan
  69. {
  70. private $_isOpen = 0;
  71. public function on() {
  72. echo ‘Fan is open‘, ‘<br/>‘;
  73. $this->_isOpen = 1;
  74. }
  75. public function off() {
  76. echo ‘Fan is off‘, ‘<br/>‘;
  77. $this->_isOpen = 0;
  78. }
  79. }
  80. class AirConditioner
  81. {
  82. private $_isOpen = 0;
  83. public function on() {
  84. echo ‘AirConditioner is open‘, ‘<br/>‘;
  85. $this->_isOpen = 1;
  86. }
  87. public function off() {
  88. echo ‘AirConditioner is off‘, ‘<br/>‘;
  89. $this->_isOpen = 0;
  90. }
  91. }
  92. class Television
  93. {
  94. private $_isOpen = 0;
  95. public function on() {
  96. echo ‘Television is open‘, ‘<br/>‘;
  97. $this->_isOpen = 1;
  98. }
  99. public function off() {
  100. echo ‘Television is off‘, ‘<br/>‘;
  101. $this->_isOpen = 0;
  102. }
  103. }
  104. /**
  105. * 客户类
  106. *
  107. */
  108. class client {
  109. static function open() {
  110. $f = new  SwitchFacade();
  111. $f->method1(1);
  112. }
  113. static function close() {
  114. $f = new  SwitchFacade();
  115. $f->method1(0);
  116. }
  117. }
  118. client::open();

11.
与其他相关模式

1)抽象工厂模式:Abstract Factory式可以与Facade模式一起使用以提供一个接口,这一接口可用来以一种子系统独立的方式创建子系统对象。 Abstract Factory也可以代替Facade模式隐藏那些与平台相关的类。
    2)中介模式:Mediator模式与Facade模式的相似之处是,它抽象了一些已有的类的功能。然而,Mediator的目的是对同事之间的任意通讯进行抽象,通常集中不属于任何单个对象的功能。
    Mediator的同事对象知道中介者并与它通信,而不是直接与其他同类对象通信。相对而言,Facade模式仅对子系统对象的接口进行抽象,从而使它们更容易使用;它并不定义新功能,子系统也不知道Facade的存在。 
    通常来讲,仅需要一个Facade对象,因此Facade对象通常属于Singleton模式。
   3)Adapter模式
    适配器模式是将一个接口通过适配来间接转换为另一个接口。
    外观模式的话,其主要是提供一个整洁的一致的接口给客户端。

12. 总结

1)根据“单一职责原则”,在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入一个外观对象,它为子系统的访问提供了一个简单而单一的入口。

2)外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,外观类充当了客户类与子系统类之间的“第三者”,同时降低客户类与子系统类的耦合度。外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。

3)外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行,外观类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与外观对象打交道,而不需要与子系统内部的很多对象打交道。

4)外观模式从很大程度上提高了客户端使用的便捷性,使得客户端无须关心子系统的工作细节,通过外观角色即可调用相关功能。

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

13.模式扩展

一个系统有多个外观类:

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

不要试图通过外观类为子系统增加新行为:

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

外观模式与迪米特法则:

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

抽象外观类的引入:

外观模式最大的缺点在于违背了“开闭原则”

当增加新的子系统或者移除子系统时需要修改外观类,可以通过引入抽象外观类在一定程度上解决该问题,客户端针对抽象外观类进行编程。对于新的业务需求,不修改原有外观类,而对应增加一个新的具体外观类,由新的具体外观类来关联新的子系统对象,同时通过修改配置文件来达到不修改源代码并更换外观类的目的。

UML:

时间: 2024-08-03 09:22:09

Facade(外观)模式的相关文章

Facade(外观)模式

Facade(外观)模式是一个功能介于工具包和完整应用程序之间的类,可提供包或子系统中类的简化功能. Facade模式通常起源于普通的程序开发.当从多个不同类中分离你的代码时,可能需要通过提取访问子系统的类来重构系统. /* * Copyright (c) 2001, 2005. Steven J. Metsker. * * Steve Metsker makes no representations or warranties about * the fitness of this softw

Facade——外观模式

Facade外观模式,也是比较常用的一种模式,基本上所有软件系统中都会用到. GOF 在<设计模式>一书中给出如下定义:为子系统中的一组接口提供一个一致的界面, Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.简单说,就是将复杂的逻辑封装起来,对外公开简单的接口,由客户程序调用.客户对象通过一个外观接口读写子系统中各接口的数据资源. 适用情景: (1)设计初期阶段,应该有意识的将不同层分离,层与层之间建立外观模式. (2)开发阶段,子系统越来越复杂,增加外观模式提供一

设计模式(十一):FACADE外观模式 -- 结构型模式

1. 概述 外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性.例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依赖关系达到最小呢? 3. 解决方案 外观模式:为子系统中的一组接口提供一个一致的界面,

Facade外观模式(C++实现)

外观模式:外观模式的意图是为系统中的大量对象提供一个一致的对外接口,以简化系统的使用.它提供了一个统一的接口,用来访问子系统中的一群接口.外观定义了一个高层接口,让子系统更容易使用.但外观并不屏蔽系统里的对象,如果需要,用户完全可以越过外观的包装使用底层对象以获得更灵活的功能. 外观模式结构图如下: 给出一个简单的C++实现 #include<iostream> using namespace std; class SubSystemA { public: SubSystemA(){} ~Su

java演示facade(外观)模式

实际应用中,原来的代码涉及多个子系统时,重新进行类的设计,将原来分散在源码中的类结构及方法重新组合,形成新的.统一的接口,供上层应用使用. Facade所面对的往往是多个类或其它程序单元,通过重新组合各类及程序单元,对外提供统一的接口/界面. 在遇到以下情况使用Facade模式: 1.当你要为一个复杂子系统提供一个简单接口时.子系统往往因为不断演化而变得越来越复杂.大多数模式使用时都会产生更多更小的类.这使得子系 统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一

facade外观模式

通过买股票与通过基金买股票引出外观模式: package com.disign.facade; /** * Created by zhen on 2017-05-18. */ public class TestStock { public void run1(){ Stock1 gu1 = new Stock1(); Stock2 gu2 = new Stock2(); Stock3 gu3 = new Stock3(); gu1.buy(); gu2.buy(); gu3.buy(); gu1

外观模式(Facade)

一.外观模式介绍 面向对象的一个比较重要的法则:迪米特法则(最少知识原则):一个软件实体应当尽可能少的与其他实体发生相互作用. 外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口.这个接口使得这一子系统更加容易使用.说白了,就可以理解为封装 外观模式的核心:为子系统提供统一的入口,封装子系统的复杂性,便于客户端调用 例1:股民炒股 未使用外观模式情况 要让股民尽可能少的与股票直接打交道,给其提供一个蒙面,让股民跟蒙面打交道.这样就符合了迪米特法则,让股民尽可能少的与股票打

php设计模式之Proxy(代理模式)和Facade(外观)设计模式

Proxy(代理模式)和Facade(外观)设计模式它们均为更复杂的功能提供抽象化的概念,但这两种实现抽象化的过程大不相同 Proxy案例中,所有的方法和成员变量都来自于目标对象,必要时,该代理能够对它所传递的数据进行修改或检查魔术方法使得Proxy的实现变的简单,Proxy模式的一类应用时用来记录方法的访问信息还可以利用Proxy的类确定代码的范围或调试程序中存在的问题 <?php class LoggingProxy{ private $target; //传递进去一个对象 public f

设计模式之外观模式(Facade)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些具体的类的信息封装起来.第二,它们隐藏了这些类的实例是如何被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,以

Java 设计模式:外观模式Facade

Facade 外观模式 外观模式----为子系统的一组接口提供一个统一的界面,此模式定义了一个更高层的接口,这一接口使得子系统更容易使用. 借用<大话设计模式>中的例子:市场上有N多只股票,当股民想要买股票时为了最大化自己的收益需要考察市面上很多种类的股票,然后根据自己的判断选取几只股票组合购买(这种场景下每一只股票都是可以单独购买的,用户需要考察.选取一组股票来一起购买).而有的用户直接购买基金,基金的作用是帮用户选取几只股票来组合购买,用户不用自己去选取多只股票. 在这个场景下:单独的购买