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

1.基礎(chǔ)類2.工具類

我判斷一個(gè)知識(shí)點(diǎn)屬于哪一類的主要依據(jù)有2點(diǎn)：

1.這個(gè)知識(shí)點(diǎn)是否經(jīng)久不衰;2.這個(gè)知識(shí)點(diǎn)是否沒有替代品;

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

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

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

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

相關(guān)參考:

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

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

1. 利用繼承？

階段1

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

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

階段2

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

引入新的問題：

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

而真實(shí)的情況是：橡皮鴨子 RubberDuck 不應(yīng)該會(huì) fly。

思考:

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

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

階段3

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

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

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

2.父類Duck的改動(dòng)會(huì)牽連所有子類Duck也要跟著改動(dòng)

2. 使用接口效果如何？

階段4

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

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

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

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

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

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

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

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

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

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

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

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

4. 設(shè)計(jì)鴨子的行為

階段5

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

行為的每一個(gè)具體實(shí)現(xiàn)(implementation)都會(huì)實(shí)現(xiàn)(implement) 對(duì)應(yīng)的接口：

前人的經(jīng)驗(yàn)：

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

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

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

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

這樣做有什么好處？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 測(cè)試當(dāng)前代碼

測(cè)試代碼：

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

測(cè)試效果：

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

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

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

3.模擬鴨子使用的設(shè)計(jì)模式：策略模式;

什么是策略模式？

指對(duì)象有某個(gè)行為，但是在不同的場(chǎng)景中，該行為有不同的實(shí)現(xiàn)算法。

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

2.封裝了每個(gè)算法;

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

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

6. 最后的總結(jié)

懶人們專用：

7. 更多實(shí)踐

有哪些開源項(xiàng)目使用或者借鑒了策略模式？

?Android

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

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

-END-