萬字圖文詳解24種設(shè)計(jì)模式

我們發(fā)現(xiàn)沒有，代理模式說白了就是做 “方法包裝” 或做 “方法增強(qiáng)”。在面向切面編程中，其實(shí)就是動(dòng)態(tài)代理的過程。比如 Spring 中，我們自己不定義代理類，但是 Spring 會(huì)幫我們動(dòng)態(tài)來定義代理，然后把我們定義在 @Before、@After、@Around 中的代碼邏輯動(dòng)態(tài)添加到代理中。

說到動(dòng)態(tài)代理，又可以展開說，Spring 中實(shí)現(xiàn)動(dòng)態(tài)代理有兩種，一種是如果我們的類定義了接口，如 UserService 接口和 UserServiceImpl 實(shí)現(xiàn)，那么采用 JDK 的動(dòng)態(tài)代理，感興趣的讀者可以去看看 java.lang.reflect.Proxy 類的源碼；另一種是我們自己沒有定義接口的，Spring 會(huì)采用 CGLIB 進(jìn)行動(dòng)態(tài)代理，它是一個(gè) jar 包，性能還不錯(cuò)。

適配器模式

說完代理模式，說適配器模式，是因?yàn)樗鼈兒芟嗨疲@里可以做個(gè)比較。

適配器模式做的就是，有一個(gè)接口需要實(shí)現(xiàn)，但是我們現(xiàn)成的對(duì)象都不滿足，需要加一層適配器來進(jìn)行適配。

適配器模式總體來說分三種：默認(rèn)適配器模式、對(duì)象適配器模式、類適配器模式。先不急著分清楚這幾個(gè)，先看看例子再說。

默認(rèn)適配器模式

首先，我們先看看最簡(jiǎn)單的適配器模式**默認(rèn)適配器模式(Default Adapter)**是怎么樣的。

我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對(duì)文件或文件夾進(jìn)行監(jiān)控，一旦發(fā)生了對(duì)應(yīng)的操作，就會(huì)觸發(fā)相應(yīng)的方法。

public?interface?FileAlterationListener?{
????void?onStart(final?FileAlterationObserver?observer);
????void?onDirectoryCreate(final?File?directory);
????void?onDirectoryChange(final?File?directory);
????void?onDirectoryDelete(final?File?directory);
????void?onFileCreate(final?File?file);
????void?onFileChange(final?File?file);
????void?onFileDelete(final?File?file);
????void?onStop(final?FileAlterationObserver?observer);
}

此接口的一大問題是抽象方法太多了，如果我們要用這個(gè)接口，意味著我們要實(shí)現(xiàn)每一個(gè)抽象方法，如果我們只是想要監(jiān)控文件夾中的文件創(chuàng)建和文件刪除事件，可是我們還是不得不實(shí)現(xiàn)所有的方法，很明顯，這不是我們想要的。

所以，我們需要下面的一個(gè)適配器，它用于實(shí)現(xiàn)上面的接口，但是所有的方法都是空方法，這樣，我們就可以轉(zhuǎn)而定義自己的類來繼承下面這個(gè)類即可。

public?class?FileAlterationListenerAdaptor?implements?FileAlterationListener?{

????public?void?onStart(final?FileAlterationObserver?observer)?{
????}

????public?void?onDirectoryCreate(final?File?directory)?{
????}

????public?void?onDirectoryChange(final?File?directory)?{
????}

????public?void?onDirectoryDelete(final?File?directory)?{
????}

????public?void?onFileCreate(final?File?file)?{
????}

????public?void?onFileChange(final?File?file)?{
????}

????public?void?onFileDelete(final?File?file)?{
????}

????public?void?onStop(final?FileAlterationObserver?observer)?{
????}
}

比如我們可以定義以下類，我們僅僅需要實(shí)現(xiàn)我們想實(shí)現(xiàn)的方法就可以了：

public?class?FileMonitor?extends?FileAlterationListenerAdaptor?{
????public?void?onFileCreate(final?File?file)?{
????????//?文件創(chuàng)建
????????doSomething();
????}

????public?void?onFileDelete(final?File?file)?{
????????//?文件刪除
????????doSomething();
????}
}

當(dāng)然，上面說的只是適配器模式的其中一種，也是最簡(jiǎn)單的一種，無需多言。下面，再介紹**“正統(tǒng)的”**適配器模式。

對(duì)象適配器模式

來看一個(gè)《Head First 設(shè)計(jì)模式》中的一個(gè)例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當(dāng)鴨來用。因?yàn)椋F(xiàn)在鴨這個(gè)接口，我們沒有合適的實(shí)現(xiàn)類可以用，所以需要適配器。

public?interface?Duck?{
????public?void?quack();?//?鴨的呱呱叫
????public?void?fly();?//?飛
}

public?interface?Cock?{
????public?void?gobble();?//?雞的咕咕叫
????public?void?fly();?//?飛
}

public?class?WildCock?implements?Cock?{
????public?void?gobble()?{
????????System.out.println("咕咕叫");
????}
????public?void?fly()?{
????????System.out.println("雞也會(huì)飛哦");
????}
}

鴨接口有 fly() 和 quare() 兩個(gè)方法，雞 Cock 如果要冒充鴨，fly() 方法是現(xiàn)成的，但是雞不會(huì)鴨的呱呱叫，沒有 quack() 方法。這個(gè)時(shí)候就需要適配了：

//?毫無疑問，首先，這個(gè)適配器肯定需要?implements?Duck，這樣才能當(dāng)做鴨來用
public?class?CockAdapter?implements?Duck?{
??
????Cock?cock;
????//?構(gòu)造方法中需要一個(gè)雞的實(shí)例，此類就是將這只雞適配成鴨來用
???public?CockAdapter(Cock?cock)?{
????????this.cock?=?cock;
????}
??
????//?實(shí)現(xiàn)鴨的呱呱叫方法
????@Override
???public?void?quack()?{
????????//?內(nèi)部其實(shí)是一只雞的咕咕叫
????????cock.gobble();
????}
??
???@Override
???public?void?fly()?{
????????cock.fly();
????}
}

客戶端調(diào)用很簡(jiǎn)單了：

public?static?void?main(String[]?args)?{
????//?有一只野雞
???Cock?wildCock?=?new?WildCock();
???//?成功將野雞適配成鴨
???Duck?duck?=?new?CockAdapter(wildCock);
???...
}

到這里，大家也就知道了適配器模式是怎么回事了。無非是我們需要一只鴨，但是我們只有一只雞，這個(gè)時(shí)候就需要定義一個(gè)適配器，由這個(gè)適配器來充當(dāng)鴨，但是適配器里面的方法還是由雞來實(shí)現(xiàn)的。

我們用一個(gè)圖來簡(jiǎn)單說明下：

上圖應(yīng)該還是很容易理解的，我就不做更多的解釋了。下面，我們看看類適配模式怎么樣的。

類適配器模式

廢話少說，直接上圖：

看到這個(gè)圖，大家應(yīng)該很容易理解的吧，通過繼承的方法，適配器自動(dòng)獲得了所需要的大部分方法。這個(gè)時(shí)候，客戶端使用更加簡(jiǎn)單，直接 Target t = new SomeAdapter(); 就可以了。

適配器模式總結(jié)

1. 類適配和對(duì)象適配的異同

   ★

   一個(gè)采用繼承，一個(gè)采用組合；

   類適配屬于靜態(tài)實(shí)現(xiàn)，對(duì)象適配屬于組合的動(dòng)態(tài)實(shí)現(xiàn)，對(duì)象適配需要多實(shí)例化一個(gè)對(duì)象。

   總體來說，對(duì)象適配用得比較多。

   ”

2. 適配器模式和代理模式的異同

   比較這兩種模式，其實(shí)是比較對(duì)象適配器模式和代理模式，在代碼結(jié)構(gòu)上，它們很相似，都需要一個(gè)具體的實(shí)現(xiàn)類的實(shí)例。但是它們的目的不一樣，代理模式做的是增強(qiáng)原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當(dāng)做鴨來使用”，而雞和鴨它們之間原本沒有繼承關(guān)系。

   adapter-5

橋梁模式

理解橋梁模式，其實(shí)就是理解代碼抽象和解耦。

我們首先需要一個(gè)橋梁，它是一個(gè)接口，定義提供的接口方法。

public?interface?DrawAPI?{
???public?void?draw(int?radius,?int?x,?int?y);
}

然后是一系列實(shí)現(xiàn)類：

public?class?RedPen?implements?DrawAPI?{
????@Override
????public?void?draw(int?radius,?int?x,?int?y)?{
????????System.out.println("用紅色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
????}
}
public?class?GreenPen?implements?DrawAPI?{
????@Override
????public?void?draw(int?radius,?int?x,?int?y)?{
????????System.out.println("用綠色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
????}
}
public?class?BluePen?implements?DrawAPI?{
????@Override
????public?void?draw(int?radius,?int?x,?int?y)?{
????????System.out.println("用藍(lán)色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
????}
}

定義一個(gè)抽象類，此類的實(shí)現(xiàn)類都需要使用 DrawAPI：

public?abstract?class?Shape?{
????protected?DrawAPI?drawAPI;
????protected?Shape(DrawAPI?drawAPI)?{
????????this.drawAPI?=?drawAPI;
????}
????public?abstract?void?draw();
}

定義抽象類的子類：

//?圓形
public?class?Circle?extends?Shape?{
????private?int?radius;
????public?Circle(int?radius,?DrawAPI?drawAPI)?{
????????super(drawAPI);
????????this.radius?=?radius;
????}
????public?void?draw()?{
????????drawAPI.draw(radius,?0,?0);
????}
}
//?長(zhǎng)方形
public?class?Rectangle?extends?Shape?{
????private?int?x;
????private?int?y;
????public?Rectangle(int?x,?int?y,?DrawAPI?drawAPI)?{
????????super(drawAPI);
????????this.x?=?x;
????????this.y?=?y;
????}
????public?void?draw()?{
????????drawAPI.draw(0,?x,?y);
????}
}

最后，我們來看客戶端演示：

public?static?void?main(String[]?args)?{
????Shape?greenCircle?=?new?Circle(10,?new?GreenPen());
????Shape?redRectangle?=?new?Rectangle(4,?8,?new?RedPen());
????greenCircle.draw();
????redRectangle.draw();
}

可能大家看上面一步步還不是特別清晰，我把所有的東西整合到一張圖上：

這回大家應(yīng)該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優(yōu)點(diǎn)也是顯而易見的，就是非常容易進(jìn)行擴(kuò)展。

★

本節(jié)引用了這里的例子，并對(duì)其進(jìn)行了修改。

”

裝飾模式

要把裝飾模式說清楚明白，不是件容易的事情。也許讀者知道 Java IO 中的幾個(gè)類是典型的裝飾模式的應(yīng)用，但是讀者不一定清楚其中的關(guān)系，也許看完就忘了，希望看完這節(jié)后，讀者可以對(duì)其有更深的感悟。

首先，我們先看一個(gè)簡(jiǎn)單的圖，看這個(gè)圖的時(shí)候，了解下層次結(jié)構(gòu)就可以了：

我們來說說裝飾模式的出發(fā)點(diǎn)，從圖中可以看到，接口 Component 其實(shí)已經(jīng)有了 ConcreteComponentA 和 ConcreteComponentB 兩個(gè)實(shí)現(xiàn)類了，但是，如果我們要增強(qiáng)這兩個(gè)實(shí)現(xiàn)類的話，我們就可以采用裝飾模式，用具體的裝飾器來裝飾實(shí)現(xiàn)類，以達(dá)到增強(qiáng)的目的。

★

從名字來簡(jiǎn)單解釋下裝飾器。既然說是裝飾，那么往往就是添加小功能這種，而且，我們要滿足可以添加多個(gè)小功能。最簡(jiǎn)單的，代理模式就可以實(shí)現(xiàn)功能的增強(qiáng)，但是代理不容易實(shí)現(xiàn)多個(gè)功能的增強(qiáng)，當(dāng)然你可以說用代理包裝代理的多層包裝方式，但是那樣的話代碼就復(fù)雜了。

”

首先明白一些簡(jiǎn)單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator* 都可以作為 Component 來使用，因?yàn)樗鼈兌紝?shí)現(xiàn)了 Component 中的所有接口。它們和 Component 實(shí)現(xiàn)類 ConcreteComponent* 的區(qū)別是，它們只是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都只是在具體的實(shí)現(xiàn)中加了層皮來裝飾而已。

★

注意這段話中混雜在各個(gè)名詞中的 Component 和 Decorator，別搞混了。

”

下面來看看一個(gè)例子，先把裝飾模式弄清楚，然后再介紹下 java io 中的裝飾模式的應(yīng)用。

最近大街上流行起來了“快樂檸檬”，我們把快樂檸檬的飲料分為三類：紅茶、綠茶、咖啡，在這三大類的基礎(chǔ)上，又增加了許多的口味，什么金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很長(zhǎng)的菜單，但是仔細(xì)看下，其實(shí)原料也沒幾樣，但是可以搭配出很多組合，如果顧客需要，很多沒出現(xiàn)在菜單中的飲料他們也是可以做的。

在這個(gè)例子中，紅茶、綠茶、咖啡是最基礎(chǔ)的飲料，其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當(dāng)然，在開發(fā)中，我們確實(shí)可以像門店一樣，開發(fā)這些類：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......但是，很快我們就發(fā)現(xiàn)，這樣子干肯定是不行的，這會(huì)導(dǎo)致我們需要組合出所有的可能，而且如果客人需要在紅茶中加雙份檸檬怎么辦？三份檸檬怎么辦？

不說廢話了，上代碼。

首先，定義飲料抽象基類：

public?abstract?class?Beverage?{
???//?返回描述
???public?abstract?String?getDescription();
???//?返回價(jià)格
???public?abstract?double?cost();
}

然后是三個(gè)基礎(chǔ)飲料實(shí)現(xiàn)類，紅茶、綠茶和咖啡：

public?class?BlackTea?extends?Beverage?{
???public?String?getDescription()?{
????????return?"紅茶";
????}
???public?double?cost()?{
????????return?10;
????}
}
public?class?GreenTea?extends?Beverage?{
????public?String?getDescription()?{
????????return?"綠茶";
????}
???public?double?cost()?{
????????return?11;
????}
}
...//?咖啡省略

定義調(diào)料，也就是裝飾者的基類，此類必須繼承自 Beverage：

//?調(diào)料
public?abstract?class?Condiment?extends?Beverage?{
????
}

然后我們來定義檸檬、芒果等具體的調(diào)料，它們屬于裝飾者，毫無疑問，這些調(diào)料肯定都需要繼承調(diào)料 Condiment 類：

public?class?Lemon?extends?Condiment?{
????private?Beverage?bevarage;
????//?這里很關(guān)鍵，需要傳入具體的飲料，如需要傳入沒有被裝飾的紅茶或綠茶，
????//?當(dāng)然也可以傳入已經(jīng)裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
????public?Lemon(Beverage?bevarage)?{
????????this.bevarage?=?bevarage;
????}
????public?String?getDescription()?{
????????//?裝飾
????????return?bevarage.getDescription()?+?",?加檸檬";
????}
????public?double?cost()?{
????????//?裝飾
????????return?beverage.cost()?+?2;?//?加檸檬需要?2?元
????}
}

public?class?Mango?extends?Condiment?{
????private?Beverage?bevarage;
????public?Mango(Beverage?bevarage)?{
????????this.bevarage?=?bevarage;
????}
????public?String?getDescription()?{
????????return?bevarage.getDescription()?+?",?加芒果";
????}
????public?double?cost()?{
????????return?beverage.cost()?+?3;?//?加芒果需要?3?元
????}
}
...//?給每一種調(diào)料都加一個(gè)類

看客戶端調(diào)用：

public?static?void?main(String[]?args)?{
????//?首先，我們需要一個(gè)基礎(chǔ)飲料，紅茶、綠茶或咖啡
????Beverage?beverage?=?new?GreenTea();
????//?開始裝飾
????beverage?=?new?Lemon(beverage);?//?先加一份檸檬
????beverage?=?new?Mongo(beverage);?//?再加一份芒果

????System.out.println(beverage.getDescription()?+?"?價(jià)格：￥"?+?beverage.cost());
????//"綠茶, 加檸檬, 加芒果?價(jià)格：￥16"
}

如果我們需要 芒果-珍珠-雙份檸檬-紅茶：

Beverage?beverage?=?new?Mongo(new?Pearl(new?Lemon(new?Lemon(new?BlackTea()))));

是不是很變態(tài)？

看看下圖可能會(huì)清晰一些：

到這里，大家應(yīng)該已經(jīng)清楚裝飾模式了吧。

下面，我們?cè)賮碚f說 java IO 中的裝飾模式。看下圖 InputStream 派生出來的部分類：

我們知道 InputStream 代表了輸入流，具體的輸入來源可以是文件（FileInputStream）、管道（PipedInputStream）、數(shù)組（ByteArrayInputStream）等，這些就像前面奶茶的例子中的紅茶、綠茶，屬于基礎(chǔ)輸入流。

FilterInputStream 承接了裝飾模式的關(guān)鍵節(jié)點(diǎn)，它的實(shí)現(xiàn)類是一系列裝飾器，比如 BufferedInputStream 代表用緩沖來裝飾，也就使得輸入流具有了緩沖的功能，LineNumberInputStream 代表用行號(hào)來裝飾，在操作的時(shí)候就可以取得行號(hào)了，DataInputStream 的裝飾，使得我們可以從輸入流轉(zhuǎn)換為 java 中的基本類型值。

當(dāng)然，在 java IO 中，如果我們使用裝飾器的話，就不太適合面向接口編程了，如：

InputStream?inputStream?=?new?LineNumberInputStream(new?BufferedInputStream(new?FileInputStream("")));

這樣的結(jié)果是，InputStream 還是不具有讀取行號(hào)的功能，因?yàn)樽x取行號(hào)的方法定義在 LineNumberInputStream 類中。

我們應(yīng)該像下面這樣使用：

DataInputStream?is?=?new?DataInputStream(
?????????new?BufferedInputStream(
???????????????????????????????new?FileInputStream("")));

★

所以說嘛，要找到純的嚴(yán)格符合設(shè)計(jì)模式的代碼還是比較難的。

”

門面模式

門面模式（也叫外觀模式，F(xiàn)acade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門面模式的應(yīng)用。這是一個(gè)簡(jiǎn)單的設(shè)計(jì)模式，我們直接上代碼再說吧。

首先，我們定義一個(gè)接口：

public?interface?Shape?{
???void?draw();
}

定義幾個(gè)實(shí)現(xiàn)類：

public?class?Circle?implements?Shape?{
????@Override
????public?void?draw()?{
???????System.out.println("Circle::draw()");
????}
}

public?class?Rectangle?implements?Shape?{
????@Override
????public?void?draw()?{
???????System.out.println("Rectangle::draw()");
????}
}

客戶端調(diào)用：

public?static?void?main(String[]?args)?{
????//?畫一個(gè)圓形
???Shape?circle?=?new?Circle();
???circle.draw();
??
???//?畫一個(gè)長(zhǎng)方形
???Shape?rectangle?=?new?Rectangle();
???rectangle.draw();
}

以上是我們常寫的代碼，我們需要畫圓就要先實(shí)例化圓，畫長(zhǎng)方形就需要先實(shí)例化一個(gè)長(zhǎng)方形，然后再調(diào)用相應(yīng)的 draw() 方法。

下面，我們看看怎么用門面模式來讓客戶端調(diào)用更加友好一些。

我們先定義一個(gè)門面：

public?class?ShapeMaker?{
???private?Shape?circle;
???private?Shape?rectangle;
???private?Shape?square;

???public?ShapeMaker()?{
??????circle?=?new?Circle();
??????rectangle?=?new?Rectangle();
??????square?=?new?Square();
???}

??/**
???*?下面定義一堆方法，具體應(yīng)該調(diào)用什么方法，由這個(gè)門面來決定
???*/
??
???public?void?drawCircle(){
??????circle.draw();
???}
???public?void?drawRectangle(){
??????rectangle.draw();
???}
???public?void?drawSquare(){
??????square.draw();
???}
}

看看現(xiàn)在客戶端怎么調(diào)用：

public?static?void?main(String[]?args)?{
??ShapeMaker?shapeMaker?=?new?ShapeMaker();

??//?客戶端調(diào)用現(xiàn)在更加清晰了
??shapeMaker.drawCircle();
??shapeMaker.drawRectangle();
??shapeMaker.drawSquare();??
}

門面模式的優(yōu)點(diǎn)顯而易見，客戶端不再需要關(guān)注實(shí)例化時(shí)應(yīng)該使用哪個(gè)實(shí)現(xiàn)類，直接調(diào)用門面提供的方法就可以了，因?yàn)殚T面類提供的方法的方法名對(duì)于客戶端來說已經(jīng)很友好了。

組合模式

組合模式用于表示具有層次結(jié)構(gòu)的數(shù)據(jù)，使得我們對(duì)單個(gè)對(duì)象和組合對(duì)象的訪問具有一致性。

直接看一個(gè)例子吧，每個(gè)員工都有姓名、部門、薪水這些屬性，同時(shí)還有下屬員工集合（雖然可能集合為空），而下屬員工和自己的結(jié)構(gòu)是一樣的，也有姓名、部門這些屬性，同時(shí)也有他們的下屬員工集合。

public?class?Employee?{
???private?String?name;
???private?String?dept;
???private?int?salary;
???private?List<Employee>?subordinates;?//?下屬

???public?Employee(String?name,String?dept,?int?sal)?{
??????this.name?=?name;
??????this.dept?=?dept;
??????this.salary?=?sal;
??????subordinates?=?new?ArrayList<Employee>();
???}

???public?void?add(Employee?e)?{
??????subordinates.add(e);
???}

???public?void?remove(Employee?e)?{
??????subordinates.remove(e);
???}

???public?List<Employee>?getSubordinates(){
?????return?subordinates;
???}

???public?String?toString(){
??????return?("Employee?:[?Name?:?"?+?name?+?",?dept?:?"?+?dept?+?",?salary?:"?+?salary+"?]");
???}???
}

通常，這種類需要定義 add(node)、remove(node)、getChildren() 這些方法。

這說的其實(shí)就是組合模式，這種簡(jiǎn)單的模式我就不做過多介紹了，相信各位讀者也不喜歡看我寫廢話。

享元模式

英文是 Flyweight Pattern，不知道是誰最先翻譯的這個(gè)詞，感覺這翻譯真的不好理解，我們?cè)囍鴱?qiáng)行關(guān)聯(lián)起來吧。Flyweight 是輕量級(jí)的意思，享元分開來說就是 共享 元器件，也就是復(fù)用已經(jīng)生成的對(duì)象，這種做法當(dāng)然也就是輕量級(jí)的了。

復(fù)用對(duì)象最簡(jiǎn)單的方式是，用一個(gè) HashMap 來存放每次新生成的對(duì)象。每次需要一個(gè)對(duì)象的時(shí)候，先到 HashMap 中看看有沒有，如果沒有，再生成新的對(duì)象，然后將這個(gè)對(duì)象放入 HashMap 中。

這種簡(jiǎn)單的代碼我就不演示了。

結(jié)構(gòu)型模式總結(jié)

前面，我們說了代理模式、適配器模式、橋梁模式、裝飾模式、門面模式、組合模式和享元模式。讀者是否可以分別把這幾個(gè)模式說清楚了呢？在說到這些模式的時(shí)候，心中是否有一個(gè)清晰的圖或處理流程在腦海里呢？

代理模式是做方法增強(qiáng)的，適配器模式是把雞包裝成鴨這種用來適配接口的，橋梁模式做到了很好的解耦，裝飾模式從名字上就看得出來，適合于裝飾類或者說是增強(qiáng)類的場(chǎng)景，門面模式的優(yōu)點(diǎn)是客戶端不需要關(guān)心實(shí)例化過程，只要調(diào)用需要的方法即可，組合模式用于描述具有層次結(jié)構(gòu)的數(shù)據(jù)，享元模式是為了在特定的場(chǎng)景中緩存已經(jīng)創(chuàng)建的對(duì)象，用于提高性能。

行為型模式

行為型模式關(guān)注的是各個(gè)類之間的相互作用，將職責(zé)劃分清楚，使得我們的代碼更加地清晰。

策略模式

策略模式太常用了，所以把它放到最前面進(jìn)行介紹。它比較簡(jiǎn)單，我就不廢話，直接用代碼說事吧。

下面設(shè)計(jì)的場(chǎng)景是，我們需要畫一個(gè)圖形，可選的策略就是用紅色筆來畫，還是綠色筆來畫，或者藍(lán)色筆來畫。

首先，先定義一個(gè)策略接口：

public?interface?Strategy?{
???public?void?draw(int?radius,?int?x,?int?y);
}

然后我們定義具體的幾個(gè)策略：

public?class?RedPen?implements?Strategy?{
???@Override
???public?void?draw(int?radius,?int?x,?int?y)?{
??????System.out.println("用紅色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
???}
}
public?class?GreenPen?implements?Strategy?{
???@Override
???public?void?draw(int?radius,?int?x,?int?y)?{
??????System.out.println("用綠色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
???}
}
public?class?BluePen?implements?Strategy?{
???@Override
???public?void?draw(int?radius,?int?x,?int?y)?{
??????System.out.println("用藍(lán)色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);
???}
}

使用策略的類：

public?class?Context?{
???private?Strategy?strategy;

???public?Context(Strategy?strategy){
??????this.strategy?=?strategy;
???}

???public?int?executeDraw(int?radius,?int?x,?int?y){
??????return?strategy.draw(radius,?x,?y);
???}
}

客戶端演示：

public?static?void?main(String[]?args)?{
????Context?context?=?new?Context(new?BluePen());?//?使用綠色筆來畫
???context.executeDraw(10,?0,?0);
}

放到一張圖上，讓大家看得清晰些：

這個(gè)時(shí)候，大家有沒有聯(lián)想到結(jié)構(gòu)型模式中的橋梁模式，它們其實(shí)非常相似，我把橋梁模式的圖拿過來大家對(duì)比下：

要我說的話，它們非常相似，橋梁模式在左側(cè)加了一層抽象而已。橋梁模式的耦合更低，結(jié)構(gòu)更復(fù)雜一些。

觀察者模式

觀察者模式對(duì)于我們來說，真是再簡(jiǎn)單不過了。無外乎兩個(gè)操作，觀察者訂閱自己關(guān)心的主題和主題有數(shù)據(jù)變化后通知觀察者們。

首先，需要定義主題，每個(gè)主題需要持有觀察者列表的引用，用于在數(shù)據(jù)變更的時(shí)候通知各個(gè)觀察者：

public?class?Subject?{
????private?List<Observer>?observers?=?new?ArrayList<Observer>();
????private?int?state;
????public?int?getState()?{
????????return?state;
????}
????public?void?setState(int?state)?{
????????this.state?=?state;
????????//?數(shù)據(jù)已變更，通知觀察者們
????????notifyAllObservers();
????}
????//?注冊(cè)觀察者
????public?void?attach(Observer?observer)?{
????????observers.add(observer);
????}
????//?通知觀察者們
????public?void?notifyAllObservers()?{
????????for?(Observer?observer?:?observers)?{
????????????observer.update();
????????}
????}
}

定義觀察者接口：

public?abstract?class?Observer?{
????protected?Subject?subject;
????public?abstract?void?update();
}

其實(shí)如果只有一個(gè)觀察者類的話，接口都不用定義了，不過，通常場(chǎng)景下，既然用到了觀察者模式，我們就是希望一個(gè)事件出來了，會(huì)有多個(gè)不同的類需要處理相應(yīng)的信息。比如，訂單修改成功事件，我們希望發(fā)短信的類得到通知、發(fā)郵件的類得到通知、處理物流信息的類得到通知等。

我們來定義具體的幾個(gè)觀察者類：

public?class?BinaryObserver?extends?Observer?{
????//?在構(gòu)造方法中進(jìn)行訂閱主題
????public?BinaryObserver(Subject?subject)?{
????????this.subject?=?subject;
????????//?通常在構(gòu)造方法中將?this?發(fā)布出去的操作一定要小心
????????this.subject.attach(this);
????}
????//?該方法由主題類在數(shù)據(jù)變更的時(shí)候進(jìn)行調(diào)用
????@Override
????public?void?update()?{
????????String?result?=?Integer.toBinaryString(subject.getState());
????????System.out.println("訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為二進(jìn)制值為："?+?result);
????}
}

public?class?HexaObserver?extends?Observer?{
????public?HexaObserver(Subject?subject)?{
????????this.subject?=?subject;
????????this.subject.attach(this);
????}
????@Override
????public?void?update()?{
????????String?result?=?Integer.toHexString(subject.getState()).toUpperCase();
????????System.out.println("訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為十六進(jìn)制值為："?+?result);
????}
}

客戶端使用也非常簡(jiǎn)單：

public?static?void?main(String[]?args)?{
????//?先定義一個(gè)主題
????Subject?subject1?=?new?Subject();
????//?定義觀察者
????new?BinaryObserver(subject1);
????new?HexaObserver(subject1);
??
????//?模擬數(shù)據(jù)變更，這個(gè)時(shí)候，觀察者們的?update?方法將會(huì)被調(diào)用
????subject.setState(11);
}

output:

訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為二進(jìn)制值為：1011
訂閱的數(shù)據(jù)發(fā)生變化，新的數(shù)據(jù)處理為十六進(jìn)制值為：B

當(dāng)然，jdk 也提供了相似的支持，具體的大家可以參考 java.util.Observable 和 java.util.Observer 這兩個(gè)類。

實(shí)際生產(chǎn)過程中，觀察者模式往往用消息中間件來實(shí)現(xiàn)，如果要實(shí)現(xiàn)單機(jī)觀察者模式，筆者建議讀者使用 Guava 中的 EventBus，它有同步實(shí)現(xiàn)也有異步實(shí)現(xiàn)，本文主要介紹設(shè)計(jì)模式，就不展開說了。

還有，即使是上面的這個(gè)代碼，也會(huì)有很多變種，大家只要記住核心的部分，那就是一定有一個(gè)地方存放了所有的觀察者，然后在事件發(fā)生的時(shí)候，遍歷觀察者，調(diào)用它們的回調(diào)函數(shù)。

責(zé)任鏈模式

責(zé)任鏈通常需要先建立一個(gè)單向鏈表，然后調(diào)用方只需要調(diào)用頭部節(jié)點(diǎn)就可以了，后面會(huì)自動(dòng)流轉(zhuǎn)下去。比如流程審批就是一個(gè)很好的例子，只要終端用戶提交申請(qǐng)，根據(jù)申請(qǐng)的內(nèi)容信息，自動(dòng)建立一條責(zé)任鏈，然后就可以開始流轉(zhuǎn)了。

有這么一個(gè)場(chǎng)景，用戶參加一個(gè)活動(dòng)可以領(lǐng)取獎(jiǎng)品，但是活動(dòng)需要進(jìn)行很多的規(guī)則校驗(yàn)然后才能放行，比如首先需要校驗(yàn)用戶是否是新用戶、今日參與人數(shù)是否有限額、全場(chǎng)參與人數(shù)是否有限額等等。設(shè)定的規(guī)則都通過后，才能讓用戶領(lǐng)走獎(jiǎng)品。

★

如果產(chǎn)品給你這個(gè)需求的話，我想大部分人一開始肯定想的就是，用一個(gè) List 來存放所有的規(guī)則，然后 foreach 執(zhí)行一下每個(gè)規(guī)則就好了。不過，讀者也先別急，看看責(zé)任鏈模式和我們說的這個(gè)有什么不一樣？

”

首先，我們要定義流程上節(jié)點(diǎn)的基類：

public?abstract?class?RuleHandler?{
????//?后繼節(jié)點(diǎn)
????protected?RuleHandler?successor;
??
????public?abstract?void?apply(Context?context);
??
????public?void?setSuccessor(RuleHandler?successor)?{
????????this.successor?=?successor;
????}
??
????public?RuleHandler?getSuccessor()?{
????????return?successor;
????}
}

接下來，我們需要定義具體的每個(gè)節(jié)點(diǎn)了。

校驗(yàn)用戶是否是新用戶：

public?class?NewUserRuleHandler?extends?RuleHandler?{
????public?void?apply(Context?context)?{
????????if?(context.isNewUser())?{
????????????//?如果有后繼節(jié)點(diǎn)的話，傳遞下去
????????????if?(this.getSuccessor()?!=?null)?{
????????????????this.getSuccessor().apply(context);
????????????}
????????}?else?{
????????????throw?new?RuntimeException("該活動(dòng)僅限新用戶參與");
????????}
????}
}

校驗(yàn)用戶所在地區(qū)是否可以參與：

public?class?LocationRuleHandler?extends?RuleHandler?{
????public?void?apply(Context?context)?{
????????boolean?allowed?=?activityService.isSupportedLocation(context.getLocation);
????????if?(allowed)?{
????????????if?(this.getSuccessor()?!=?null)?{
????????????????this.getSuccessor().apply(context);
????????????}
????????}?else?{
????????????throw?new?RuntimeException("非常抱歉，您所在的地區(qū)無法參與本次活動(dòng)");
????????}
????}
}

校驗(yàn)獎(jiǎng)品是否已領(lǐng)完：

public?class?LimitRuleHandler?extends?RuleHandler?{
????public?void?apply(Context?context)?{
????????int?remainedTimes?=?activityService.queryRemainedTimes(context);?//?查詢剩余獎(jiǎng)品
????????if?(remainedTimes?>?0)?{
????????????if?(this.getSuccessor()?!=?null)?{
????????????????this.getSuccessor().apply(userInfo);
????????????}
????????}?else?{
????????????throw?new?RuntimeException("您來得太晚了，獎(jiǎng)品被領(lǐng)完了");
????????}
????}
}

客戶端：

public?static?void?main(String[]?args)?{
????RuleHandler?newUserHandler?=?new?NewUserRuleHandler();
????RuleHandler?locationHandler?=?new?LocationRuleHandler();
????RuleHandler?limitHandler?=?new?LimitRuleHandler();
??
????//?假設(shè)本次活動(dòng)僅校驗(yàn)地區(qū)和獎(jiǎng)品數(shù)量，不校驗(yàn)新老用戶
????locationHandler.setSuccessor(limitHandler);
??
????locationHandler.apply(context);
}

代碼其實(shí)很簡(jiǎn)單，就是先定義好一個(gè)鏈表，然后在通過任意一節(jié)點(diǎn)后，如果此節(jié)點(diǎn)有后繼節(jié)點(diǎn)，那么傳遞下去。

至于它和我們前面說的用一個(gè) List 存放需要執(zhí)行的規(guī)則的做法有什么異同，留給讀者自己琢磨吧。

模板方法模式

在含有繼承結(jié)構(gòu)的代碼中，模板方法模式是非常常用的。

通常會(huì)有一個(gè)抽象類：

public?abstract?class?AbstractTemplate?{
????//?這就是模板方法
????public?void?templateMethod()?{
????????init();
????????apply();?//?這個(gè)是重點(diǎn)
????????end();?//?可以作為鉤子方法
????}

????protected?void?init()?{
????????System.out.println("init?抽象層已經(jīng)實(shí)現(xiàn)，子類也可以選擇覆寫");
????}

????//?留給子類實(shí)現(xiàn)
????protected?abstract?void?apply();

????protected?void?end()?{
????}
}

模板方法中調(diào)用了 3 個(gè)方法，其中 apply() 是抽象方法，子類必須實(shí)現(xiàn)它，其實(shí)模板方法中有幾個(gè)抽象方法完全是自由的，我們也可以將三個(gè)方法都設(shè)置為抽象方法，讓子類來實(shí)現(xiàn)。也就是說，模板方法只負(fù)責(zé)定義第一步應(yīng)該要做什么，第二步應(yīng)該做什么，第三步應(yīng)該做什么，至于怎么做，由子類來實(shí)現(xiàn)。

我們寫一個(gè)實(shí)現(xiàn)類：

public?class?ConcreteTemplate?extends?AbstractTemplate?{
????public?void?apply()?{
????????System.out.println("子類實(shí)現(xiàn)抽象方法?apply");
????}

????public?void?end()?{
????????System.out.println("我們可以把?method3?當(dāng)做鉤子方法來使用，需要的時(shí)候覆寫就可以了");
????}
}

客戶端調(diào)用演示：

public?static?void?main(String[]?args)?{
????AbstractTemplate?t?=?new?ConcreteTemplate();
????//?調(diào)用模板方法
????t.templateMethod();
}

代碼其實(shí)很簡(jiǎn)單，基本上看到就懂了，關(guān)鍵是要學(xué)會(huì)用到自己的代碼中。

狀態(tài)模式

update: 2017-10-19

廢話我就不說了，我們說一個(gè)簡(jiǎn)單的例子。商品庫(kù)存中心有個(gè)最基本的需求是減庫(kù)存和補(bǔ)庫(kù)存，我們看看怎么用狀態(tài)模式來寫。

核心在于，我們的關(guān)注點(diǎn)不再是 Context 是該進(jìn)行哪種操作，而是關(guān)注在這個(gè) Context 會(huì)有哪些操作。

定義狀態(tài)接口：

public?interface?State?{
????public?void?doAction(Context?context);
}

定義減庫(kù)存的狀態(tài)：

public?class?DeductState?implements?State?{

????public?void?doAction(Context?context)?{
????????System.out.println("商品賣出，準(zhǔn)備減庫(kù)存");
????????context.setState(this);

????????//...?執(zhí)行減庫(kù)存的具體操作
????}

????public?String?toString()?{
????????return?"Deduct?State";
????}
}?

定義補(bǔ)庫(kù)存狀態(tài)：

public?class?RevertState?implements?State?{
??
????public?void?doAction(Context?context)?{
????????System.out.println("給此商品補(bǔ)庫(kù)存");
????????context.setState(this);

????????//...?執(zhí)行加庫(kù)存的具體操作
????}

????public?String?toString()?{
????????return?"Revert?State";
????}
}

前面用到了 context.setState(this)，我們來看看怎么定義 Context 類：

public?class?Context?{
????private?State?state;
???private?String?name;
???public?Context(String?name)?{
????????this.name?=?name;
????}
????
???public?void?setState(State?state)?{
????????this.state?=?state;
????}
???public?void?getState()?{
????????return?this.state;
????}
}

我們來看下客戶端調(diào)用，大家就一清二楚了：

public?static?void?main(String[]?args)?{
????//?我們需要操作的是?iPhone?X
????Context?context?=?new?Context("iPhone?X");
???
????//?看看怎么進(jìn)行補(bǔ)庫(kù)存操作
???State?revertState?=?new?RevertState();
???revertState.doAction(context);
??
????//?同樣的，減庫(kù)存操作也非常簡(jiǎn)單
???State?deductState?=?new?DeductState();
???deductState.doAction(context);
??
???//?如果需要我們可以獲取當(dāng)前的狀態(tài)
????//?context.getState().toString();
}

讀者可能會(huì)發(fā)現(xiàn)，在上面這個(gè)例子中，如果我們不關(guān)心當(dāng)前 context 處于什么狀態(tài)，那么 Context 就可以不用維護(hù) state 屬性了，那樣代碼會(huì)簡(jiǎn)單很多。

不過，商品庫(kù)存這個(gè)例子畢竟只是個(gè)例，我們還有很多實(shí)例是需要知道當(dāng)前 context 處于什么狀態(tài)的。

行為型模式總結(jié)

行為型模式部分介紹了策略模式、觀察者模式、責(zé)任鏈模式、模板方法模式和狀態(tài)模式，其實(shí)，經(jīng)典的行為型模式還包括備忘錄模式、命令模式等，但是它們的使用場(chǎng)景比較有限，而且本文篇幅也挺大了，我就不進(jìn)行介紹了。

總結(jié)

學(xué)習(xí)設(shè)計(jì)模式的目的是為了讓我們的代碼更加的優(yōu)雅、易維護(hù)、易擴(kuò)展。這次整理這篇文章，讓我重新審視了一下各個(gè)設(shè)計(jì)模式，對(duì)我自己而言收獲還是挺大的。我想，文章的最大收益者一般都是作者本人，為了寫一篇文章，需要鞏固自己的知識(shí)，需要尋找各種資料，而且，自己寫過的才最容易記住，也算是我給讀者的建議吧。