參考
- 《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ) 》5.9 Strategy--對象行為型模式
- 《設(shè)計(jì)模式解析》（第二版）第九章 Strategy模式
- 《Android源碼設(shè)計(jì)模式解析與實(shí)戰(zhàn)》第七章策略模式
處理新需求的一種途徑
災(zāi)難往往是由短期未甄選最優(yōu)的決策耘拇，長期積累而引起的
在軟件開發(fā)中也是如此忘蟹，只關(guān)心眼前的事情延塑，而忽視長期問題
原因：我們確實(shí)無法預(yù)測新需求將如何變化
如果要把軟件編寫得能夠方便地添加新功能，在設(shè)計(jì)階段就永遠(yuǎn)止步不前了
客戶或老板正死死盯著我們的進(jìn)度篷角，要求立即實(shí)現(xiàn)，我們沒有時間多想倦畅。
我們以后會考慮這個問題
-
似乎就是兩種選擇：
- 過度分析或過度設(shè)計(jì)
- 一上來就扎進(jìn)細(xì)節(jié)中蹂季，編寫代碼，根本不考慮長期問題落追。
考慮變化的設(shè)計(jì)
- 針對接口進(jìn)行編程盈滴，而不要針對實(shí)現(xiàn)編程。
- 優(yōu)先使用對象組合轿钠，而不是類繼承
- 考慮設(shè)計(jì)中什么應(yīng)該是可變的巢钓，關(guān)注對變化的概念進(jìn)行封裝
例子1：國際電子商務(wù)系統(tǒng)
這個系統(tǒng)的總架構(gòu)中有一個控制器對象，用于處理銷售請求疗垛。他能夠確認(rèn)何時有人在請求銷售訂單症汹，并將請求轉(zhuǎn)發(fā)給SalesOrder對象進(jìn)行訂單處理。
SalesOrder對象的功能包括：
- 允許客戶通過GUI填寫訂單
- 處理稅額的計(jì)算
- 處理訂單贷腕，打印銷售數(shù)據(jù)
當(dāng)然這些功能可以借助其他對象去實(shí)現(xiàn)背镇，他的作用應(yīng)該是充當(dāng)一個存在銷售訂單信息的容器。
處理新的需求
比如必須處理美國之外的顧客的訂單稅額泽裳。
那么我們至少需要添加新的稅額計(jì)算規(guī)則
那么該怎樣添呢芽世？
- 復(fù)制和粘貼
一份代碼，兩個版本诡壁，維護(hù)很麻煩 - 使用switch或者if語句济瓢，用一個變量指定各種情況
如果有很多個國家呢？以后添加國家還要慢慢檢查分支妹卿，看漏掉那個國家沒有旺矾。條件復(fù)雜后蔑鹦，分支的流向也開始模糊了，反而難以閱讀和理解箕宙。 - 使用函數(shù)指針或者委托
函數(shù)指針和委托無法維持每個對象的狀態(tài)嚎朽，功能受限。 - 繼承
如果錯誤使用柬帕，繼承會使設(shè)計(jì)非常脆弱和僵化哟忍。
比如：
這種方案的困難之處在于，它這次能夠湊效陷寝，但是無法次次湊效锅很，比如，如果要處理德國訂單凤跑，或者應(yīng)對其他方面發(fā)生變化（如日期格式爆安，語言和運(yùn)費(fèi)規(guī)則），我們構(gòu)建的繼承層次將無法輕松應(yīng)對仔引。
使用策略模式方法
第一步 發(fā)現(xiàn)變化并封裝之
在本例中扔仓，已經(jīng)確定繳稅規(guī)則是變化的，“將它封裝”就應(yīng)該創(chuàng)建一個抽象類定義如何在概念上完成稅額計(jì)算咖耘，然后根據(jù)每種變化派生具體類翘簇。
第二步 組合優(yōu)先
應(yīng)該使用組合代替繼承，用組合包含變化儿倒，也就是說版保，只有一個SalesOrder類，讓它包含處理變化的CalcTax類
直接繼承方和策略模式方案比較
一個是自己直接派生處理變化义桂，另一個是包含引用指向變化，當(dāng)然是后一種好蹈垢，因?yàn)橐恍┒愵~業(yè)務(wù)規(guī)則能更好的獨(dú)立于使用自己的SalesOrder
《設(shè)計(jì)模式》中的Strategy 模式
意圖
可以根據(jù)上下文慷吊，使用不同的業(yè)務(wù)規(guī)則或算法
解釋
定義一系列的算法，把它們一個個封裝起來曹抬，并且使它們可相互替換，Strategy模式使算法可獨(dú)立于使用它的客戶而變化。
原則
- 對象都具有指責(zé)
- 這些指責(zé)不同的具體實(shí)現(xiàn)是通過多態(tài)的使用完成的
- 概念上相同的算法具有多個不同的實(shí)現(xiàn)银酗，需要進(jìn)行管理
角色
- Context 用來操作策略的上下文環(huán)境膜毁，比如上面說的Calculator類
- Stragety 策略的對象
-
ConcreteStragetyA,ConcreteStragetyB 具體的策略實(shí)現(xiàn)
策略模式UML類圖
示例代碼
public class PriceCalculator {
private Stragety stragety;
public void setStragety(Stragety stragety){
this.stragety=stragety;
}
public void calculatePrice(int km) {
int price=0;
if (stragety!=null) {
price=stragety.calculatePrice(km);
}
System.out.println(String.valueOf(price));
}
}
public class Bus implements Stragety{
@Override
public int calculatePrice(int km) {
return 3*km;
}
}
public class Subway implements Stragety{
@Override
public int calculatePrice(int km) {
return 5*km;
}
}
public class Taxi implements Stragety{
@Override
public int calculatePrice(int km) {
return 2*km;
}
}
public static void main(String[] args) {
PriceCalculator laowang=new PriceCalculator();
laowang.setStragety(new Bus());
laowang.calculatePrice(3);
laowang.setStragety(new Subway());
laowang.calculatePrice(3);
laowang.setStragety(new Taxi());
laowang.calculatePrice(3);
}
效果
使用if-else暴露的問題是代碼臃腫，邏輯復(fù)雜张足，難以升級和維護(hù)触创，沒有結(jié)構(gòu)可言；策略模式是通過建立抽象为牍，將不同的策略構(gòu)建成一個具體的策略實(shí)現(xiàn)哼绑，通過不同的策略實(shí)現(xiàn)算法替換岩馍。在簡化邏輯，結(jié)構(gòu)的同時抖韩，增強(qiáng)了系統(tǒng)的可讀性蛀恩，穩(wěn)定性，可擴(kuò)展性茂浮。
應(yīng)用例子2 Android動畫中的時間插值器
待研究
