哎，曾幾何時
想當年，其實我也特別鍾情於 if/else連環寫法，上來就是一頓sao操作，比如舉個好理解的簡單栗子：一般來說我們正常的後台管理系統都有所謂的角色的概念，不同管理員許可權不一樣，能夠行使的操作也不一樣，比如：
比如乙個使用者進來，我們需要根據不同使用者的角色來判斷其有哪些行為，這時候sao**出現了：這樣當系統裡有幾十個角色時，那幾十個 if/else巢狀可以說是非常酸爽了…… 這樣一來非常不優雅，別人閱讀起來很費勁；二來則是以後如果再複雜一點，或者想要再加條件的話不好擴充套件；而且**一改，以前的老功能肯定還得重測，豈不瘋了……所以，如果在不看下文的情況下，你一般會如何去對付這些令人頭痛的if/else語句呢？當然有人會說用 switch/case來寫是否會優雅一些呢？答案是：毛區別都沒有！
接下來簡單講幾種改進方式，別再 if/else走天下了
什麼角色能幹什麼事，這很明顯有乙個對應關係，所以學過的列舉為啥不用呢？首先定義乙個公用介面 roleoperation，表示不同角色所能做的操作：
接下來我們將不同角色的情況全部交由列舉類來做，定義乙個不同角色有不同許可權的列舉類 roleenum：
接下來呼叫就變得異常簡單了，一行**就行了， if/else也灰飛煙滅了：
而且這樣一來，以後假如我想擴充條件，只需要去列舉類中加**即可，而不是去改以前的**，這豈不很穩！
除了用列舉來消除 if/else，工廠模式也可以實現不同分支做不同的事情，很明顯就提供了使用工廠模式的契機，我們只需要將不同情況單獨定義好，然後去工廠類裡面聚合即可。首先，針對不同的角色，單獨定義其業務類：
接下來再寫乙個工廠類 rolefactory對上面不同角色進行聚合：
接下來借助上面這個工廠，業務**呼叫也只需一行**， if/else同樣被消除了：
這樣的話以後想擴充套件條件也很容易，只需要增加新**，而不需要動以前的業務**，非常符合「開閉原則」。
來，我們接著來，除了工廠模式，策略模式也不妨試一試策略模式和工廠模式寫起來其實區別也不大！在上面工廠模式**的基礎上，按照策略模式的指導思想，我們也來建立乙個所謂的策略上下文類，這裡命名為 rolecontext：
很明顯上面傳入的引數 operation就是表示不同的「策略」。我們在業務**裡傳入不同的角色，即可得到不同的操作結果：
共 勉好了，先講到這裡吧，本文僅僅是拋磚引玉，使用了乙個極其簡單的示例來打了個樣，然而其思想可以廣泛地應用於實際複雜的業務和場景，思想真的很重要！寫**前還是得多思考一番，考慮是否有更具可擴充套件性的寫法！
關於if else語句的寫法
假如現在我們的情況判斷確定只有兩種 當然未來可能會有新的情況 比如 正確和錯誤兩種狀態。我們定義正確的status值為1，錯誤的status值為2。不推薦的 寫法 public static void main string args else 應該這麼寫 public static void ma...
if else簡化之策略模式（了解）
在日常開發中，基於業務的複雜，需要對不同的場景進行判斷，每當多出一種情況，那麼又要新增一條if else，這樣讓 看起來非常的冗長以及修改起來很麻煩，剛才看到其中一種思路，應用到了設計模式中的策略模式。設計模式有20多種包括 單例，介面卡 策略 工廠 這裡僅僅是其中一種，算是我自己對剛敲的案例的理解...
用mapGetters簡化模板寫法
如果你在寫vuex 發現getter寫成所謂下面的形式 computed 你是否覺得麻煩，波利亞曾經就說過一句名言 你是否能用不同方式匯出結果，他言外之意就是你有沒有更簡單的解法，用在前端寫 上就是，你是否能用不同 風格寫出相同的效果。我在這裡簡要的為大家介紹與mapstate,mapmutatio...