設計模式是對大家實際工作中寫的各種代碼進行高層次抽象的總結，其中最出名的當屬?Gang of Four?(GoF) 的分類了，他們將設計模式分類為 23 種經典的模式，根據用途我們又可以分為三大類，分別為創建型模式、結構型模式和行為型模式。

有一些重要的設計原則在開篇和大家分享下，這些原則將貫通全文：

面向接口編程，而不是面向實現。這個很重要，也是優雅的、可擴展的代碼的第一步，這就不需要多說了吧。

職責單一原則。每個類都應該只有一個單一的功能，并且該功能應該由這個類完全封裝起來。

對修改關閉，對擴展開放。對修改關閉是說，我們辛辛苦苦加班寫出來的代碼，該實現的功能和該修復的 bug 都完成了，別人可不能說改就改；對擴展開放就比較好理解了，也就是說在我們寫好的代碼基礎上，很容易實現擴展。

創建型模式比較簡單，但是會比較沒有意思，結構型和行為型比較有意思。

創建型模式

創建型模式的作用就是創建對象，說到創建一個對象，最熟悉的就是 new 一個對象，然后 set 相關屬性。但是，在很多場景下，我們需要給客戶端提供更加友好的創建對象的方式，尤其是那種我們定義了類，但是需要提供給其他開發者用的時候。

簡單工廠模式

和名字一樣簡單，非常簡單，直接上代碼吧：

public?class?FoodFactory?{public?static?Food?makeFood(String?name)?{if?(name.equals("noodle"))?{Food?noodle?=?new?LanZhouNoodle();noodle.addSpicy("more");return?noodle;}?else?if?(name.equals("chicken"))?{Food?chicken?=?new?HuangMenChicken();chicken.addCondiment("potato");return?chicken;}?else?{return?null;}} }

其中，LanZhouNoodle 和 HuangMenChicken 都繼承自 Food。

簡單地說，簡單工廠模式通常就是這樣，一個工廠類 XxxFactory，里面有一個靜態方法，根據我們不同的參數，返回不同的派生自同一個父類（或實現同一接口）的實例對象。

我們強調職責單一?原則，一個類只提供一種功能，FoodFactory 的功能就是只要負責生產各種 Food。

工廠模式

簡單工廠模式很簡單，如果它能滿足我們的需要，我覺得就不要折騰了。之所以需要引入工廠模式，是因為我們往往需要使用兩個或兩個以上的工廠。

public?interface?FoodFactory?{Food?makeFood(String?name); } public?class?ChineseFoodFactory?implements?FoodFactory?{@Overridepublic?Food?makeFood(String?name)?{if?(name.equals("A"))?{return?new?ChineseFoodA();}?else?if?(name.equals("B"))?{return?new?ChineseFoodB();}?else?{return?null;}} } public?class?AmericanFoodFactory?implements?FoodFactory?{@Overridepublic?Food?makeFood(String?name)?{if?(name.equals("A"))?{return?new?AmericanFoodA();}?else?if?(name.equals("B"))?{return?new?AmericanFoodB();}?else?{return?null;}} }

其中，ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。

客戶端調用：

public?class?APP?{public?static?void?main(String[]?args)?{//?先選擇一個具體的工廠FoodFactory?factory?=?new?ChineseFoodFactory();//?由第一步的工廠產生具體的對象，不同的工廠造出不一樣的對象Food?food?=?factory.makeFood("A");} }

雖然都是調用 makeFood("A") ?制作 A 類食物，但是，不同的工廠生產出來的完全不一樣。

第一步，我們需要選取合適的工廠，然后第二步基本上和簡單工廠一樣。

核心在于，我們需要在第一步選好我們需要的工廠?。比如，我們有 LogFactory 接口，實現類有 FileLogFactory 和 KafkaLogFactory，分別對應將日志寫入文件和寫入 Kafka 中，顯然，我們客戶端第一步就需要決定到底要實例化 FileLogFactory 還是 KafkaLogFactory，這將決定之后的所有的操作。

雖然簡單，不過我也把所有的構件都畫到一張圖上，這樣讀者看著比較清晰：

factory-1

抽象工廠模式

當涉及到產品族?的時候，就需要引入抽象工廠模式了。

一個經典的例子是造一臺電腦。我們先不引入抽象工廠模式，看看怎么實現。

因為電腦是由許多的構件組成的，我們將 CPU 和主板進行抽象，然后 CPU 由 CPUFactory 生產，主板由 MainBoardFactory 生產，然后，我們再將 CPU 和主板搭配起來組合在一起，如下圖：

這個時候的客戶端調用是這樣的：

//?得到?Intel?的?CPU CPUFactory?cpuFactory?=?new?IntelCPUFactory(); CPU?cpu?=?intelCPUFactory.makeCPU();//?得到?AMD?的主板 MainBoardFactory?mainBoardFactory?=?new?AmdMainBoardFactory(); MainBoard?mainBoard?=?mainBoardFactory.make();//?組裝?CPU?和主板 Computer?computer?=?new?Computer(cpu,?mainBoard);

單獨看 CPU 工廠和主板工廠，它們分別是前面我們說的工廠模式?。這種方式也容易擴展，因為要給電腦加硬盤的話，只需要加一個 HardDiskFactory 和相應的實現即可，不需要修改現有的工廠。

但是，這種方式有一個問題，那就是如果?Intel 家產的 CPU 和 AMD 產的主板不能兼容使用?，那么這代碼就容易出錯，因為客戶端并不知道它們不兼容，也就會錯誤地出現隨意組合。

下面就是我們要說的產品族?的概念，它代表了組成某個產品的一系列附件的集合：

當涉及到這種產品族的問題的時候，就需要抽象工廠模式來支持了。我們不再定義 CPU 工廠、主板工廠、硬盤工廠、顯示屏工廠等等，我們直接定義電腦工廠，每個電腦工廠負責生產所有的設備，這樣能保證肯定不存在兼容問題。

?

這個時候，對于客戶端來說，不再需要單獨挑選 CPU廠商、主板廠商、硬盤廠商等，直接選擇一家品牌工廠，品牌工廠會負責生產所有的東西，而且能保證肯定是兼容可用的。

public?static?void?main(String[]?args)?{//?第一步就要選定一個“大廠”ComputerFactory?cf?=?new?AmdFactory();//?從這個大廠造?CPUCPU?cpu?=?cf.makeCPU();//?從這個大廠造主板MainBoard?board?=?cf.makeMainBoard();//?從這個大廠造硬盤HardDisk?hardDisk?=?cf.makeHardDisk();//?將同一個廠子出來的?CPU、主板、硬盤組裝在一起Computer?result?=?new?Computer(cpu,?board,?hardDisk); }

當然，抽象工廠的問題也是顯而易見的，比如我們要加個顯示器，就需要修改所有的工廠，給所有的工廠都加上制造顯示器的方法。這有點違反了對修改關閉，對擴展開放?這個設計原則。

單例模式

單例模式用得最多，錯得最多。

餓漢模式最簡單：

public?class?Singleton?{//?首先，將?new?Singleton()?堵死private?Singleton()?{};//?創建私有靜態實例，意味著這個類第一次使用的時候就會進行創建private?static?Singleton?instance?=?new?Singleton();public?static?Singleton?getInstance()?{return?instance;}//?瞎寫一個靜態方法。這里想說的是，如果我們只是要調用 Singleton.getDate(...)，//?本來是不想要生成?Singleton?實例的，不過沒辦法，已經生成了public?static?Date?getDate(String?mode)?{return?new?Date();} }

很多人都能說出餓漢模式的缺點，可是我覺得生產過程中，很少碰到這種情況：你定義了一個單例的類，不需要其實例，可是你卻把一個或幾個你會用到的靜態方法塞到這個類中。

飽漢模式最容易出錯：

public?class?Singleton?{//?首先，也是先堵死?new?Singleton()?這條路private?Singleton()?{}//?和餓漢模式相比，這邊不需要先實例化出來，注意這里的?volatile，它是必須的private?static?volatile?Singleton?instance?=?null;public?static?Singleton?getInstance()?{if?(instance?==?null)?{//?加鎖synchronized?(Singleton.class)?{//?這一次判斷也是必須的，不然會有并發問題if?(instance?==?null)?{instance?=?new?Singleton();}}}return?instance;} }

雙重檢查，指的是兩次檢查 instance 是否為 null。

volatile 在這里是需要的，希望能引起讀者的關注。

很多人不知道怎么寫，直接就在 getInstance() 方法簽名上加上 synchronized，這就不多說了，性能太差。

嵌套類最經典，以后大家就用它吧：

public?class?Singleton3?{private?Singleton3()?{}//?主要是使用了?嵌套類可以訪問外部類的靜態屬性和靜態方法?的特性private?static?class?Holder?{private?static?Singleton3?instance?=?new?Singleton3();}public?static?Singleton3?getInstance()?{return?Holder.instance;} }

注意，很多人都會把這個嵌套類?說成是靜態內部類?，嚴格地說，內部類和嵌套類是不一樣的，它們能訪問的外部類權限也是不一樣的。

最后，我們說一下枚舉，枚舉很特殊，它在類加載的時候會初始化里面的所有的實例，而且 JVM 保證了它們不會再被實例化，所以它天生就是單例的。

雖然我們平時很少看到用枚舉來實現單例，但是在 RxJava 的源碼中，有很多地方都用了枚舉來實現單例。

建造者模式

經常碰見的 XxxBuilder 的類，通常都是建造者模式的產物。建造者模式其實有很多的變種，但是對于客戶端來說，我們的使用通常都是一個模式的：

Food?food?=?new?FoodBuilder().a().b().c().build(); Food?food?=?Food.builder().a().b().c().build();

套路就是先 new 一個 Builder，然后可以鏈式地調用一堆方法，最后再調用一次 build() 方法，我們需要的對象就有了。

來一個中規中矩的建造者模式：

class?User?{//?下面是“一堆”的屬性private?String?name;private?String?password;private?String?nickName;private?int?age;//?構造方法私有化，不然客戶端就會直接調用構造方法了private?User(String?name,?String?password,?String?nickName,?int?age)?{this.name?=?name;this.password?=?password;this.nickName?=?nickName;this.age?=?age;}//?靜態方法，用于生成一個?Builder，這個不一定要有，不過寫這個方法是一個很好的習慣，//?有些代碼要求別人寫?new?User.UserBuilder().a()...build()?看上去就沒那么好public?static?UserBuilder?builder()?{return?new?UserBuilder();}public?static?class?UserBuilder?{//?下面是和?User?一模一樣的一堆屬性private?String??name;private?String?password;private?String?nickName;private?int?age;private?UserBuilder()?{}//?鏈式調用設置各個屬性值，返回?this，即?UserBuilderpublic?UserBuilder?name(String?name)?{this.name?=?name;return?this;}public?UserBuilder?password(String?password)?{this.password?=?password;return?this;}public?UserBuilder?nickName(String?nickName)?{this.nickName?=?nickName;return?this;}public?UserBuilder?age(int?age)?{this.age?=?age;return?this;}// build()?方法負責將 UserBuilder 中設置好的屬性“復制”到 User 中。//?當然，可以在?“復制”?之前做點檢驗public?User?build()?{if?(name?==?null?||?password?==?null)?{throw?new?RuntimeException("用戶名和密碼必填");}if?(age?<=?0?||?age?>=?150)?{throw?new?RuntimeException("年齡不合法");}//?還可以做賦予”默認值“的功能if?(nickName?==?null)?{nickName?=?name;}return?new?User(name,?password,?nickName,?age);}} }

核心是：先把所有的屬性都設置給 Builder，然后 build() 方法的時候，將這些屬性復制?給實際產生的對象。

看看客戶端的調用：

public?class?APP?{public?static?void?main(String[]?args)?{User?d?=?User.builder().name("foo").password("pAss12345").age(25).build();} }

說實話，建造者模式的鏈式?寫法很吸引人，但是，多寫了很多“無用”的 builder 的代碼，感覺這個模式沒什么用。不過，當屬性很多，而且有些必填，有些選填的時候，這個模式會使代碼清晰很多。我們可以在?Builder 的構造方法?中強制讓調用者提供必填字段，還有，在 build() 方法中校驗各個參數比在 User 的構造方法中校驗，代碼要優雅一些。

題外話，強烈建議讀者使用 lombok，用了 lombok 以后，上面的一大堆代碼會變成如下這樣:

@Builderclass?User?{????private?String??name;????private?String?password;????private?String?nickName;????private?int?age;}

怎么樣，省下來的時間是不是又可以干點別的了。

當然，如果你只是想要鏈式寫法，不想要建造者模式，有個很簡單的辦法，User 的 getter 方法不變，所有的 setter 方法都讓其?return this?就可以了，然后就可以像下面這樣調用：

User?user?=?new?User().setName("").setPassword("").setAge(20);

很多人是這么用的，但是筆者覺得其實這種寫法非常地不優雅，不是很推薦使用。

原型模式

這是我要說的創建型模式的最后一個設計模式了。

原型模式很簡單：有一個原型實例?，基于這個原型實例產生新的實例，也就是“克隆”了。

Object 類中有一個 clone() 方法，它用于生成一個新的對象，當然，如果我們要調用這個方法，java 要求我們的類必須先實現 Cloneable 接口?，此接口沒有定義任何方法，但是不這么做的話，在 clone() 的時候，會拋出 CloneNotSupportedException 異常。

protected?native?Object?clone()?throws?CloneNotSupportedException;

java 的克隆是淺克隆，碰到對象引用的時候，克隆出來的對象和原對象中的引用將指向同一個對象。通常實現深克隆的方法是將對象進行序列化，然后再進行反序列化。

原型模式了解到這里我覺得就夠了，各種變著法子說這種代碼或那種代碼是原型模式，沒什么意義。

創建型模式總結

創建型模式總體上比較簡單，它們的作用就是為了產生實例對象，算是各種工作的第一步了，因為我們寫的是面向對象?的代碼，所以我們第一步當然是需要創建一個對象了。

簡單工廠模式最簡單；工廠模式在簡單工廠模式的基礎上增加了選擇工廠的維度，需要第一步選擇合適的工廠；抽象工廠模式有產品族的概念，如果各個產品是存在兼容性問題的，就要用抽象工廠模式。單例模式就不說了，為了保證全局使用的是同一對象，一方面是安全性考慮，一方面是為了節省資源；建造者模式專門對付屬性很多的那種類，為了讓代碼更優美；原型模式用得最少，了解和 Object 類中的 clone() 方法相關的知識即可。

結構型模式

前面創建型模式介紹了創建對象的一些設計模式，這節介紹的結構型模式旨在通過改變代碼結構來達到解耦的目的，使得我們的代碼容易維護和擴展。

代理模式

第一個要介紹的代理模式是最常使用的模式之一了，用一個代理來隱藏具體實現類的實現細節，通常還用于在真實的實現的前后添加一部分邏輯。

既然說是代理?，那就要對客戶端隱藏真實實現，由代理來負責客戶端的所有請求。當然，代理只是個代理，它不會完成實際的業務邏輯，而是一層皮而已，但是對于客戶端來說，它必須表現得就是客戶端需要的真實實現。

理解代理?這個詞，這個模式其實就簡單了。

public?interface?FoodService?{Food?makeChicken();Food?makeNoodle(); }public?class?FoodServiceImpl?implements?FoodService?{public?Food?makeChicken()?{Food?f?=?new?Chicken()f.setChicken("1kg");f.setSpicy("1g");f.setSalt("3g");return?f;}public?Food?makeNoodle()?{Food?f?=?new?Noodle();f.setNoodle("500g");f.setSalt("5g");return?f;} }//?代理要表現得“就像是”真實實現類，所以需要實現?FoodService public?class?FoodServiceProxy?implements?FoodService?{//?內部一定要有一個真實的實現類，當然也可以通過構造方法注入private?FoodService?foodService?=?new?FoodServiceImpl();public?Food?makeChicken()?{System.out.println("我們馬上要開始制作雞肉了");//?如果我們定義這句為核心代碼的話，那么，核心代碼是真實實現類做的，//?代理只是在核心代碼前后做些“無足輕重”的事情Food?food?=?foodService.makeChicken();System.out.println("雞肉制作完成啦，加點胡椒粉");?//?增強food.addCondiment("pepper");return?food;}public?Food?makeNoodle()?{System.out.println("準備制作拉面~");Food?food?=?foodService.makeNoodle();System.out.println("制作完成啦")return?food;} }

客戶端調用，注意，我們要用代理來實例化接口：

//?這里用代理類來實例化 FoodService?foodService?=?new?FoodServiceProxy(); foodService.makeChicken();

?

proxy

我們發現沒有，代理模式說白了就是做?“方法包裝”?或做?“方法增強”?。在面向切面編程中，其實就是動態代理的過程。比如 Spring 中，我們自己不定義代理類，但是 Spring 會幫我們動態來定義代理，然后把我們定義在 @Before、@After、@Around 中的代碼邏輯動態添加到代理中。

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

適配器模式

說完代理模式，說適配器模式，是因為它們很相似，這里可以做個比較。

適配器模式做的就是，有一個接口需要實現，但是我們現成的對象都不滿足，需要加一層適配器來進行適配。

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

默認適配器模式

首先，我們先看看最簡單的適配器模式默認適配器模式(Default Adapter)?是怎么樣的。

我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對文件或文件夾進行監控，一旦發生了對應的操作，就會觸發相應的方法。

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); }

此接口的一大問題是抽象方法太多了，如果我們要用這個接口，意味著我們要實現每一個抽象方法，如果我們只是想要監控文件夾中的文件創建?和文件刪除?事件，可是我們還是不得不實現所有的方法，很明顯，這不是我們想要的。

所以，我們需要下面的一個適配器?，它用于實現上面的接口，但是所有的方法都是空方法?，這樣，我們就可以轉而定義自己的類來繼承下面這個類即可。

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)?{} }

比如我們可以定義以下類，我們僅僅需要實現我們想實現的方法就可以了：

public?class?FileMonitor?extends?FileAlterationListenerAdaptor?{public?void?onFileCreate(final?File?file)?{//?文件創建doSomething();}public?void?onFileDelete(final?File?file)?{//?文件刪除doSomething();} }

當然，上面說的只是適配器模式的其中一種，也是最簡單的一種，無需多言。下面，再介紹**“正統的”** 適配器模式。

對象適配器模式

來看一個《Head First 設計模式》中的一個例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當鴨來用。因為，現在鴨這個接口，我們沒有合適的實現類可以用，所以需要適配器。

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("雞也會飛哦");} }

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

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

客戶端調用很簡單了：

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

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

我們用一個圖來簡單說明下：

?

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

類適配器模式

廢話少說，直接上圖：

?

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

適配器模式總結

類適配和對象適配的異同

一個采用繼承，一個采用組合；

類適配屬于靜態實現，對象適配屬于組合的動態實現，對象適配需要多實例化一個對象。

總體來說，對象適配用得比較多。

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

比較這兩種模式，其實是比較對象適配器模式和代理模式，在代碼結構上，它們很相似，都需要一個具體的實現類的實例。但是它們的目的不一樣，代理模式做的是增強原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當做鴨來使用”，而雞和鴨它們之間原本沒有繼承關系。

?

橋梁模式

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

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

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

然后是一系列實現類：

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

定義一個抽象類，此類的實現類都需要使用 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);} } //?長方形 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(); }

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

這回大家應該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優點也是顯而易見的，就是非常容易進行擴展。

本節引用了這里的例子，并對其進行了修改。

裝飾模式

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

首先，我們先看一個簡單的圖，看這個圖的時候，了解下層次結構就可以了：

我們來說說裝飾模式的出發點，從圖中可以看到，接口?Component?其實已經有了?ConcreteComponentA?和?ConcreteComponentB?兩個實現類了，但是，如果我們要增強?這兩個實現類的話，我們就可以采用裝飾模式，用具體的裝飾器來裝飾?實現類，以達到增強的目的。

從名字來簡單解釋下裝飾器。既然說是裝飾，那么往往就是添加小功能?這種，而且，我們要滿足可以添加多個小功能。最簡單的，代理模式就可以實現功能的增強，但是代理不容易實現多個功能的增強，當然你可以說用代理包裝代理的多層包裝方式，但是那樣的話代碼就復雜了。

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

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

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

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

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

不說廢話了，上代碼。

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

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

然后是三個基礎飲料實現類，紅茶、綠茶和咖啡：

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;????}}...//?咖啡省略

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

//?調料public?abstract?class?Condiment?extends?Beverage?{}

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

public?class?Lemon?extends?Condiment?{private?Beverage?bevarage;//?這里很關鍵，需要傳入具體的飲料，如需要傳入沒有被裝飾的紅茶或綠茶，//?當然也可以傳入已經裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶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?元} } ...//?給每一種調料都加一個類

看客戶端調用：

public?static?void?main(String[]?args)?{//?首先，我們需要一個基礎飲料，紅茶、綠茶或咖啡Beverage?beverage?=?new?GreenTea();//?開始裝飾beverage?=?new?Lemon(beverage);?//?先加一份檸檬beverage?=?new?Mongo(beverage);?//?再加一份芒果System.out.println(beverage.getDescription()?+?"?價格：￥"?+?beverage.cost());//"綠茶, 加檸檬, 加芒果?價格：￥16" }

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

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

是不是很變態？

看看下圖可能會清晰一些：

到這里，大家應該已經清楚裝飾模式了吧。

下面，我們再來說說 java IO 中的裝飾模式。看下圖 InputStream 派生出來的部分類：

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

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

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

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

這樣的結果是，InputStream 還是不具有讀取行號的功能，因為讀取行號的方法定義在 LineNumberInputStream 類中。

我們應該像下面這樣使用：

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

所以說嘛，要找到純的嚴格符合設計模式的代碼還是比較難的。

門面模式

門面模式（也叫外觀模式，Facade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門面模式的應用。這是一個簡單的設計模式，我們直接上代碼再說吧。

首先，我們定義一個接口：

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

定義幾個實現類：

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

客戶端調用：

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

以上是我們常寫的代碼，我們需要畫圓就要先實例化圓，畫長方形就需要先實例化一個長方形，然后再調用相應的 draw() 方法。

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

我們先定義一個門面：

public?class?ShapeMaker?{private?Shape?circle;private?Shape?rectangle;private?Shape?square;public?ShapeMaker()?{circle?=?new?Circle();rectangle?=?new?Rectangle();square?=?new?Square();}/***?下面定義一堆方法，具體應該調用什么方法，由這個門面來決定*/public?void?drawCircle(){circle.draw();}public?void?drawRectangle(){rectangle.draw();}public?void?drawSquare(){square.draw();} }

看看現在客戶端怎么調用：

public?static?void?main(String[]?args)?{ShapeMaker?shapeMaker?=?new?ShapeMaker();//?客戶端調用現在更加清晰了shapeMaker.drawCircle();shapeMaker.drawRectangle();shapeMaker.drawSquare(); }

門面模式的優點顯而易見，客戶端不再需要關注實例化時應該使用哪個實現類，直接調用門面提供的方法就可以了，因為門面類提供的方法的方法名對于客戶端來說已經很友好了。

組合模式

組合模式用于表示具有層次結構的數據，使得我們對單個對象和組合對象的訪問具有一致性。

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

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() 這些方法。

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

享元模式

英文是 Flyweight Pattern，不知道是誰最先翻譯的這個詞，感覺這翻譯真的不好理解，我們試著強行關聯起來吧。Flyweight 是輕量級的意思，享元分開來說就是 共享 元器件，也就是復用已經生成的對象，這種做法當然也就是輕量級的了。

復用對象最簡單的方式是，用一個 HashMap 來存放每次新生成的對象。每次需要一個對象的時候，先到 HashMap 中看看有沒有，如果沒有，再生成新的對象，然后將這個對象放入 HashMap 中。

這種簡單的代碼我就不演示了。

結構型模式總結

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

代理模式是做方法增強的，適配器模式是把雞包裝成鴨這種用來適配接口的，橋梁模式做到了很好的解耦，裝飾模式從名字上就看得出來，適合于裝飾類或者說是增強類的場景，門面模式的優點是客戶端不需要關心實例化過程，只要調用需要的方法即可，組合模式用于描述具有層次結構的數據，享元模式是為了在特定的場景中緩存已經創建的對象，用于提高性能。

行為型模式

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

策略模式

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

下面設計的場景是，我們需要畫一個圖形，可選的策略就是用紅色筆來畫，還是綠色筆來畫，或者藍色筆來畫。

首先，先定義一個策略接口：

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

然后我們定義具體的幾個策略：

public?class?RedPen?implements?Strategy?{@Overridepublic?void?draw(int?radius,?int?x,?int?y)?{System.out.println("用紅色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);} } public?class?GreenPen?implements?Strategy?{@Overridepublic?void?draw(int?radius,?int?x,?int?y)?{System.out.println("用綠色筆畫圖，radius:"?+?radius?+?",?x:"?+?x?+?",?y:"?+?y);} } public?class?BluePen?implements?Strategy?{@Overridepublic?void?draw(int?radius,?int?x,?int?y)?{System.out.println("用藍色筆畫圖，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); }

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

strategy-1

這個時候，大家有沒有聯想到結構型模式中的橋梁模式，它們其實非常相似，我把橋梁模式的圖拿過來大家對比下：

bridge-1

要我說的話，它們非常相似，橋梁模式在左側加了一層抽象而已。橋梁模式的耦合更低，結構更復雜一些。

觀察者模式

觀察者模式對于我們來說，真是再簡單不過了。無外乎兩個操作，觀察者訂閱自己關心的主題和主題有數據變化后通知觀察者們。

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

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;//?數據已變更，通知觀察者們notifyAllObservers();}//?注冊觀察者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(); }

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

我們來定義具體的幾個觀察者類：

public?class?BinaryObserver?extends?Observer?{//?在構造方法中進行訂閱主題public?BinaryObserver(Subject?subject)?{this.subject?=?subject;//?通常在構造方法中將?this?發布出去的操作一定要小心this.subject.attach(this);}//?該方法由主題類在數據變更的時候進行調用@Overridepublic?void?update()?{String?result?=?Integer.toBinaryString(subject.getState());System.out.println("訂閱的數據發生變化，新的數據處理為二進制值為："?+?result);} }public?class?HexaObserver?extends?Observer?{public?HexaObserver(Subject?subject)?{this.subject?=?subject;this.subject.attach(this);}@Overridepublic?void?update()?{String?result?=?Integer.toHexString(subject.getState()).toUpperCase();System.out.println("訂閱的數據發生變化，新的數據處理為十六進制值為："?+?result);} }

客戶端使用也非常簡單：

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

output:

訂閱的數據發生變化，新的數據處理為二進制值為：1011 訂閱的數據發生變化，新的數據處理為十六進制值為：B

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

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

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

責任鏈模式

責任鏈通常需要先建立一個單向鏈表，然后調用方只需要調用頭部節點就可以了，后面會自動流轉下去。比如流程審批就是一個很好的例子，只要終端用戶提交申請，根據申請的內容信息，自動建立一條責任鏈，然后就可以開始流轉了。

有這么一個場景，用戶參加一個活動可以領取獎品，但是活動需要進行很多的規則校驗然后才能放行，比如首先需要校驗用戶是否是新用戶、今日參與人數是否有限額、全場參與人數是否有限額等等。設定的規則都通過后，才能讓用戶領走獎品。

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

首先，我們要定義流程上節點的基類：

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

接下來，我們需要定義具體的每個節點了。

校驗用戶是否是新用戶：

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

校驗用戶所在地區是否可以參與：

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("非常抱歉，您所在的地區無法參與本次活動");}} }

校驗獎品是否已領完：

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

客戶端：

public?static?void?main(String[]?args)?{RuleHandler?newUserHandler?=?new?NewUserRuleHandler();RuleHandler?locationHandler?=?new?LocationRuleHandler();RuleHandler?limitHandler?=?new?LimitRuleHandler();//?假設本次活動僅校驗地區和獎品數量，不校驗新老用戶locationHandler.setSuccessor(limitHandler);locationHandler.apply(context); }

代碼其實很簡單，就是先定義好一個鏈表，然后在通過任意一節點后，如果此節點有后繼節點，那么傳遞下去。

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

模板方法模式

在含有繼承結構的代碼中，模板方法模式是非常常用的。

通常會有一個抽象類：

public?abstract?class?AbstractTemplate?{//?這就是模板方法public?void?templateMethod()?{init();apply();?//?這個是重點end();?//?可以作為鉤子方法}protected?void?init()?{System.out.println("init?抽象層已經實現，子類也可以選擇覆寫");}//?留給子類實現protected?abstract?void?apply();protected?void?end()?{} }

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

我們寫一個實現類：

public?class?ConcreteTemplate?extends?AbstractTemplate?{public?void?apply()?{System.out.println("子類實現抽象方法?apply");}public?void?end()?{System.out.println("我們可以把?method3?當做鉤子方法來使用，需要的時候覆寫就可以了");} }

客戶端調用演示：

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

代碼其實很簡單，基本上看到就懂了，關鍵是要學會用到自己的代碼中。

狀態模式

update: 2017-10-19

廢話我就不說了，我們說一個簡單的例子。商品庫存中心有個最基本的需求是減庫存和補庫存，我們看看怎么用狀態模式來寫。

核心在于，我們的關注點不再是 Context 是該進行哪種操作，而是關注在這個 Context 會有哪些操作。

定義狀態接口：

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

定義減庫存的狀態：

public?class?DeductState?implements?State?{public?void?doAction(Context?context)?{System.out.println("商品賣出，準備減庫存");context.setState(this);//...?執行減庫存的具體操作}public?String?toString()?{return?"Deduct?State";} }

定義補庫存狀態：

public?class?RevertState?implements?State?{public?void?doAction(Context?context)?{System.out.println("給此商品補庫存");context.setState(this);//...?執行加庫存的具體操作}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;} }

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

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

讀者可能會發現，在上面這個例子中，如果我們不關心當前 context 處于什么狀態，那么 Context 就可以不用維護 state 屬性了，那樣代碼會簡單很多。

不過，商品庫存這個例子畢竟只是個例，我們還有很多實例是需要知道當前 context 處于什么狀態的。

行為型模式總結

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

總結

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

總結

以上是生活随笔為你收集整理的3W＋字的设计模式手册的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。