JavaScript设计模式之外观模式介绍

外观模式说明

说明:外观模式是用于由于子系统或程序组成较复杂而提供的一个高层界面接口,使用客户端更容易访问底层的程序或系统接口;

外观模式是我们经常使用遇到的模式,我们经常涉及到的功能,可能需要涉及到几个子接口或子系统,而我们的某个功能,可能只需要这向个多个子接口中的一个或几个组成的顺序封装。如果是业务功能直接对应子接口或子系统的,可能要求开发人员对内部需要相当的了解;你可能需要去了解业务流程是怎么走,他的顺序是什么,等等。这即需要开发员了解业务,也使得客户端编程变得相当的复杂;

这里如果有一层,或是一个类,专门提供好封装好我们要使用的方法,客户端功能只需要与这个中间层类交互,中间层类的相应方法有了解业务的相关开发人员组织封装,那么程序将变得非常的简单,程序员只需要知道他这个功能所需要对应方法是哪个即可,也不用知道内部的逻辑。

这个中间层类就是我们说的外观类,这就是外观模式的思想。

场景实例:

1>. 比如总开关的例子,这个总开关,可以控制家里的大门的一盏灯,大厅的几盏灯,并控制着家电视机,电冰箱等的供电,你把哪个小按钮按上“ON”,哪个就有了电,甚至直接发光输热,你不必知道,这总开关上的按钮是怎么出来电的,或是怎么按制到相关电器的,反正直接压上就来电了。

这些个电灯,电视机等就是我们要使用的接口,小系统;这个总开关就是我们的外观类,我们直接面对它操作即可。

2>. 还好比一个公司,有好几个职能部门,老板哪一天需要各方面工作的执行情况了,他就跑去一个个部门内部,问个员工说这个某某事情办得怎么样了,如果问对人了能直接给老板答案,要是不是这个人负责的,他还会跟老板说,哦,这事是谁谁负责的,老板还得跑去问下那人,多麻烦。

如果每个职能部门设个主管负责人,老板直接去找它了解情况就可以了,老板也不用关心这个负责人是怎么知道这些的,他只要想了解的这么1,2,3件事情的情况跟进展即可。

实例源码

现在按第二个实例场景实现源码:

1. 几个部门职能类:

部门1 (业务部门):

代码如下:

function BusinessDept() {
  this.manager = '陈经理'; //负责人
}
BusinessDept.prototype = {
  MonthSales: function() {
    console.log(this.manager + '说:这个月销售额是xxx');
  },
  NextPlan: function() {
    console.log(this.manager + '说:接下来的计划是这样的,xxxx');
  }
}

部门2(研发部门):

代码如下:

function RDdept() {
  this.manager = '黄经理';
}
RDdept.prototype = {
  progress: function() {
    console.log(this.manager + '说:目前的项目情况跟进展是这样的xxx');
  },
  deptPlan: function() {
    console.log(this.manager + '说:接下来的部门规划是这样的xxx');
  }
}

以上是各部门主管所要回答老板的问题;

接下来建立外观类,用于组织老板想问的问题;

代码如下:

function Facade() {
  this.business = new BusinessDept() ;
  this.rddept = new RDdept();
}
Facade.prototype = {
  DeptSituation: function() {
    this.business.MonthSales(); //销售部经理先说;
    this.rddept.progress();
  },
  deptPlan: function() {
    this.business.NextPlan(); //报告接下来计划;
    this.rddept.deptPlan();
  }
}

接下来老板把两位经理叫到面前,开始问话了:

代码如下:

var facade = new Facade();
console.log('老板问:现在介绍下自己部门的情况?');
facade.DeptSituation();
console.log('老板问:接下来有什么规划?');
facade.deptPlan();

其他说明

使用外观模式,可以使得接口或类之间解耦,使得类之间不必产生依赖,不必要使用时得A包含B,或是B一定得包含A,这违反了关闭修改原则,使用中间层外观类包装,可以使得接口调用变得简单,使用子接口或子系统对象调用变得更加自由可组织。

外观模式经常出现我们的编程中,外观模式经常使用在架构系统的模式定义中出现,我们的系统要使用第三方的接口服务,也经常再加层外观层用于组织可用的业务接口;

(0)

相关推荐

  • php设计模式 Facade(外观模式)

    模式定义:外观模式(Facade Pattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.外观模式又称为门面模式,它是一种对象结构型模式. 模式结构: 外观模式的就是让client客户端以一种简单的方式来调用比较复杂的系统,来完成一件事情. Subsystem: 复制代码 代码如下: class car { public function start() { print_r("

  • Java设计模式之外观模式(Facade模式)介绍

    外观模式(Facade)的定义:为子系统中的一组接口提供一个一致的界面. Facade一个典型应用就是数据库JDBC的应用,如下例对数据库的操作: 复制代码 代码如下: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "<driver>" ).newInstance(); co

  • Java设计模式详解之门面模式(外观模式)

    门面模式(Facade Pattern)也叫外观模式,它隐藏系统的复杂性,并向客户端提供一个可以访问系统的接口.这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性,为子系统中的一组接口提供了一个统一的高层访问接口,这个接口使得子系统更容易被访问或使用.这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用. 简而言之,就是把一堆复杂的流程封装成一个接口供给用户更简单的使用,这个设计模式里有三个角色: 1)门面角色( facade ):

  • JavaScript设计模式之外观模式实例

    外观模式(门面模式),是一种相对简单而又无处不在的模式.外观模式提供一个高层接口,这个接口使得客户端或子系统更加方便调用. 用一段再简单不过的代码来表示: 复制代码 代码如下: var getName = function(){ return "svenzeng" } var getSex = function(){ return 'man' } 如果你需要分别调用getName和getSex函数. 那可以用一个更高层的接口getUserInfo来调用. 复制代码 代码如下: var

  • 轻松掌握java外观模式

    定义:外观模式(Facade),为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用 特点: (1)实现了子系统与客户端之间的松耦合关系. (2)客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易. 企业级开发和常用框架重的应用:很多,比如常见的字符串的分割方法spilt也是 具体实例: package com.test.faced; /** * 以喝茶为例:我们要喝茶,就得有茶具,茶叶,煮茶工具等 */ public c

  • java设计模式之外观模式学习笔记

    外观模式: 又称门面模式: 外观Facade为子系统的一组接口提供一个一致界面,使得这组子系统易于使用(通过引入一个新的外观角色降低原系统复杂度,同时降低客户类与子系统的耦合度). 图片来源: 设计模式: 可复用面向对象软件的基础. 实现 案例需求: 租房 有过自己找房租房经历的同学能够体会得到找房是件很痛苦的事, 不光要挨个小区跑而且还要跟(二)房东讨价还价. 于是后来学聪明了, 不再自己挨门挨户的磨嘴皮子, 而是直接找像链家.我爱我家这样的房屋中介, 他们手上握有一定的房源, 我们只需付给他

  • C#设计模式之外观模式介绍

    1.在设计初期阶段,应该要有意识的将不同的两层分离,比如考虑数据访问层.业务逻辑层.表示层之间建立外观模式,这样可以为子系统提供简单一致的接口,使得耦合大大降低. 2.开发阶段,子系统内部由于不够重构变得非常复杂,增加外观模式可以屏蔽这个复杂性,并提供简单的接口. 3.维护一个遗留的大型系统,代码不好再维护时,使用外观模式也是不错的选择. 看看外观模式的结构图: Facade类定义:可以给高层系统提供简单的接口 复制代码 代码如下: class Facade { SubSystemOne one

  • C++设计模式之外观模式

    前言 在实际开发时,面对一个大的系统,总是会将一个大的系统分成若干个子系统,等子系统完成之后,再分别调用对应的子系统来完成对应的整体功能,这样有利于降低系统的复杂性:最终进行实现某个具体的功能时,我们将对应的子系统进行组合就好了:但是,子系统那么多,关系那么复杂,组合形成一个完整的系统,是存在难度的. 我们在使用visual studio进行编译C++代码时,你只是在菜单中选择了Build,然后visual studio就开始了一堆的编译工作:你应该知道,因为你的一个简单的Build动作,编译器

  • 实例解析设计模式中的外观模式在iOS App开发中的运用

    外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义 一个高层接口,这个接口使得这一子系统更加容易使用. 下面给大家展示一下类的结构图,想必大家一看就明白了: 其实这个模式中,没有类与类之间的继承关系,只是进行了简单的类引用,统一了对外的接口而已.看起来是不是很简单?废话不多说了,下面简单向大家展示一下代码吧! 注意:本文所有代码均在ARC环境下编译通过. SubSystemOne类接口 复制代码 代码如下: #import <Foundation/Foundation.

  • java设计模式之外观模式(Facade)

    概述 外部与内部子系统通信时必须通过的一个统一的外观模式对象进行,就是外观模式,也称门面模式.一般而言,Facade模式是为了降低客户端与实现化层之间的依赖性.外观模式的用意是为子系统提供一个集中化和简化的沟通渠道. UML类图 在上面的UML图中,出现三个角色: 客户端角色(Client):用户通过客户端来调用外观模式的类,从而来操作子系统: 外观角色(Facade):客户端可以调用这个类,此类中包含了调用子系统中具体的功能: 子系统角色(Module):定义了子系统中具体的单个功能: 代码示

随机推荐