對于技術(shù)領(lǐng)域的知識點，我個人喜歡簡單地劃分為2類：

1.基礎類2.工具類

我判斷一個知識點屬于哪一類的主要依據(jù)有2點：

1.這個知識點是否經(jīng)久不衰;2.這個知識點是否沒有替代品;

如果上述2點都滿足，則我會認為這是基礎類知識，屬于可以長期投資的價值股; 典型的例如操作系統(tǒng)、數(shù)據(jù)結(jié)構(gòu)、Linux環(huán)境編程、軟件模式(設計模式、架構(gòu)模式...)等我會歸類為基礎類知識；

而例如 Qt、Git、Docker、甚至各種編程語言(C、C++、Java、Python)等知識點我都會暫時歸類為工具類。不要誤會，這些都只是我個人的喜好，并沒有要貶低你心愛的技術(shù)的意思，只要是你在工作里需要重度使用的技術(shù)，你都應該把它歸類為基礎類，以便提醒自己需要深耕該技術(shù)。

說了這么多，無非是想告訴你，我認為設計模式很重要，僅此而已。即便你從事的是底層軟件相關(guān)的工作，你只用 C 語言進行開發(fā)，情況也是一樣的。

下面是正文(策略模式入門)

相關(guān)參考:

?Head First Design Pattern?Android 源碼設計模式解析與實戰(zhàn)?Android Design Patterns and Best Practice關(guān)注并且后臺回復“設計模式”即可下載。

需求：
模擬現(xiàn)實生活中的鴨子，鴨子會游泳，鳴叫，飛。

1. 利用繼承？

階段1

一個父類 Duck 定義 鴨子 的一些特性，子類繼承它的特性，并覆蓋(override) 父類的部分特性。至此沒什么問題，子類共同擁有父類的特性，消除了代碼的重復性。

新的需求：
一些鴨子(例如野鴨)是會飛的，我們要讓 Duck 具有 fly() 的特性。

階段2

在 Duck 類中加上 fly() 方法：

引入新的問題：

在父類 Duck 類中增加 fly() 后，導致所有的子類鴨子都會 fly 了。

而真實的情況是：橡皮鴨子 RubberDuck 不應該會 fly。

思考:

1.對代碼的局部修改，影響層面不只是局部;

2.繼承雖然能復用代碼，但是它并不完美;

階段3

在 RubberDuck 中 override fly() 方法，方法內(nèi)什么都不做。

利用繼承來提供Duck的行為的做法，存在什么缺點？

1.大量的代碼在多個 Duck 子類中冗余，例如 RubberDuck 的 fly();

2.父類Duck的改動會牽連所有子類Duck也要跟著改動

2. 使用接口效果如何？

階段4

讓部分而非全部鴨子可飛或者可叫。

把 fly() 從父類中提取出來定義為 Flyable 接口，只有會飛的鴨子才實現(xiàn)此接口 。quack() 也類似地定義為 Quackable 接口。

例如橡皮鴨 RubberDuck 不會飛，所有它不實現(xiàn) Flyable 接口。

思考：
1.這樣避免了 “階段3” 中類似 RubberDuck->fly() 的冗余代碼，但是又造成了 fly() 毫無復用性的問題( Java 接口內(nèi)不能有代碼實現(xiàn));

2.設計原則：把會變化的部分獨立出來，不要和不需要變化的代碼混在一起(Identify the aspects of your application that vary and separate them from what stays the same.);

3.各種設計模式都有一樣的目的：把會變化的部分取出并封裝起來，以便以后輕易的改動和擴展此部分，而不影響不需要變化的其他部分;

4.軟件開發(fā)的不變真理: 軟件總是要變化的;

3. 劃分變化與不變的部分

總結(jié)前面的做法：
1.階段2: 行為 ( fly 和 quake ) 來自于 Duck 類內(nèi)具體實現(xiàn) ( concrete implementation );

2.階段4: 行為來自于繼承某個接口的子類內(nèi)的專屬實現(xiàn) ( specialized implementation );

3.無論是階段2還是階段4，都是針對具體實現(xiàn)編程。即每一種會飛的鴨子，都必須要有自己專屬的關(guān)于 fly 的具體實現(xiàn)(例如 MallarDuck->fly() / RedheadDuck->fly())，而無法共用同一類 fly 的方式(例如FlyWithWings / FlyWithRocket / FlyNoWay);

提取出變化的部分：
將會變化的鴨子的行為 ( 包括fly行為和quake行為 ) 從 Duck 類中提取出來。

4. 設計鴨子的行為

階段5

讓鴨子的行為可以動態(tài)改變：
用接口代表 ( represent ) 行為，定義2個接口：FlyBehavior and QuackBehavior。

行為的每一個具體實現(xiàn)(implementation)都會實現(xiàn)(implement) 對應的接口：

前人的經(jīng)驗：

1.設計原則：要針對接口編程，不要針對具體實現(xiàn)(implementation)編程 / Program to an interface, not an implementation;

2.這里的接口是一個“抽象概念”，并不是專門指Java 里的interface;

3.針對接口編程的另一個說法是針對超類型(supertype)編程，超類型在編程語法上一般是一個抽象類(abstract class)或者接口(interface);

實現(xiàn)鴨子的行為：

這樣做有什么好處？

1.多個行為之間相互獨立，可以輕松地添加更多的行為接口;

2.可以輕松地添加更多的行為實現(xiàn);
例如添加一個用火箭來飛行的行為：添加了一個FlyRocketPowered類，它實現(xiàn)FlyBehavior接口即可

3.具體的行為實現(xiàn)都被封裝在XXXBehavior接口內(nèi)，使用者不用關(guān)心具體的行為細節(jié);

4.行為接口 XXXBehavior 可以供其他 client 復用，例如雞;

整合鴨子的行為：
1.鴨子將飛行和叫的行為委托 (delegate) 給別人處理，而不是在 Duck 類或者子類中自己來實現(xiàn);

2.在 Duck 類中加入行為實例 xxxBehavior 和行為執(zhí)行函數(shù) performXxx();

3.實現(xiàn) performQuack();

public class Duck { QuackBehavior quackBehavior;}public void performQuack() { quackBehavior.quack();}

4.初始化行為實例變量，例如在 MallardDuck 類中：

public class MallardDuck extends Duck { public MallardDuck() { quackBehavior = new Quack(); flyBehavior = new FlyWithWings();}

這里的做法并不完美：因為 MallardDuck 的構(gòu)造函數(shù)里使用了 Quack 類 這個具體實現(xiàn)，即 MallardDuck 和 具體實現(xiàn)類 Quack 綁定在了一起。

由于xxxBehavior是可以在運行時被改變的，所以目前的做法已有足夠的彈性了，暫時不用理會構(gòu)造函數(shù)里的瑕疵。

5.允許動態(tài)地設置鴨子的行為，添加setXxxBehavior()：

public void setFlyBehavior(FlyBehavior fb) { flyBehavior = fb;}

到這里，模擬鴨子的整個設計就已經(jīng)完成了，整個設計框圖如下：

5. 測試當前代碼

測試代碼：

public class MiniDuckSimulator { public static void main(String[] args) { Duck mallard = new MallardDuck(); mallard.performQuack(); mallard.performFly(); mallard.setFlyBehavior(new FlyRocketPowered()); mallard.performFly(); }}

測試效果：

%java MiniDuckSimulatorQuackI’m flying!!I'm flying with a rocker

根據(jù)測試結(jié)果總結(jié)一下：
1."有1個"比“是1個”更好，鴨子的行為不是繼承來的，而是和行為對象組合而來;

2.設計原則：多用組合，少用繼承(Favor composition over inheritance);

3.模擬鴨子使用的設計模式：策略模式;

什么是策略模式？

指對象有某個行為，但是在不同的場景中，該行為有不同的實現(xiàn)算法。

策略模式三要素：
1.定義了一族算法（業(yè)務規(guī)則）;

2.封裝了每個算法;

3.這族的算法可互換代替（interchangeable）;

再舉一個例子：
在一款游戲里，有不同的角色(國王、皇后、騎士...)，角色有不同的武器(斧頭、劍、刀)，該怎么設計？

6. 最后的總結(jié)

懶人們專用：

7. 更多實踐

有哪些開源項目使用或者借鑒了策略模式？

?Android

還等什么？趕緊分析起來吧~~

本文授權(quán)轉(zhuǎn)載自公眾號“嵌入式系統(tǒng)磚家”，作者可愛的東東

-END-