前言

傳送地址：

前端設(shè)計(jì)模式之工廠模式

前端設(shè)計(jì)模式之代理模式

設(shè)計(jì)模式已經(jīng)到了第三篇抖苦，前兩篇分別是代理模式與工廠模式层宫，那么繼續(xù)我們 23 篇設(shè)計(jì)模式的鏈路-策略模式。

策略模式

什么是策略模式？

策略模式的定義與特點(diǎn)

策略（Strategy）模式的定義：該模式定義了一系列算法，并將每個(gè)算法封裝起來笨使，使它們可以相互替換，且算法的變化不會(huì)影響使用算法的客戶。策略模式屬于對象行為模式辉词，它通過對算法進(jìn)行封裝，把使用算法的責(zé)任和算法的實(shí)現(xiàn)分割開來猾骡，并委派給不同的對象對這些算法進(jìn)行管理瑞躺。此什么是策略模式處引用了 gof 設(shè)計(jì)模式的描述。

策略模式的主要優(yōu)點(diǎn)如下：

• 多重條件語句不易維護(hù)卓练，而使用策略模式可以避免使用多重條件語句隘蝎。
• 策略模式提供了一系列的可供重用的算法族，恰當(dāng)使用繼承可以把算法族的公共代碼轉(zhuǎn)移到父類里面襟企，從而避免重復(fù)的代碼嘱么。
• 策略模式可以提供相同行為的不同實(shí)現(xiàn)，客戶可以根據(jù)不同時(shí)間或空間要求選擇不同的顽悼。
• 策略模式提供了對開閉原則的完美支持曼振，可以在不修改原代碼的情況下，靈活增加新算法蔚龙。
• 策略模式把算法的使用放到環(huán)境類中冰评，而算法的實(shí)現(xiàn)移到具體策略類中，實(shí)現(xiàn)了二者的分離木羹。

其主要缺點(diǎn)如下：

• 客戶端必須理解所有策略算法的區(qū)別甲雅，以便適時(shí)選擇恰當(dāng)?shù)乃惴悺?/li>
• 策略模式造成很多的策略類。

策略模式的通俗理解

接著我們寵物店的??坑填，我們除了招代理商之外抛人，還可以引入互聯(lián)網(wǎng)的大數(shù)據(jù)分析得出我們定向推薦的客戶類型，提高服務(wù)質(zhì)量

客戶描述	寵物推薦	寵物照片
兒童客戶：主要推薦一些比較乖巧脐瑰，攻擊性不高的小型犬	柴犬	image
女性客戶：主要推薦一些顏值較高的小型犬	薩摩耶妖枚，吉娃娃	image
頭鐵客戶：主要推薦一些特別折騰的，真的勇士型寵物	哈士奇	image

上面的??都是單條件苍在，然而在現(xiàn)實(shí)中的很多情況會(huì)復(fù)雜的多绝页，比如客戶會(huì)有跨越年齡、性別寂恬、生活習(xí)慣续誉、家庭環(huán)境、個(gè)人性格等各種因素參雜在一快初肉，所以用戶行為畫像是一個(gè)非常復(fù)雜而細(xì)致的事情屈芜，也導(dǎo)致我們在處理客戶喜好的時(shí)候，會(huì)出現(xiàn)多重條件干擾因素，推薦算法會(huì)比較復(fù)雜井佑。

項(xiàng)目實(shí)戰(zhàn)

解決多重條件業(yè)務(wù)

多業(yè)務(wù)場景下的訂單跳轉(zhuǎn)一直是個(gè)很頭疼的問題属铁，因?yàn)槊織l業(yè)務(wù)的訂單可能需要定制，跳轉(zhuǎn)的詳情也可能不太一樣躬翁，當(dāng)業(yè)務(wù)線過多的時(shí)候焦蘑，很容易陷入多重條件地獄，不斷去累加判斷條件

const orderType = 1 // 1: 美妝盒发，2：電器例嘱，3：家具
if (orderType === 1) {
  console.log('美妝訂單')  // 簡單是用打印方法來舉例，實(shí)際可以當(dāng)做每個(gè)訂單條件跳轉(zhuǎn)宁舰、展示的操作都不一樣
} else if (orderType === 2) {
  console.log('電器訂單')
} else if (orderType === 3) {
  console.log('家具訂單')
} 

如上這種拼卵，雖然是看起來?xiàng)l件很多但是屬于單條件，我們可以使用策略模式來簡單改造蛮艰，如下所示：

const orderType = 1 // 1: 美妝腋腮，2：電器，3：家具

const orderFunction = {
  1() { console.log('美妝訂單') },
  2() { console.log('電器訂單') },
  3() { console.log('家具訂單') },
}

orderFunction[orderType]()

解決多重嵌套條件業(yè)務(wù)

但是我們的業(yè)務(wù)可能會(huì)更加復(fù)雜壤蚜，訂單頁面我們采用了 h5 嵌入其他應(yīng)用的模式即寡，我們可能將此業(yè)務(wù)嵌入快應(yīng)用、RN袜刷、原生 App聪富、小程序、h5 等各種環(huán)境里面著蟹，展示的內(nèi)容以及路由跳轉(zhuǎn)可能都不盡相同墩蔓，我們?yōu)榱嗽黾与y度，更為直觀的體現(xiàn)萧豆，所以每種對應(yīng)的規(guī)則都默認(rèn)是完全不同的方法奸披。

const orderType = 1 // 1: 美妝，2：電器炕横，3：家具
const orderWay = 1 // 1：h5源内，2：app葡粒，3：小程序

if (orderType === 1) {
  if (orderWay === 1) {
    console.log('美妝訂單h5')
  } else if (orderWay === 2) {
    console.log('美妝訂單app')
  } else if (orderWay === 3) {
    console.log('美妝訂單小程序')
  }
} else if (orderType === 2) {
  if (orderWay === 1) {
    console.log('電器訂單h5')
  } else if (orderWay === 2) {
    console.log('電器訂單app')
  } else if (orderWay === 3) {
    console.log('電器訂單小程序')
  }
} else if (orderType === 3) {
  if (orderWay === 1) {
    console.log('家具訂單h5')
  } else if (orderWay === 2) {
    console.log('家具訂單app')
  } else if (orderWay === 3) {
    console.log('家具訂單小程序')
  }
}

看到上述代碼份殿，可能人生已經(jīng)絕望，因?yàn)閷?shí)際中的訂單類型遠(yuǎn)不止 3 種嗽交，環(huán)境類型也遠(yuǎn)不止 3 種卿嘲，然而還可能有更多的附件條件并沒有加上去。且越來越多的條件加入的同時(shí)夫壁，造成代碼的可讀性拾枣、可維護(hù)性、可迭代性急速下降，雖然上述代碼格式化之后梅肤，看起來倒還是很工整的司蔬。

雖然上述是多重嵌套條件，但拆分開來還是可以理解為訂單類型跟環(huán)境類型的組合姨蝴，我們借助 es6 map 對象來進(jìn)行改造

const orderType = 1 // 1: 美妝俊啼，2：電器，3：家具
const orderWay = 2 // 1：h5左医，2：app授帕，3：小程序

const strategy = () => { // 訂單類型+環(huán)境類型策略
  const map = new Map([
    [{
      orderType: 1,
      orderWay: 1
    }, () => {
      console.log('美妝訂單h5')
    }],
    [{
      orderType: 1,
      orderWay: 2
    }, () => {
      console.log('美妝訂單app')
    }],
    [{
      orderType: 1,
      orderWay: 3
    }, () => {
      console.log('美妝訂單小程序')
    }],
    [{
      orderType: 2,
      orderWay: 1
    }, () => {
      console.log('電器訂單h5')
    }],
    [{
      orderType: 2,
      orderWay: 2
    }, () => {
      console.log('電器訂單app')
    }],
    [{
      orderType: 2,
      orderWay: 3
    }, () => {
      console.log('電器訂單小程序')
    }],
    [{
      orderType: 3,
      orderWay: 1
    }, () => {
      console.log('家具訂單h5')
    }],
    [{
      orderType: 3,
      orderWay: 2
    }, () => {
      console.log('家具訂單app')
    }],
    [{
      orderType: 3,
      orderWay: 3
    }, () => {
      console.log('家具訂單小程序')
    }],
  ])
  return map
}

const run = (orderType, orderWay) => {
  let action = [...strategy()].filter(([key, value]) => (key.orderType === orderType && key.orderWay === orderWay))
  action.forEach(([key, value]) => value.call(this))
}

run(orderType, orderWay)

如上述重構(gòu)后的，我們借助 map 對象的特性（此處不對 map 對象做更深的拓展講解）浮梢。如果再有新增的規(guī)則跛十，我們可以放在 map 里面進(jìn)行新增對應(yīng)規(guī)則與方法，減少條件嵌套地獄出現(xiàn)秕硝，并且邏輯會(huì)更加清晰芥映。但實(shí)際情況中還可以對類似的方法進(jìn)行合并，邏輯會(huì)更加清晰缝裤。

解決多重嵌套條件地獄

上述的多種嵌套條件的解決方案是比較簡單的屏轰，現(xiàn)實(shí)中很難有這么完美的條件判斷出現(xiàn)。接下來見證一下什么叫地獄的風(fēng)景

const orderType = 1 // 1: 美妝憋飞，2：電器霎苗，3：家具
const orderWay = 1 // 1：h5，2：app榛做，3：小程序
const orderMoney = 100 // 金額范圍劃分唁盏，0-100，100-1000检眯，1000以上厘擂，跳轉(zhuǎn)的訂單詳情也不相同

if (orderType === 1) {
    if (orderWay === 1) {
        if (0 <= orderMoney && orderMoney < 100) {
            console.log('美妝訂單h5-0')
        } else if (orderMoney < 1000) {
            console.log('美妝訂單h5-100')
        } else {
            console.log('美妝訂單h5-1000')
        }
    } else if (orderWay === 2) {
        if (0 <= orderMoney && orderMoney < 100) {
            console.log('美妝訂單app-0')
        } else if (orderMoney < 1000) {
            console.log('美妝訂單app-100')
        } else {
            console.log('美妝訂單app-1000')
        }
    } else if (orderWay === 3) {
        if (0 <= orderMoney && orderMoney < 100) {
            console.log('美妝訂單小程序-0')
        } else if (orderMoney < 1000) {
            console.log('美妝訂單小程序-100')
        } else {
            console.log('美妝訂單小程序-1000')
        }
    }
} // 條件判斷次數(shù)太多，所以此處只用了一層條件

我們來簡單分析一下上述的條件锰瘸，可以將相同的策略提取出來刽严。首先環(huán)境跟訂單類型的組合可以默認(rèn)已知，所以將金額條件提取出來避凝，當(dāng)作一組策略返回

const orderType = 1 // 1: 美妝舞萄，2：電器，3：家具
const orderWay = 1 // 1：h5管削，2：app倒脓，3：小程序
const orderMoney = 10000 // 金額范圍劃分，0-100含思，100-1000崎弃，1000以上甘晤，跳轉(zhuǎn)的訂單詳情也不相同

const orderMoneyStrategy = (orderMoney) => { // 提取金額策略
    if (0 <= orderMoney && orderMoney < 100) {
        return 1
    } else if (orderMoney < 1000) {
        return 2
    }
    return 3
}

const strategy = () => { // 訂單類型+環(huán)境類型策略
    const map = new Map([
        [{
            orderType: 1,
            orderWay: 1,
            orderMoney: 1
        }, () => {
            console.log('美妝訂單h5-0')
        }],
        [{
            orderType: 1,
            orderWay: 1,
            orderMoney: 2
        }, () => {
            console.log('美妝訂單h5-100')
        }],
        [{
            orderType: 1,
            orderWay: 1,
            orderMoney: 3
        }, () => {
            console.log('美妝訂單h5-1000')
        }],
    ])
    return map
}

const run = (orderType, orderWay, orderMoney) => {
    let action = [...strategy()].filter(([key, value]) => (key.orderType === orderType && key.orderWay === orderWay && key.orderMoney === orderMoney))
    action.forEach(([key, value]) => value.call(this))
}

run(orderType, orderWay, orderMoneyStrategy(orderMoney))

上述就是將兩個(gè)策略拆開再組合，可以使條件邏輯更加清晰饲做，但是從上述例子也能看出线婚，策略模式在使用過程中并不能減少很多的代碼量，并且策略越多盆均，拆分組合的過程就會(huì)越復(fù)雜酌伊，所以的使用過程中要合理運(yùn)用。

附加信息

完整的 demo 地址：項(xiàng)目實(shí)戰(zhàn) demo缀踪，喜歡的朋友可以 star 一下居砖，后續(xù)會(huì)根據(jù)設(shè)計(jì)模式博文的推出，逐步的將此項(xiàng)目繼續(xù)拓展出來驴娃。