工廠方法（Factory Method）模式又稱為虛擬構造器（Virtual Constructor）模式或者多態工廠（Polymorphic Factory）模式，屬于類的創建型模式。在工廠方法模式中，父類負責定義創建對象的公共接口，而子類則負責生成具體的對象，這樣做的目的是將類的實例化操作延遲到子類中完成，即由子類來決定究竟應該實體化哪一個類。
在簡單工廠模式中，一個工廠類處于對產品類進行實例化的中心位置上，它知道每一個產品類的細節，并決定何時哪一個產品類應當被實例化。簡單工廠模式的優點是能夠使客戶端獨立于產品的創建過程，并且在系統中引入新產品時無需對客戶端進行修改，缺點是當有新產品要加入到系統中時，必須對工廠類進行修改，以加入必要的處理邏輯。簡單工廠模式的致命弱點就是處于核心地位的工廠類，因為一旦它無法確定要對哪個類進行實例化時，就無法使用該模式，而工廠方法模式則可以很好地避免這一問題。
考慮這樣一個應用程序框架（Framework），它可以用來瀏覽各種格式的文檔，如TXT、DOC、PDF、HTML等，設計時為了讓軟件的體系結構能夠盡可能地通用，定義了Application和Document這兩個抽象父類，客戶必須通過它們的子類來處理某一具體類型的文檔。例如，要想利用該框架來編寫一個PDF文件瀏覽器，必須先定義PDFApplication和PDFDocument這兩個類，它們應該分別繼承于Application和Document。
Application的職責是對Document進行管理，并且在需要時創建它們，比如當用戶從菜單中選擇Open或者New的時候，Application就要負責創建一個Document的實例。顯而易見，被實例化的特定Document子類是與具體應用相關的，因此Application無法預測哪個Document的子類將被實例化，它只知道一個新的Document何時（When）被創建，但并不知道哪種（Which）具體的Document將被創建。此時若仍堅持使用簡單工廠模式會出現一個非常尷尬的局面：框架必須實例化類，但它只知道不能被實例化的抽象類。
解決的辦法是使用工廠方法模式，它封裝了哪一個Document子類將被創建的信息，并且能夠將這些信息從框架中分離出來。如圖1所示，Application的子類重新定義了Application的抽象方法createDocument()，并返回某個恰當的Document子類的實例。我們稱createDocument()是一個工廠方法（factory method），因為它非常形象地描述了類的實例化過程，即負責"生產"一個對象。
簡單說來，工廠方法模式的作用就是可以根據不同的條件生成各種類的實例，這些實例通常屬于多個相似的類型，并且具有共同的父類。工廠方法模式將這些實例的創建過程封裝了起來，從而簡化了客戶程序的編寫，并改善了軟件體系結構的可擴展性，使得將來能夠以最小的代價加入新的子類。工廠方法這一模式適合在如下場合中運用：
當無法得知必須創建的對象屬于哪個類的時候，或者無法得知屬于哪個類的對象將被返回的時候，但前提是這些對象都符合一定的接口標準。
當一個類希望由它的子類來決定所創建的對象的時候，其目的是使程序的可擴展性更好，在加入其他類時更具彈性。
當創建對象的職責被委托給多個幫助子類（helper subclass）中的某一個，并且希望將哪個子類是代理者這一信息局部化的時候。
需要說明的是，使用工廠方法模式創建對象并不意味著一定會讓代碼變得更短（實事上往往更長），并且可能需要設計更多的輔助類，但它的確可以靈活地、有彈性地創建尚未確定的對象，從而簡化了客戶端應用程序的邏輯結構，并提高了代碼的可讀性和可重用性。
拿一個動物工廠來舉例說明
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
class Animal(object): def eat(self, food): raise NotImplementedError()class Dog(Animal): def eat(self, food): print '狗吃', foodclass Cat(Animal): def eat(self, food): print '貓吃', foodclass AnimalFactory(object): def create_animal(self): raise NotImplementedError()class DogFactory(Animal): def create_animal(self): return Dog()class CatFactory(AnimalFactory): def create_animal(self): return Cat()def client(): animal_factory = DogFactory() animal = animal_factory.create_animal() animal.eat('肉骨頭') animal_factory = CatFactory() animal = animal_factory.create_animal() animal.eat('魚骨頭') |
下面是簡單工廠模式的實現：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
class Animal(object): def eat(self, food): raise NotImplementedError()class Dog(Animal): def eat(self, food): print '狗吃', foodclass Cat(Animal): def eat(self, food): print '貓吃', fooddef create_animal(name): if name == 'dog': return Dog() elif name == 'cat': return Cat()def client(): animal = create_animal('dog') animal.eat('肉骨頭') animal = create_animal('cat') animal.eat('魚骨頭') |
看起來工廠方法模式要復雜很多啊，也沒覺得比簡單工廠模式有什么好處，為什么還要用工廠方法模式呢？ 簡單工廠模式的優點很明顯，工廠函數封裝了邏輯判斷，客戶端使用負擔要小很多。相應的問題也很明顯，要增加新的產品類型，就需要修改工廠函數，這違背了開閉原則。 但是工廠方法模式似乎繞了一圈又回到原始時代了，下面寫不就行了嗎，何必外面套一層Factory：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class Animal(object): def eat(self, food): raise NotImplementedError()class Dog(Animal): def eat(self, food): print '狗吃', foodclass Cat(Animal): def eat(self, food): print '貓吃', fooddef client(): dog = Dog() dog.eat('肉骨頭') cat = Cat() cat.eat('魚骨頭') |
工廠方法模式，對于需要做強類型檢查的語言比如Java、C++等在組織代碼時是有好處的。對于Python這種動態語言來說，感覺體現不出太多價值，或許我還沒有理解工廠方法模式的真諦。
