策略 想法 函數接口 易維 例如 www 設計思路 interface con

策略模式： 它定義了算法家族，分別封裝起來，讓它們之間可以相到替換，此模式用算法的變化不會影響到其它的客戶。

---

此模式還是其實就是我們平常寫的代碼，其實設計模式就是告訴你如何寫代碼罷了，並不是什麽搬來就可以用的方案，如果是這樣，為鳥不直接寫在庫作框架調用就得了，因為它僅僅提供一種解決方案。它只是告訴你有與它相似需求的時候，代碼該怎麽寫。這樣寫出來的代碼它的擴展性好，容易維護，類之間的耦合度低。

---

策略模式迎合了幾個面向對象的設計思想： 1、找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。 2、多用組合，少用繼承。 3、針對接口而不是實現編程。

---

引用《Head First 設計模式》中的例子： 假如我們要設一個鴨子類： 那麽一般的想法就是： 在基類中，有fly(),swim(),quack()這些函數接口，然後在子類中只要實現這些接口就行了。但是問題來了，例如我們要實現一個“旱鴨子”和“橡皮鴨”。你會發現，感覺在設計上邏輯有點不太對了，像皮鴨會叫嗎？它會有quack()或者fly()函數接口嗎？而旱鴨子會有swim()方法？這些肯定是不對的。 問題在於這種設計思路不太符合： 2、多用組合，少用繼承。 原則，都用繼承就沒有那麽靈活了。
或者你會這麽設計： 這樣也許是個好設計，把fly()和swim單獨弄出來作一個類，然後單獨繼承，這樣設計倒是符合： 1、找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。 但是Acton類本來應該也是Duck該有的，Action應該是屬於Duck類。單獨分開來繼承，可能實現上沒有太大的影響 ，但是從邏輯上好像也不太好，好像有人非得把你“五馬分屍”。
所以總結下，這麽設計： 也就是將Action作為Duck的成員，再在它自己的方法中調用Action中的接口。

1. voidDuck::peformfly(){
2. this->action.fly();
3. }

---

上面的框圖的，代碼實現。

1. #include<iostream>
2. #include<string>
4. classStratery{
5. public:
6. Stratery
   (){
8. }
9. virtualvoidAlgorithmInterface(){
10. std::cout<<"AlgorithmInterface"<<std::endl;
11. }
12. };
13. classConcreteStrateryA:publicStratery{
14. public:
15. virtualvoidAlgorithmInterface(){
16. std::cout<<"ConcreteStrateryA"<<std::endl;
17. }
18. };
20. classConcreteStrateryB:publicStratery{
21. public:
22. virtualvoidAlgorithmInterface(){
23. std::cout<<"ConcreteStrateryB"<<std::endl;
24. }
25. };
26. classConcreteStrateryC:publicStratery{
27. public:
28. virtualvoidAlgorithmInterface(){
29. std::cout<<"ConcreteStrateryC"<<std::endl;
30. }
31. };
32. classContext{
33. private:
34. Stratery*stratery;
35. public:
36. Context(Stratery*_stratery):stratery(_stratery){
38. }
39. voidContextInterface(){
40. stratery->AlgorithmInterface();
41. }
42. };
44. int main(){
45. Context contextA(newConcreteStrateryA());
46. contextA.ContextInterface();
47. Context contextB(newConcreteStrateryB());
48. contextB.ContextInterface();
49. Context contextC(newConcreteStrateryB());
50. contextC.ContextInterface();
51. }

---

上面的實現，就是使用了策略模式的經典用法。 其中：

1. ConcreteStrateryA

1. ConcreteStrateryB

1. ConcreteStrateryC

就是算法家族。這些算法之間是沒有耦合的。這也是策略模式的要點之一。 可以說，策略模式就是用來封裝算法，但是也可以擴展到所有其它與之要求相似的類。例如前面的Duck類，那麽Duck類中封裝的算法就是 Action了。

null

C++策略模式