很多時候會發現自己在寫**的時候寫了一坨if else 語句使得自己的**看起來很醜，隨著業務量的增大，**變得很難維護，之前想到能替換if else的只有switch，其實效果並沒有明顯的提公升，現在在看設計模式方面的知識，發現兩種設計模式能夠解決分支判斷的臃腫問題。
大家都知道超級瑪麗的遊戲吧，瑪麗要吃蘑菇，他就要挑起，頂出牆壁裡的蘑菇；瑪麗想到懸崖的另一邊，他就要跳起；瑪麗想躲避被前面的烏龜咬到，他就要開槍打死烏龜；前面飛過炮彈，瑪麗就要蹲下躲避；時間不夠了，就要加速奔跑···
如果這個遊戲要用if或者switch條件判斷，顯得有些疲憊，如果使用狀態模式將『跳躍』、『開槍』、『蹲下』和『奔跑』作為乙個個的狀態來開發，之後在遇到不同情況的時候直接使用狀態，思路將變得清晰。
首先建立乙個狀態物件，內部儲存狀態變數，然後內部封裝好每種動作對應的狀態，最後狀態物件返回乙個介面物件，它可以對內部的狀態修改或者呼叫。
**如下：
/** 超級瑪麗裡面的狀態： 跳躍、開槍、蹲下、奔跑等 */
const marrystate = function
() ;
//動作與狀態方法對映
const states =,
move() ,
shoot() ,
squat()
};//動作控制類
const action =;
if(arg.length)
}//返回動作控制類
return
this
; },
//執行動作
goes()
return
this
; }
};//返回介面方法 change、goes
return
};
使用方式：
//建立乙個超級瑪麗
const marry = new
marrystate();
marry
.change('jump','shoot') //
新增跳躍與射擊動作
.goes() //
執行動作
.goes() //
執行動作
.change('shoot') //
新增射擊動作
.goes(); //
執行動作
可以發現，狀態模式中的狀態可以連續使用。
原理：將條件判斷的不同結果轉化為物件的內部狀態，作為物件內部的私有變數。
好處：當我們需要增加、修改、呼叫、刪除某種狀態方法時就會很容易，也方便了我們對狀態物件中內部狀態的管理。
用途：狀態模式是為了解決程式中臃腫的分支判斷語句問題，將每個分支轉化為一種狀態獨立出來，方便每種狀態的管理又不至於每次執行時遍歷所有分支。
總之，狀態模式的最終目的是簡化分支判斷流程。
商品的**活動。在聖誕節，一部分商品5折**，一部分商品8折**，一部分商品9折**，等到元旦，普通使用者滿100減30，高階vip使用者滿100減50···
如果這種情況用if或switch來寫將是一件很費時費力的事情。
而且對於聖誕節或者元宵節，當天的一種商品只有一種**策略，根本不用關心其他的**狀態。
首先要將這些**演算法封裝在乙個策略物件內，然後對每種商品的策略呼叫時，直接對策略物件中的演算法呼叫即可，為方便我們的管理與使用，我們需要返回乙個呼叫介面物件來實現對策略演算法對呼叫。
**如下：
/** **策略物件 */
const pricestrategy = function
() ,
//100 返 50
return50(price) ,
//9 折
percent90(price) ,
//8 折
percent80(price) ,
//5 折
percent50(price)
};//策略演算法呼叫介面
return
function
(algorithm, price)
}();
使用方式：
const price = pricestrategy('return50', '343.20');
console.log(price);
**如下：
/** 表單正則驗證側羅物件 */
const inputstrategy = function
() ,
//是否是乙個數字
number(value) ,
//是否為本地**
phone(value) \-\d$|^\d\-\d$/.test(value);}};
return
,
//新增策略
addstrategy(type, fn)
}};
可以發現，表單驗證返回的介面中新增了乙個新增策略介面。因為已有的策略即使再多，有時候也不能滿足其他工程師的需求，這樣就可以增強策略物件的拓展性。
//拓展 可以延伸演算法
inputstrategy.addstrategy('nickname', function
(value) $/.test(value);
});
策略模式：將定義的一組演算法封裝起來，使其相互之間可以替換。
策略模式不需要管理狀態、狀態間沒有依賴關係、策略之間可以相互替換、在策略物件內部儲存的是相互獨立的一些演算法。
策略模式使得演算法脫離與模組邏輯而獨立管理，使我們可以專心研發演算法，而不必受模組邏輯所約束。
設計模式並不是很高深不可理解的一門學問，只是根據經驗把複雜的業務邏輯整理清楚，使之更容易操作化。
根據不同的業務邏輯選擇不同的設計模式有助於簡化**，也有助於**的解耦，使得**更加有效和可維護。
使用elif分支代替對映簡化設計
在python的程式設計中，字典這樣的對映程式總是可以用elif結構來代替。通常，這樣可以使得設計獲得更好的一致性。例如，之前有 如下 usr bin python class card def init self,rank,suit self.suit suit self.rank rank se...
python中的分支判斷
在python中，要構造分支結構可以使用if elif和else關鍵字，所謂的關鍵字就是有特殊含義的的單詞，像if和else就是專門用於構造分支結構的的關鍵字，很顯然你不能夠使其作為變數使用 如果非要作變數可以加一些字元進行組合使用 例子 user name input 請輸入使用者名稱 passw...
分支模式 並行軟體開發的分支模式
提到軟體配置管理模式，大家一定會想到那本書軟體配置管理模式，但是如果只是說 模式 無疑最有名的是 設計模式 的確，這些模式都有著一脈相承的關係。軟體配置管理模式這本書的主要作者是stephen p.berczuk，他在1998年時參與了chiliplop 98，在這次會議中，確立軟體配置管理模式的一...