设计模式--外观模式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.
实现

我们使用开关的例子;

<?php
/**
* 外观模式
*
*/
class SwitchFacade
{
private $_light = null; //电灯
private $_ac = null; //空调
private $_fan = null; //电扇
private $_tv = null; //电视 public function __construct()
{
$this->_light = new Light();
$this->_fan = new Fan();
$this->_ac = new AirConditioner();
$this->_tv = new Television();
}
/**
* 晚上开电灯
*
*/
public function method1($isOpen =1) {
if ($isOpen == 1) {
$this->_light->on();
$this->_fan->on();
$this->_ac->on();
$this->_tv->on();
}else{
$this->_light->off();
$this->_fan->off();
$this->_ac->off();
$this->_tv->off();
} }
/**
* 白天不需要电灯
*
*/
public function method2() {
if ($isOpen == 1) {
$this->_fan->on();
$this->_ac->on();
$this->_tv->on();
}else{
$this->_fan->off();
$this->_ac->off();
$this->_tv->off();
}
}
} /******************************************子系统类 ************/
/**
*
*/
class Light
{
private $_isOpen = 0;
public function on() {
echo 'Light is open', '<br/>';
$this->_isOpen = 1;
}
public function off() {
echo 'Light is off', '<br/>';
$this->_isOpen = 0;
}
} class Fan
{
private $_isOpen = 0;
public function on() {
echo 'Fan is open', '<br/>';
$this->_isOpen = 1;
}
public function off() {
echo 'Fan is off', '<br/>';
$this->_isOpen = 0;
}
} class AirConditioner
{
private $_isOpen = 0;
public function on() {
echo 'AirConditioner is open', '<br/>';
$this->_isOpen = 1;
}
public function off() {
echo 'AirConditioner is off', '<br/>';
$this->_isOpen = 0;
}
}
class Television
{
private $_isOpen = 0;
public function on() {
echo 'Television is open', '<br/>';
$this->_isOpen = 1;
}
public function off() {
echo 'Television is off', '<br/>';
$this->_isOpen = 0;
}
}
/**
* 客户类
*
*/
class client {
static function open() {
$f = new SwitchFacade();
$f->method1(1);
} static function close() {
$f = new SwitchFacade();
$f->method1(0);
}
}
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:

GoF--外观设计模式的更多相关文章

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

    Proxy(代理模式)和Facade(外观)设计模式它们均为更复杂的功能提供抽象化的概念,但这两种实现抽象化的过程大不相同 Proxy案例中,所有的方法和成员变量都来自于目标对象,必要时,该代理能够对 ...

  2. 猿取向的规划设计模式 ——GoF《设计模式》阅读摘要(零)

    这个话题是很奇怪,设计模式是引导程序的设计不是模仿什么软件?呃.我的意思是,这是 面"对象"相对的设计模式. 我曾见过有人写<给妻子解释设计模式>,这样的把计算机中的思 ...

  3. IOS设计模式第三篇之外观设计模式

    外观设计模式: 这个外观设计模式提供了一个单独的接口给复杂的子系统.而不是暴露用户的一组类和API,你仅仅暴露一个简单的同一的API. 下面的图片解释这个概念: API的用户根本不知道后面系统的复杂性 ...

  4. 外观设计模式 (Facade)

    目的:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使 外观设计模式使用场合: 1. 在设计初期阶段,应该有意识的将不同的两个分层.层与层之间建立外观 ...

  5. 实践GoF的设计模式:迭代器模式

    摘要:迭代器模式主要用在访问对象集合的场景,能够向客户端隐藏集合的实现细节. 本文分享自华为云社区<[Go实现]实践GoF的23种设计模式:迭代器模式>,作者:元闰子. 简介 有时会遇到这 ...

  6. C++外观设计模式模式(三)

    3.外观模式总结 引入了外观类.解除了客户类与子系统的耦合性.客户类不须要直接操作子系统,而是由外观类负责处理,对client而言是透明的,客户类仅仅须要操作外观类就能够了,符合"迪迷特法则 ...

  7. 面向程序猿的设计模式 ——GoF《设计模式》读书总结(壹)抽象工厂&amp;生成器

    第一部分:创建型模式 创建型模式抽象了实例化过程. 它们帮助一个系统独立于怎样创建.组合和表示它的那些对象.(把一些小的对象组装成大对象,这个工作由专门的类对象来做) 一个类创建型模式使用继承改变被实 ...

  8. .NET设计模式(12):外观模式(Façade Pattern)(转)

    概述 在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化.那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依 ...

  9. (转载)设计模式学习笔记(十一)——Facade外观模式

    (转载)http://www.cnblogs.com/kid-li/archive/2006/07/10/446904.html Facade外观模式,是一种结构型模式,它主要解决的问题是:组件的客户 ...

  10. Java设计模式学习记录-GoF设计模式概述

    前言 最近要开始学习设计模式了,以前是偶尔会看看设计模式的书或是在网上翻到了某种设计模式,就顺便看看,也没有仔细的学习过.前段时间看完了JVM的知识,然后就想着JVM那么费劲的东西都看完了,说明自己学 ...

随机推荐

  1. 如何设置ASP.NET页面的运行超时时间 (转载)

    全局超时时间 服务器上如果有多个网站,希望统一设置一下超时时间,则需要设置 Machine.config 文件中的 ExecutionTimeout 属性值. Machine.config 文件位于 ...

  2. Linux的fasync驱动异步通知详解【转】

    本文转载自:http://blog.csdn.net/coding__madman/article/details/51851338 版权声明:本文为博主原创文章,未经博主允许不得转载. 工作项目用有 ...

  3. windows环境安装和配置Apache-Tomcat7.0

    转自:http://blog.sina.com.cn/s/blog_7c35df9b010111sh.html 说明: Tomcat Manager的用户名和密码可以到"Tomcat安装目录 ...

  4. 微信H5页面内实现一键关注公众号

    H5页面内实现关注公众号的微信JSSDK没有相关接口开放,因此就得动点脑筋来实现该功能了.下面的方法就是通过一种非常蹊跷的方式实现的. 首先,需要在公众号内发表一篇原创文章,注意是原创文章,然后由另一 ...

  5. CryptoJS DES加密

    <!DOCTYPE html><html><head><meta charset="utf-8"><meta http-equ ...

  6. c++多线程の数据竞争和互斥对象

    看两个代码: void function() { ;i>;i--) { cout<<"from sub thread"+i<<endl; } } vo ...

  7. UE4 使用UGM制作血条

    声明:本文是自己做的项目,可能不是最好的方法,或有错误使用方式.各位不喜勿喷! HP进度 HP背景 将上面的资源拖到UE4中(使用UE4自带的颜色也可实现效果,具体参考官方教程 https://doc ...

  8. MySQL自定义函数

    用户自定义函数(user-defined function,UDF)是一种对MySQL扩展的途径,其用法与内置函数相同. 自定义函数两个必要条件: 参数:可以有另个或多个 返回值:只能有一个 创建自定 ...

  9. caffe + ubuntu16.04 (version without GPU)

    This Guide is based on caffe github wiki guide (https://github.com/BVLC/caffe/wiki/Ubuntu-16.04-or-1 ...

  10. Asp.Net 一个请求的处理流程

    1.浏览器请求 请求-准备环境-->处理请求   2.Aspnet 环境的创建 客户请求 IIS区分静态文件还是动态文件,静态文件直接文件返回,动态文件通过aspnet_isapi.dll进行处 ...