摘要:做前端開發已經好幾年了,對設計模式一直沒有深入學習總結過。今天第一天,首先來講策略模式。什么是策略模式四兄弟的經典設計模式中,對策略模式的定義如下定義一系列的算法,把它們一個個封裝起來,并且使它們可互相替換。
做前端開發已經好幾年了,對設計模式一直沒有深入學習總結過。隨著架構相關的工作越來越多,越來越能感覺到設計模式成為了我前進道路上的一個阻礙。所以從今天開始深入學習和總結經典的設計模式以及面向對象的幾大原則。
今天第一天,首先來講策略模式。
什么是策略模式?GoF四兄弟的經典《設計模式》中,對策略模式的定義如下:
定義一系列的算法,把它們一個個封裝起來,并且使它們可互相替換。
上邊這句話,從字面來看很簡單。但是如何在開發過程中去應用,僅憑一個定義依然是一頭霧水。以筆者曾經做過的商戶進銷存系統為例:
某超市準備舉行促銷活動,市場人員經過調查分析制定了一些促銷策略:
購物滿100減10
購物滿200減30
購物滿300減50
。。。
收銀軟件的界面是這樣的(簡單示意):
我們應該如何計算實際消費金額?
最初的實現是這樣的:
//方便起見,我們把各個促銷策略定義為枚舉值:0,1,2... var getActualTotal = function(onSaleType,originTotal){ if(onSaleType===0){ return originTotal-Math.floor(originTotal/100)*10 } if(onSaleType===1){ return originTotal-Math.floor(originTotal/200)*30 } if(onSaleType===0){ return originTotal-Math.floor(originTotal/300)*50 } } getActualTotal(1,2680); //2208
上面這段代碼很簡單,而且缺點也很明顯。隨著我的滿減策略逐漸增多,getActualTotal函數會越變越大,而且充滿了if判斷,稍一疏忽就容易弄錯。
OK,有人說我很懶,雖然這樣不夠優雅但并不影響我的使用,畢竟滿減策略再多也多不到哪去。
我只能說,需求永遠不是程序員定的。。這時,市場人員說我們新版程序添加了會員功能,我們需要支持以下的促銷策略:
會員促銷策略:
會員充300返60,且首單打9折
會員充500返100,且首單打8折
會員充1000返300,且首單打7折
...
這個時候,如果你還在原先的getActualTotal函數中繼續添加if判斷,我想如果你的領導review你這段代碼,可能會懷疑自己當初怎么把你招進來。。
OK,我們終于下定決心要重構促銷策略的代碼,我們可以這么做:
var vipPolicy_0=function(originTotal){ return originTotal-Math.floor(originTotal/100)*10 } var vipPolicy_1=function(originTotal){ return originTotal-Math.floor(originTotal/200)*30 } ... //會員充1000返300 var vipPolicy_10=function(account,originTotal){ if(account===0){ account+=1300; return originTotal*0.9 }else{ account+=1300; return originTotal; } return originTotal-Math.floor(originTotal/200)*30 } ... var vipPolicy_n=function(){ ... } var getActualTotal=function(onSaleType,originTotal,account){ switch(onSaleType){ case 0: return vipPolicy_0(originTotal); case 1: return vipPolicy_0(originTotal); ... case n: return ... default: return originTotal; } }
好了,現在我們每種策略都有自己獨立的空間了,看起來井井有條。但是還有兩個問題沒有解決:
隨著促銷策略的增加,getActualTotal的代碼量依然會越來越大
系統缺乏彈性,如果需要增加一種策略,那么除了添加一個策略函數,還需要修改switch...case..語句
讓我們再來回顧一下策略模式的定義:
定義一系列的算法,把它們一個個封裝起來,并且使它們可互相替換
在我們的例子中,每種促銷策略的實現方式是不一樣的,但我們最終的目的都是為了求得實際金額。策略模式可以把我們對促銷策略的算法一個個封裝起來,并且使它們可互相替換而不影響我們對實際金額的求值,這正好是我們所需要的。
下面我們用策略模式來重構上面的代碼:
var policies={ "Type_0":function(originTotal){ return originTotal-Math.floor(originTotal/100)*10 }, "Type_1":function(originTotal){ return originTotal-Math.floor(originTotal/200)*30 }, ... "Type_n":function(originTotal){ ... } } var getActualTotal=function(onSaleType,originTotal,account){ return policies["Type_"+onSaleType](originTotal,account) } //執行 getActualTotal(0,2680.00);//2208
分析上面的代碼我們發現,不管促銷策略如何增加,getActualTotal函數完全不需要再變化了。我們要做的,就是增加新策略的函數而已。
通過策略模式的代碼,我們消除了讓人反胃的大片條件分支語句,getActualTotal本身并沒有計算能力,而是將計算全權委托給了策略函數。
由此我們可以總結出策略模式實現的要點:
將變化的算法封裝成獨立的策略函數,并負責具體的計算
委托函數,該函數接受客戶請求,并將請求委托給某一個具體的策略函數
用一張UML圖表示如下:
怎么樣?現在看到上面這張圖是不是有了了然于胸的感覺?那就趕緊去試一試策略模式吧!
參考書籍:
《設計模式:可復用面向對象軟件的基礎》
《大話設計模式》
《Javascript設計模式與開發實踐》
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/95219.html
摘要:什么是裝飾者模式今天我們來講另外一個非常實用的設計模式裝飾者模式。就增加功能來說,裝飾者模式相比生成子類更為靈活。下面,裝飾者模式就要正式登場了。下一步,我們可以愉快的去使用裝飾者模式啦 什么是裝飾者模式 今天我們來講另外一個非常實用的設計模式:裝飾者模式。這個名字聽上去有些莫名其妙,不著急,我們先來記住它的一個別名:包裝器模式。 我們記著這兩個名字來開始今天的文章。 首先還是上《設計...
摘要:表示創建了一個,這是一條虛線,虛線從開始到結束指向了中間的框里。具體安裝參考官網文檔下載完成后打開終端運行成功運行則表示安裝成功了。 Docker這兩年非常火熱,也是各大廠必用的好東西,這兩天沒事玩了一下感覺很不錯,學起來也不難 寫下此文共勉學習。 關于Docker Docker 可理解為跑在宿主機上的非常精簡、小巧、高度濃縮的虛擬機。 它可以將容器里的進程安穩的在宿主機上運行。 Do...
showImg(https://segmentfault.com/img/bVbw3tK?w=1240&h=827); 前端工程師這個崗位,真的是反人性的 我們來思考一個問題: 一個6年左右經驗的前端工程師: 前面兩年在用jQuery 期間一直在用React-native(一步一步踩坑過來的那種) 最近兩年還在寫微信小程序 下面一個2年經驗的前端工程師: 并不會跨平臺技術,他的兩年工作都是Reac...
閱讀 1662·2019-08-30 12:51
閱讀 656·2019-08-29 17:30
閱讀 3696·2019-08-29 15:17
閱讀 852·2019-08-28 18:10
閱讀 1355·2019-08-26 17:08
閱讀 2169·2019-08-26 12:16
閱讀 3429·2019-08-26 11:47
閱讀 3497·2019-08-23 16:18