練就Java24章真經—你所不知道的工廠方法

codeGoogle發表於2018-09-04

Java

前言

最近一直在Java方向奮鬥《終於，我還是下決心學Java後臺了》，今天抽空開始學習Java的設計模式了。計劃有時間就去學習，你這麼有時間，還不來一起上車嗎？

之所以要學習Java模式，是因為面試的時候有時間回答的不是太完整，面試過後才想起來如何回答。所以，我說了： 只有總結才是王道，只有總結才能提高

設計模式

其實正規的來說Java其實是23中設計模式，不過網上也有說是24種或者是26中的！設計模式不過是前人對程式碼的一種封裝。用專業的話來講：設計模式是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結

建立型模式，共五種：

1.工廠方法模式、
2.抽象工廠模式、
3.單例模式、
4.建造者模式、
5.原型模式。

結構型模式，共七種：

6.介面卡模式、
7.裝飾器模式、
8.代理模式、
9.外觀模式、
10.橋接模式、
11.組合模式、
12.享元模式。

行為型模式，共十一種：

13.策略模式、
14.模板方法模式、
15.觀察者模式、
16.迭代子模式、
17.責任鏈模式、
18.命令模式、
19.備忘錄模式、
20.狀態模式、
21.訪問者模式、
22.中介者模式、
23.直譯器模式。

今日重點：工廠方法模式

工廠模式是建立型模式之一，又稱為靜態工廠方法模式！

優點：

1.良好的封裝性，程式碼結構清晰。一個物件建立是有條件約束的，如一個呼叫者需要一個具體的產品物件，只要知道這個產品的類名（或約束字串）就可以了，不用知道建立物件的艱辛過程，減少模組間的耦合。
2.工廠方法模式的擴充套件性非常優秀。在增加產品類的情況下，只要適當地修改具體的工廠類或擴充套件一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統擴充套件。
3.遮蔽產品類。這一特點非常重要，產品類的實現如何變化，呼叫者都不需要關心，它只需要關心產品的介面，只要介面保持不表，系統中的上層模組就不要發生變化，因為產品類的例項化工作是由工廠類負責，一個產品物件具體由哪一個產品生成是由工廠類決定的。在資料庫開發中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連線資料庫，資料庫從MySql切換到Oracle，需要改動地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案例。
4.工廠方法模式是典型的解耦框架。高層模組值需要知道產品的抽象類，其他的實現類都不用關心，符合迪米特原則，我不需要的就不要去交流；也符合依賴倒轉原則，只依賴產品類的抽象；當然也符合里氏替換原則，使用產品子類替換產品父類，沒問題！

缺點：

每次增加一個產品時，都需要增加一個具體類和物件實現工廠，是的系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。

用途：

第一種情況是對於某個產品，呼叫者清楚地知道應該使用哪個具體工廠服務，例項化該具體工廠，生產出具體的產品來。Java Collection中的iterator() 方法即屬於這種情況。

第二種情況，只是需要一種產品，而不想知道也不需要知道究竟是哪個工廠為生產的，即最終選用哪個具體工廠的決定權在生產者一方，它們根據當前系統的情況來例項化一個具體的工廠返回給使用者，而這個決策過程這對於使用者來說是透明的。

典型例子： 車子繼承vehicle（車）類，有小汽車卡，公交車bus等，車子工廠實現工廠介面，工廠介面有抽象方法vehicle produce vehicle（String type）方法，車子工廠中實現工廠方法vehicle produce vehicle（String Type），方法中根據需要new新的車子。

示例程式碼：