JavaScript 设计模式 --- 策略模式

前言

在我们编写业务代码时，分支结构应该是我们最常用到的结构了。下面先模拟一个简单的业务场景：
要根据当前用户登录的身份（达人/机构/卖家）和对应的角色等级来展示用户的logo

// 假设有这么一个基于React的logo组件
<logo role={role} level={level} />

// 假如内部的实现是这样子的
render(){
 	const { role, level } = this.props;
    if (role === '达人'){
        return <span className={a}>{level}</span>
    } else if(role === '机构'){
        return <span className={b}>{level}</span>
    } else if(role === '卖家'){
        return <span className={c}>{level}</span>
    }
}

不需要在意上述代码的细节，假设身份最后会映射到一个class类名上，并且等级的展示也会依赖于用户的身份而有所不同。这里的关键主要还是如何去抽离出这种复杂的业务逻辑，我们希望这段逻辑可以被复用，而不是耦合在这个组件的实现里面。

策略模式的定义

我们需要定义一个策略类(strategy)，每一个类都封装了一个算法用于解决相同的问题。还需要一个上下文(context)来供外部调用，传入相应的参数。

先尝试用面向对象的思维来解决问题

看一下这段代码

// 达人策略类
function InfluencerStrategy(){
}
InfluencerStrategy.prototype.getDisplayClassName = function(role){
    // 一段很复杂的逻辑之后
    return somethingComplex(role)
}
InfluencerStrategy.prototype.getDisplayLevel = function(level){
    // 一段很复杂的逻辑之后
    return somethingComplex(level)
}

// 机构策略类
function OrganizationStrategy(){

}
OrganizationStrategy.prototype.getDisplayClassName = function(role){
    // 一段很复杂的逻辑之后
    return somethingComplex(role)
}

OrganizationStrategy.prototype.getDisplayLevel = function(level){
    // 一段很复杂的逻辑之后
    return somethingComplex(level)
}

//卖家策略类
function SellerStrategy(){

}
SellerStrategy.prototype.getDisplayClassName = function(role){
    // 一段很复杂的逻辑之后
    return somethingComplex(role)
}
SellerStrategy.prototype.getDisplayLevel = function(level){
    // 一段很复杂的逻辑之后
    return somethingComplex(level)
}

function Context(role, level){
    this.role = role;
    this.level = level;
    this.roleStrategy = null;
}
Context.prototype.setRole= function(role){
    this.role = role;
}
Context.prototype.setLevel = function(level){
    this.level = level;
}
Context.prototype.setRoleStrategy = function(rs){
    this.roleStrategy = rs;
}
Context.prototype.getClass = function(){
    return this.roleStrategy.getDisplayClassName(this.role);
}
Context.prototype.getLevel = function(){
    return this.roleStrategy.getDisplayLevel(this.level);
}

const context = new Context('某个角色名称','某个等级');
context.setRoleStrategy(new SellerStrategy());
context.getClass();
context.getLevel();

context.setRole('其他的角色名称');
context.setLevel('其他的等级');
context.setRoleStrategy(new OrganizationStrategy());
context.getClass();
context.getLevel();

上述代码看起来还是蛮多的，其实逻辑十分简单。我们这里主要是关注Context上的getClass

Context.prototype.getClass = function(){
    return this.roleStrategy.getDisplayClassName(this.role);
}

可以看到他并不负责具体的算法实现，而是把这个需求委托给了内部的一个策略实例，而这里所有的策略实例都实现了getDisplayClassName这个接口。
也就是说，策略模式讲究的是算法的实现和使用是分离的，实际上上面的几个策略类完全可以导出给外部使用，这样复用性能得到很大提升。

也许函数更好

面向对象的思路确提供了一个可行的解决方案，但是在JavaScript中，其实一个简单的函数就可以封装复杂的算法，也可以导出方便外部使用，更重要的是，方便单元测试。
我们改造一下代码

const roleStrategyMap = {
    'influencer':{
        getClass:function(role){

        },
        getLevel:function(level){

        }
    },
    'organization':{
        getClass:function(role){

        },
        getLevel:function(level){

        }
    },
    'seller':{
        getClass:function(role){

        },
        getLevel:function(level){

        }
    },
};

在调用的时候只要这样

roleStrategyMap[role].getClass()

roleStrategyMap在这里就是承担context的作用，通过role最后找到委托的策略对象，调用指定的方法。

写在最后

其实这种模式在开发过程中被用到的频率十分的高，简而言之，对于所有复杂的分支结构理论上都可以利用策略模式来重新改写，但是也不能以一概全，原生的if和else也许更助于人理解业务逻辑，在实际处理过程中也要注意取舍。