前言

傳送地址：

前端設計模式之工廠模式

前端設計模式之代理模式

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

策略模式

什么是策略模式？

策略模式的定義與特點

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

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

• 多重條件語句不易維護，而使用策略模式可以避免使用多重條件語句。
• 策略模式提供了一系列的可供重用的算法族，恰當使用繼承可以把算法族的公共代碼轉移到父類里面，從而避免重復的代碼。
• 策略模式可以提供相同行為的不同實現(xiàn)，客戶可以根據不同時間或空間要求選擇不同的。
• 策略模式提供了對開閉原則的完美支持，可以在不修改原代碼的情況下，靈活增加新算法。
• 策略模式把算法的使用放到環(huán)境類中，而算法的實現(xiàn)移到具體策略類中，實現(xiàn)了二者的分離。

其主要缺點如下：

• 客戶端必須理解所有策略算法的區(qū)別，以便適時選擇恰當的算法類。
• 策略模式造成很多的策略類。

策略模式的通俗理解

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

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

上面的??都是單條件，然而在現(xiàn)實中的很多情況會復雜的多，比如客戶會有跨越年齡、性別、生活習慣、家庭環(huán)境、個人性格等各種因素參雜在一快，所以用戶行為畫像是一個非常復雜而細致的事情，也導致我們在處理客戶喜好的時候，會出現(xiàn)多重條件干擾因素，推薦算法會比較復雜。

項目實戰(zhàn)

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

多業(yè)務場景下的訂單跳轉一直是個很頭疼的問題，因為每條業(yè)務的訂單可能需要定制，跳轉的詳情也可能不太一樣，當業(yè)務線過多的時候，很容易陷入多重條件地獄，不斷去累加判斷條件

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

如上這種，雖然是看起來條件很多但是屬于單條件，我們可以使用策略模式來簡單改造，如下所示：

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

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

orderFunction[orderType]()

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

但是我們的業(yè)務可能會更加復雜，訂單頁面我們采用了 h5 嵌入其他應用的模式，我們可能將此業(yè)務嵌入快應用、RN、原生 App、小程序、h5 等各種環(huán)境里面，展示的內容以及路由跳轉可能都不盡相同，我們?yōu)榱嗽黾与y度，更為直觀的體現(xiàn)，所以每種對應的規(guī)則都默認是完全不同的方法。

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('家具訂單小程序')
  }
}

看到上述代碼，可能人生已經絕望，因為實際中的訂單類型遠不止 3 種，環(huán)境類型也遠不止 3 種，然而還可能有更多的附件條件并沒有加上去。且越來越多的條件加入的同時，造成代碼的可讀性、可維護性、可迭代性急速下降，雖然上述代碼格式化之后，看起來倒還是很工整的。

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

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)

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

解決多重嵌套條件地獄

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

const orderType = 1 // 1: 美妝，2：電器，3：家具
const orderWay = 1 // 1：h5，2：app，3：小程序
const orderMoney = 100 // 金額范圍劃分，0-100，100-1000，1000以上，跳轉的訂單詳情也不相同

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')
        }
    }
} // 條件判斷次數太多，所以此處只用了一層條件

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

const orderType = 1 // 1: 美妝，2：電器，3：家具
const orderWay = 1 // 1：h5，2：app，3：小程序
const orderMoney = 10000 // 金額范圍劃分，0-100，100-1000，1000以上，跳轉的訂單詳情也不相同

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))

上述就是將兩個策略拆開再組合，可以使條件邏輯更加清晰，但是從上述例子也能看出，策略模式在使用過程中并不能減少很多的代碼量，并且策略越多，拆分組合的過程就會越復雜，所以的使用過程中要合理運用。

附加信息

完整的 demo 地址：項目實戰(zhàn) demo，喜歡的朋友可以 star 一下，后續(xù)會根據設計模式博文的推出，逐步的將此項目繼續(xù)拓展出來。