考慮這樣乙個場景。我們要計算兩個數的值，但是演算法不確定，可以是加減乘除的任意一種，甚至可以是加減乘除任意組合計算。
就實現方式來說可以有多種。比如我可以通過if else 繼續演算法控制
class context
// public function calculate($flag)
else if($flag == '2')
else if($flag == '3')
else if($flag == '4')
return false;
}}
abstract class context
// public abstract function calculate();
}class addcontext extends context
}class subtractcontext extends context
}class multiplycontext extends context
}class dividecontext extends context
}
同時，如果要新增演算法，就需要在原來的類中修改，違反了ocp原則。而繼承這種方法暴露的問題則是
1.繼承實現會暴露一些不必要的介面，上面只是乙個calculate,如果 我如果定義方法 public a*** function(){} 。那麼這些子類是可以訪問和修改的
2.父類通常至少定義了部分子類的具體表示，因為繼承對子類揭示了其父類的具體實現，所以破壞了封裝。子類中的實現與它的父類有如此緊密的依賴關係，以至於父類實現中的任何變化必然會導致子類變化。
3.繼承無法重複利用基本的演算法，比如其他地方也要用的加減乘除的演算法。 也就是說，它們也要通過繼承，去實現加減乘除。這樣會引起類的暴增。
因為上述原因，我們需要乙個更好的方式去實現，即能減少if else的維護，又能有更好的擴充套件性，同時基本演算法還能重複利用。
而這就需要引入今天的主角---策略模式
inte***ce istrategy
//加class addstrategy implements istrategy
}//減
class subtractstrategy implements istrategy
}//乘
class multiplystrategy implements istrategy
}//除
class dividestrategy implements istrategy
}class context
public function setstrategy(istrategy $strategy)
public function calculate()
}
1.定義乙個演算法家族，這些演算法可以相互替換，而不控制演算法步驟，不依賴其他(組合，由彈性),相關演算法系列 strategy類層次為context定義了一系列的可供重用的演算法或行為
2.乙個類定義了多種行為 , 並且這些行為在這個類的操作中以多個條件語句的形式出現。
3.將相關的條件分支移入它們各自的strategy類中以代替這些條件語句
4.有乙個潛在的缺點就是乙個客戶要選擇乙個合適的strategy就必須知道這些 strategy到底有何不同。此時可能不得不向s使用者暴露具體的實現問題。因此僅當這些不同行為變體與使用者相關的行為時 , 才需要使用strategy模式增加了物件數目
設計模式學習筆記 策略模式
我覺得策略模式與工廠方法模式極其相似！策略模式 工廠方法模式 如果單從圖來看，看不出有何相似之處。但看看呼叫方法就知道了 策略模式 context context new context abstractstrategy strategy 採用哪種策略，由呼叫方決定 strategy new con...
設計模式學習筆記 策略模式
問題 商場收銀軟體，根據單價和數量，得到總價。設計思路 兩個輸入框，分別代表單價和數量，乙個下拉框，選項有 正常，打折，滿減等演算法 商場有時需要正常收費，有時打折扣，有時滿300送100.下面是簡單工廠模式下 所有演算法的父類抽象類cashsuper public abstract class c...
二 策略模式 設計模式學習筆記
1 抽象策略角色 策略類，通常由乙個介面或者抽象類實現。定義了乙個公共介面，各種不同的演算法以不同的方式實現這個介面，context使用這個介面呼叫不同的演算法，一般使用介面或抽象類實現 2 具體策略角色 包裝了相關的演算法和行為。實現了strategy定義的介面，提供具體的演算法實現 3 環境角色...