工廠方法（Factory Method）模式又稱為虛擬構(gòu)造器（Virtual Constructor）模式或者多態(tài)工廠（Polymorphic Factory）模式，屬于類的創(chuàng)建型模式。在工廠方法模式中，父類負(fù)責(zé)定義創(chuàng)建對象的公共接口，而子類則負(fù)責(zé)生成具體的對象，這樣做的目的是將類的實(shí)例化操作延遲到子類中完成，即由子類來決定究竟應(yīng)該實(shí)體化哪一個類。
在簡單工廠模式中，一個工廠類處于對產(chǎn)品類進(jìn)行實(shí)例化的中心位置上，它知道每一個產(chǎn)品類的細(xì)節(jié)，并決定何時哪一個產(chǎn)品類應(yīng)當(dāng)被實(shí)例化。簡單工廠模式的優(yōu)點(diǎn)是能夠使客戶端獨(dú)立于產(chǎn)品的創(chuàng)建過程，并且在系統(tǒng)中引入新產(chǎn)品時無需對客戶端進(jìn)行修改，缺點(diǎn)是當(dāng)有新產(chǎn)品要加入到系統(tǒng)中時，必須對工廠類進(jìn)行修改，以加入必要的處理邏輯。簡單工廠模式的致命弱點(diǎn)就是處于核心地位的工廠類，因為一旦它無法確定要對哪個類進(jìn)行實(shí)例化時，就無法使用該模式，而工廠方法模式則可以很好地避免這一問題。
考慮這樣一個應(yīng)用程序框架（Framework），它可以用來瀏覽各種格式的文檔，如TXT、DOC、PDF、HTML等，設(shè)計時為了讓軟件的體系結(jié)構(gòu)能夠盡可能地通用，定義了Application和Document這兩個抽象父類，客戶必須通過它們的子類來處理某一具體類型的文檔。例如，要想利用該框架來編寫一個PDF文件瀏覽器，必須先定義PDFApplication和PDFDocument這兩個類，它們應(yīng)該分別繼承于Application和Document。
Application的職責(zé)是對Document進(jìn)行管理，并且在需要時創(chuàng)建它們，比如當(dāng)用戶從菜單中選擇Open或者New的時候，Application就要負(fù)責(zé)創(chuàng)建一個Document的實(shí)例。顯而易見，被實(shí)例化的特定Document子類是與具體應(yīng)用相關(guān)的，因此Application無法預(yù)測哪個Document的子類將被實(shí)例化，它只知道一個新的Document何時（When）被創(chuàng)建，但并不知道哪種（Which）具體的Document將被創(chuàng)建。此時若仍堅持使用簡單工廠模式會出現(xiàn)一個非常尷尬的局面：框架必須實(shí)例化類，但它只知道不能被實(shí)例化的抽象類。
解決的辦法是使用工廠方法模式，它封裝了哪一個Document子類將被創(chuàng)建的信息，并且能夠?qū)⑦@些信息從框架中分離出來。如圖1所示，Application的子類重新定義了Application的抽象方法createDocument()，并返回某個恰當(dāng)?shù)腄ocument子類的實(shí)例。我們稱createDocument()是一個工廠方法（factory method），因為它非常形象地描述了類的實(shí)例化過程，即負(fù)責(zé)"生產(chǎn)"一個對象。

簡單說來，工廠方法模式的作用就是可以根據(jù)不同的條件生成各種類的實(shí)例，這些實(shí)例通常屬于多個相似的類型，并且具有共同的父類。工廠方法模式將這些實(shí)例的創(chuàng)建過程封裝了起來，從而簡化了客戶程序的編寫，并改善了軟件體系結(jié)構(gòu)的可擴(kuò)展性，使得將來能夠以最小的代價加入新的子類。工廠方法這一模式適合在如下場合中運(yùn)用：
當(dāng)無法得知必須創(chuàng)建的對象屬于哪個類的時候，或者無法得知屬于哪個類的對象將被返回的時候，但前提是這些對象都符合一定的接口標(biāo)準(zhǔn)。
當(dāng)一個類希望由它的子類來決定所創(chuàng)建的對象的時候，其目的是使程序的可擴(kuò)展性更好，在加入其他類時更具彈性。
當(dāng)創(chuàng)建對象的職責(zé)被委托給多個幫助子類（helper subclass）中的某一個，并且希望將哪個子類是代理者這一信息局部化的時候。
需要說明的是，使用工廠方法模式創(chuàng)建對象并不意味著一定會讓代碼變得更短（實(shí)事上往往更長），并且可能需要設(shè)計更多的輔助類，但它的確可以靈活地、有彈性地創(chuàng)建尚未確定的對象，從而簡化了客戶端應(yīng)用程序的邏輯結(jié)構(gòu)，并提高了代碼的可讀性和可重用性。

拿一個動物工廠來舉例說明

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('魚骨頭')

下面是簡單工廠模式的實(shí)現(xiàn)：

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('魚骨頭')

看起來工廠方法模式要復(fù)雜很多啊，也沒覺得比簡單工廠模式有什么好處，為什么還要用工廠方法模式呢？ 簡單工廠模式的優(yōu)點(diǎn)很明顯，工廠函數(shù)封裝了邏輯判斷，客戶端使用負(fù)擔(dān)要小很多。相應(yīng)的問題也很明顯，要增加新的產(chǎn)品類型，就需要修改工廠函數(shù)，這違背了開閉原則。 但是工廠方法模式似乎繞了一圈又回到原始時代了，下面寫不就行了嗎，何必外面套一層Factory：

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('魚骨頭')

工廠方法模式，對于需要做強(qiáng)類型檢查的語言比如Java、C++等在組織代碼時是有好處的。對于Python這種動態(tài)語言來說，感覺體現(xiàn)不出太多價值，或許我還沒有理解工廠方法模式的真諦。