JavaScript设计模式之职责链模式

概述

职责链模式是设计模式中行为型的一种设计模式;

定义:使多个对象都有机会处理请求,从而避免请求的发送者与接收者之间的耦合关系,将这些处理请求的对象形成一个链,并沿着这个链传递请求,直到有一个对象处理它为止;

白话解释:作者坐标武汉,1000+万人口的新一线城市 ;以早高峰公交为例,早上早高峰的时候通常都是公交车前门拥堵,以至于没办法刷卡乘车;但是后门相对来说会空一些,这时我们选择后门上车,但是我们后门上车就刷不了卡;逃单?不存在的,这可不是我们作为讲文明、有素质的新一代青年应该做的;于是,我们往前面传递公交卡,请求前面的乘客帮忙传递至刷卡器处刷卡,但是我们是在后门,刷卡器是在前门,我们这传递的过程中会通过请求多位乘客帮忙传递公交卡,这个传递的过程就是一种职责链模式,每一位传递的乘客就是职责链中的节点对象;

代码实现

假设有一个售卖手机的电商网站,经过分别缴纳500元定金和200元定价的两轮预定后(订单此时生成),现在已经到了正式购买的阶段。公司针对支付过定金的客户有一定的优惠政策。在正式购买时,已支付过500元定金的客户将获得100元商城优惠券,已支付过200元的客户将获得50元商城优惠券;而之前没有支付过定金的客户将没有任何优惠券,并且在库存有限的情况下,还不一定能买得到;

参数定义

1.orderType:表示订单类型(定金用户或普通用户),code的值为1的时候是500元定金用户,为2的时候是200元定金用户,为3的时候是普通用户;

2.pay:表示用户是否已经支付定金,值为true或false。虽然用户下过500元的定金的订单,但如果他一直没有支付定金,现在只能以普通用户的身份进行购买;

3.stock:表示普通用户用于购买手机的库存数量,已经支付过500元定金或者200元定金的客户不受此限制;

实现

var order = function( orderType, pay, stock ){
    if ( orderType === 1 ){ // 500 元定金购买模式
        if ( pay === true ){ // 已支付定金
            console.log( '500 元定金预购, 得到100 优惠券' );
        }else{ // 未支付定金,降级到普通购买模式
            if ( stock > 0 ){ // 用于普通购买的手机还有库存
                console.log( '普通购买, 无优惠券' );

            }else{
                console.log( '手机库存不足' );
            }
        }
    }
    else if ( orderType === 2 ){ // 200 元定金购买模式
        if ( pay === true ){
            console.log( '200 元定金预购, 得到50 优惠券' );
        }else{
            if ( stock > 0 ){
                console.log( '普通购买, 无优惠券' );
            }else{
                console.log( '手机库存不足' );
            }
        }
    }
    else if ( orderType === 3 ){
        if ( stock > 0 ){
            console.log( '普通购买, 无优惠券' );
        }else{
            console.log( '手机库存不足' );
        }
    }
};
order( 1 , true, 500); //  500 元定金预购, 得到100 优惠券

上面的代码当然能实现需求功能,但是上述代码明显结构不清晰且order函数方法庞大,耦合程度很高;

职责链模式实现

我们使用职责链模式来实现上述功能,我们先把500元定金订单、200元定金订单、普通订单分为3个函数,接下来把orderType、pay、stock这3个参数传入;如果500元订单函数不符合处理条件,就将这个请求传递给200元订单函数,如果200元订单函数也不符合处理条件,则就将这个请求传递给普通订单函数;

var order500 = function( orderType, pay, stock ){
    if ( orderType === 1 && pay === true ){
        console.log( '500 元定金预购, 得到100 优惠券' );
    }else{
        order200( orderType, pay, stock ); // 将请求传递给200 元订单
    }
};
// 200 元订单
var order200 = function( orderType, pay, stock ){
    if ( orderType === 2 && pay === true ){
        console.log( '200 元定金预购, 得到50 优惠券' );
    }else{
        orderNormal( orderType, pay, stock ); // 将请求传递给普通订单
    }
};
// 普通购买订单
var orderNormal = function( orderType, pay, stock ){
    if ( stock > 0 ){
        console.log( '普通购买, 无优惠券' );
    }else{
        console.log( '手机库存不足' );
    }
};

// 测试结果:
order500( 1 , true, 500); // 500 元定金预购, 得到100 优惠券
order500( 1, false, 500 ); // 普通购买, 无优惠券
order500( 2, true, 500 ); // 200 元定金预购, 得到500 优惠券
order500( 3, false, 500 ); // 普通购买, 无优惠券
order500( 3, false, 0 ); // 手机库存不足

可以看到经过修改之后的代码,结构比之前的要清晰很多,拆分了函数并且去掉了很多if-else分支判断;

即使如果,修改后的代码依然是违反开放/封闭原则的,因为如果我们后面需求变更,就必须修改这些函数的内部;这显然不是我们想要的;

改良

我们先约定该函数不符合处理条件就返回nextSuccessor,如果符合处理条件就执行;

var order500 = function( orderType, pay, stock ){
    if ( orderType === 1 && pay === true ){
        console.log( '500 元定金预购,得到100 优惠券' );
    }else{
        return 'nextSuccessor'; // 我不知道下一个节点是谁,反正把请求往后面传递
    }
};

var order200 = function( orderType, pay, stock ){
    if ( orderType === 2 && pay === true ){
        console.log( '200 元定金预购,得到50 优惠券' );
    }else{
        return 'nextSuccessor'; // 我不知道下一个节点是谁,反正把请求往后面传递
    }
};

var orderNormal = function( orderType, pay, stock ){
    if ( stock > 0 ){
        console.log( '普通购买,无优惠券' );
    }else{
        console.log( '手机库存不足' );
    }
};

var Chain = function( fn ){
    this.fn = fn;
    this.successor = null;
};

//传递请求给下一个节点
Chain.prototype.setNextSuccessor = function( successor ){
    return this.successor = successor;
};

//传递请求给某个节点
Chain.prototype.passRequest = function(){

   //接收实例后的方法并将参数作为数组形式保存
    var ret = this.fn.apply( this, arguments );
    console.log(ret);

    //ret等于nextSuccessor就是不符合处理条件还得往下执行
    if ( ret === 'nextSuccessor' ){

     //这里是逻辑短路返回,并集一假则假;如果this.successor存在,则返回后面的执行结果;如果this.successor不存在,则返回this.nextSuccessor的值即为undefined
        return this.successor && this.successor.passRequest.apply( this.successor, arguments );
    }
};

var chainOrder500 = new Chain( order500 );
var chainOrder200 = new Chain( order200 );
var chainOrderNormal = new Chain( orderNormal );    

//沿职责链节点传递
chainOrder500.setNextSuccessor( chainOrder200 );
chainOrder200.setNextSuccessor( chainOrderNormal );

chainOrder500.passRequest( 1, true, 500 ); // 500 元定金预购,得到100 优惠券
chainOrder500.passRequest( 2, true, 500 ); // 200 元定金预购,得到50 优惠券
chainOrder500.passRequest( 3, true, 500 ); // 普通购买,无优惠券
chainOrder500.passRequest( 1, false, 0 ); // 手机库存不足

通过改良后,即使后面需求变更要出现定金300的订单,我们也可以轻松应对;

var order300=function(){
  //具体实现的行为
};

chainOrder300=newChain(order300);
chainOrder500.setNextSuccessor(chainOrder300);
chainOrder300.setNextSuccessor(chainOrder200);

tips:

补充知识:逻辑短路;虽然这是JS基础的知识,但是难免会有遗忘,我在写这篇文章的时候就忘了;

并集一假得假:如果是并集(并且)关系则第一个数是假的或不存在的,直接返回第二个数的值;

var x = a && b && c 等价于

var x = a;
if(a){
    x = b;
    if(b){
       x = c;
    }
}

或集一真得真:如果是或集(或者)关系,则第一个数是真的直接返回第一个数,第一个数是假的直接返回第二个;

var x = a || b || c 等价于:

var x;
if(a){
    x = a;
} else if(b){
    x = b;
} else {
    x = c;
}

记住上面加粗的两句话,基本就可以熟练运用逻辑短路了;

以上就是JavaScript设计模式之职责链模式的详细内容,更多关于JavaScript设计模式的资料请关注我们其它相关文章!

(0)

相关推荐

  • javascript设计模式 – 观察者模式原理与用法实例分析

    本文实例讲述了javascript设计模式 – 观察者模式原理与用法.分享给大家供大家参考,具体如下: 介绍:前面我们针对系统内一对多,多对多的情况做了解决方案,是使用中介者模式,将所有关联关系交由中介者处理.这一节我们介绍另外一种解决一对多问题的设计模式:观察者模式 观察者模式是使用频率最高的设计模式之一,用于建立一种对象与对象之间的依赖关系. 定义:定义对象之间的之间的一种一对多依赖关系,使得每当一个对象状态发生改变时,其相关依赖对象皆得到通知并被自动更新.观察者模式的别名包括发布-订阅模式

  • JavaScript实现职责链模式概述

    什么是职责链模式 职责链模式的定义是:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止.举个例子:当你从公交车后门上车之后,你不可能直接把硬币放到收款箱里面, 因为你不知道它在哪,那你就只能把硬币给你前面一个人,让他帮你传到前面一个人手上,这样一直传递到站在收款箱旁边人的手上,由他把硬币放到收款箱里面. 职责链模式思想 请求发送者只需要知道链中的第一个节点,从而弱化了发送者和一组接收者之间的强联系. J

  • JavaScript职责链模式概述

    一.概述 职责链模式(Chain of responsibility),就是使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止. 貌似和数据结构中的链表一样. 但,不要搞混了,职责链可不等于链表哦,因为职责链可以在任何一个节点开始往下查找,而链表,则必须从头结点开始往下查找. 比如,DOM事件机制中的冒泡事件就属于职责链,而捕获事件则属于链表. 二.利用职责链模拟冒泡 假设我们有三个对象:li.ul.di

  • JavaScript设计模式---单例模式详解【四种基本形式】

    本文实例讲述了JavaScript设计模式---单例模式.分享给大家供大家参考,具体如下: 单例模式也称为单体模式,其中: 1,单体模式用于创建命名空间,将系列关联的属性和方法组织成一个逻辑单元,减少全局变量. 逻辑单元中的代码通过单一的变量进行访问. 2,三个特点: ① 该类只有一个实例: ② 该类自行创建该实例,即在该类内部创建自身的实例对象: ③ 向整个系统公开这个实例接口 3,单体模式有四种基本形式: 第一种,最简单的单体,只被实例化一次    我简记为json对象 (1)基本结构 va

  • 深入理解JavaScript系列(38):设计模式之职责链模式详解

    介绍 职责链模式(Chain of responsibility)是使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理他为止. 也就是说,请求以后,从第一个对象开始,链中收到请求的对象要么亲自处理它,要么转发给链中的下一个候选者.提交请求的对象并不明确知道哪一个对象将会处理它--也就是该请求有一个隐式的接受者(implicit receiver).根据运行时刻,任一候选者都可以响应相应的请求,候选者的数目是任意

  • javascript设计模式 – 职责链模式原理与用法实例分析

    本文实例讲述了javascript设计模式 – 职责链模式原理与用法.分享给大家供大家参考,具体如下: 介绍:很多情况下,在一个软件系统中可以处理某个请求的对象不止一个.例如一个网络请求过来,需要有对象去解析request Body,需要有对象去解析请求头,还需要有对象去对执行对应controller.请求一层层传递,让每一个对象都基于请求完成自己的任务,然后将请求传递给下一个处理程序.是不是感觉有点中间件的感觉. 定义:职责链就是避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求.将

  • JavaScript设计模式之职责链模式应用示例

    本文实例讲述了JavaScript设计模式之职责链模式.分享给大家供大家参考,具体如下: 一.职责链的定义: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止. 二.实例场景说明: 某公司对公司产品-手机进行促销活动,有以下政策:在正式购买时,已经支付过500元定金的用户会收到100元的商城优惠卷,交200元定金的用户可以收到50元的优惠卷,而之前没有支付定金的用户只能进入普通购买模式,也就是没有优惠卷

  • JS 设计模式之:单例模式定义与实现方法浅析

    本文实例讲述了JS 设计模式之:单例模式定义与实现方法.分享给大家供大家参考,具体如下: 良好的设计模式可以显著提高代码的可读性,降低复杂度和维护成本.笔者打算通过几篇文章通俗地讲一讲常见的或者实用的设计模式. 今天先从最简单的一个入手:单例模式. 文中的示例代码会使用 ES6 语法,尽量简化不必要的细节 概念 单例模式(Singleton)属于创建型的设计模式,它限制我们只能创建单一对象或者某个类的单一实例. 通常情况下,使用该模式是为了控制整个应用程序的状态.在日常的开发中,我们遇到的单例模

  • JavaScript设计模式之观察者模式与发布订阅模式详解

    本文实例讲述了JavaScript设计模式之观察者模式与发布订阅模式.分享给大家供大家参考,具体如下: 学习了一段时间设计模式,当学到观察者模式和发布订阅模式的时候遇到了很大的问题,这两个模式有点类似,有点傻傻分不清楚,博客起因如此,开始对观察者和发布订阅开始了Google之旅.对整个学习过程做一个简单的记录. 观察者模式 当对象间存在一对多关系时,则使用观察者模式(Observer Pattern).比如,当一个对象被修改时,则会自动通知它的依赖对象.观察者模式属于行为型模式.在观察模式中共存

  • JavaScript设计模式--简单工厂模式定义与应用案例详解

    本文实例讲述了JavaScript设计模式--简单工厂模式定义与应用.分享给大家供大家参考,具体如下: 一,介绍 工厂模式创建对象(视为工厂里的产品)时无需指定创建对象的具体类. 工厂模式定义一个用于创建对象的接口,这个接口由子类决定实例化哪一个类.该模式使一个类的实例化延迟到了子类.而子类可以重写接口方法以便创建的时候指定自己的对象类型. 在这里将工厂简单分为三种: (1)简单工厂:通过第三方的类完成松耦合的任务. (2)复杂工厂:通过把实例化的任务交给子类来完成的,用以到达松耦合的目的. (

  • javascript设计模式 – 模板方法模式原理与用法实例分析

    本文实例讲述了javascript设计模式 – 模板方法模式原理与用法.分享给大家供大家参考,具体如下: 介绍:模板方法模式是结构最简单的行为型设计模式,在其结构中只存在父类与子类之间的继承关系.使用模板方法模式,可以将一些复杂流程的实现步骤封装在一系列基本方法中. 定义:定义一个操作中算法的框架,而将一些步骤延迟到子类中,模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤.模板方法是一种类行为型模式. 场景:我们设计一个游戏机,用来运行不同的游戏, 示例: var Game

  • javascript设计模式 – 访问者模式原理与用法实例分析

    本文实例讲述了javascript设计模式 – 访问者模式原理与用法.分享给大家供大家参考,具体如下: 介绍:访问者模式比较复杂,它包含访问者和被访问元素两个主要组成部分,这些被访问的元素通常具有不同的类型,且不同的访问者可以对他们进行不同的访问操作.访问者模式的主要目的是将数据结构与数据操作相分离. 定义:提供一个作用于某对象结构中的个元素的操作表示,它使得可以再不改变各元素的类的前提下定义作用于这些元素的新操作.访问者模式是一种对象行为型模式 场景:使用PC结构demo来解释下访问者模式 示

随机推荐