策略模式原理篇

當我們寫**時總會遇到一種情況，就是我們會有很多的選擇，由此衍生出很多的if…else，或者case。如果每個條件語句中包含了乙個簡單的邏輯，那還比較容易處理；但如果在乙個條件語句中又包含了多個條件語句，就會使得**變得臃腫，維護的成本也會加大，這顯然違背了開放封閉原則。

public void pay(string paytype)  else if ("aili".equals(paytype))  else if ("yinhangcard".equals(paytype))  else 
}

若是邏輯簡單的話還好，邏輯複雜的話會有較為明顯的問題：

if...else...多層巢狀，如果內部有更多的邏輯，巢狀會非常複雜；

如果又新增了更多的支付方式的話，pay的**還要修改，無法對程式進行很好的擴充套件。

因此為了較好的擴充套件程式，我們應該針對介面程式設計，而不是針對實現程式設計。那麼我們使用策略模式來解決上述寫法所面臨的問題：

行為介面：

public inte***ce payment

具體的支付方式：

public class weixinpay implements payment
}

public class alipay implements payment 
}

外界和具體策略進行連線的設定類（引數是具體的實現）：

public class shopcart 
public void pay(string price) 
}

用來操作策略的上下文環境，起到承上啟下的作用，遮蔽高層模組對策略、演算法的直接訪問，在這裡我們需要知道針對不同的情況使用哪種策略行為，這裡就是原來的巢狀的多層if...else...的地方，現在我們只需要在不同的情況下使用不同的策略即可：

shopcart shopcartweinxin = new shopcart(new weixinpay());
shopcartweinxin.pay("22");
shopcart shopcartali = new shopcart(new alipay());
shopcartali.pay("33");

採用策略模式後，當新增支付方式時，只需要實現乙個繼承payment介面的類即可，shopcart類不需要做任何改動，做到了對修改關閉，對擴充套件開放的原則，同時也做到針對介面程式設計，而不是針對實現程式設計的設計原則。其實真正的專案中，shopcart是個很複雜的類，裡面會有很多業務邏輯，在新增業務不改動舊邏輯，會增加專案的穩定性，也減少測試的工作投入。

原始碼中所使用策略模式：

乙個整體的簡單示例：

inte***ce mathalgorithm 
class mathadd implements mathalgorithm
}class mathsubstract implements mathalgorithm
}class mathmultiply implements mathalgorithm
}class mathcontext 
public int execute(int num1, int num2)
}public class main 
}

策略模式原理篇

倒車雷達原理篇

iOS知識原理篇

MongoDB分片原理篇

策略模式原理篇

倒車雷達原理篇

iOS知識原理篇

MongoDB分片原理篇

相關推薦