設計模式（一）工廠模式（轉）

原文地址（http://www.cnblogs.com/cxjchen/p/3143633.html）

簡單工廠模式

簡單工廠模式是工廠模式中最簡單的一種，他能夠用比較簡單的方式隱藏建立對象的細節，通常只須要告訴工廠類所須要的類型，工廠類就會返回須要的產品類，但客戶端看到的只是產品的抽象對象，無需關心究竟是返回了哪一個子類。客戶端惟一須要知道的具體子類就是工廠子類。除了這點，基本是達到了依賴倒轉原則的要求。

 

假如，咱們不用工廠類，只用AbstractProduct和它的子類，那客戶端每次使用不一樣的子類的時候都須要知道究竟是用哪個子類，當類比較少的時候還沒什麼問題，可是當類比較多的時候，管理起來就很是的麻煩了，就必需要作大量的替換，一個不當心就會發生錯誤。

而使用了工廠類以後，就不會有這樣的問題，無論裏面多少個類，我只須要知道類型號便可。不過，這裏還有一個疑問，那就是若是我每次用工廠類建立的類型都不相同，這樣修改起來的時候仍是會出現問題，仍是須要大量的替換。因此簡單工廠模式通常應該於程序中大部分地方都只使用其中一種產品，工廠類也不用頻繁建立產品類的狀況。這樣修改的時候只須要修改有限的幾個地方便可。

客戶只須要知道SimpleFactory就能夠了，使用的時候也是使用的AbstractFactory，這樣客戶端只在第一次建立工廠的時候是知道具體的細節的，其餘時候它都只知道AbstractFactory，這樣就完美的達到了依賴倒轉的原則。

經常使用的場景

例如部署多種數據庫的狀況，可能在不一樣的地方要使用不一樣的數據庫，此時只須要在配置文件中設定數據庫的類型，每次再根據類型生成實例，這樣，無論下面的數據庫類型怎麼變化，在客戶端看來都是隻有一個AbstractProduct，使用的時候根本無需修改代碼。提供的類型也能夠用比較便於識別的字符串，這樣不用記很長的類名，還能夠保存爲配置文件。

這樣，每次只須要修改配置文件和添加新的產品子類便可。

因此簡單工廠模式通常應用於多種同類型類的狀況，將這些類隱藏起來，再提供統一的接口，便於維護和修改。

優勢

1.隱藏了對象建立的細節，將產品的實例化推遲到子類中實現。

2.客戶端基本不用關心使用的是哪一個產品，只須要知道用哪一個工廠就好了，提供的類型也能夠用比較便於識別的字符串。

3.方便添加新的產品子類，每次只須要修改工廠類傳遞的類型值就好了。

4.遵循了依賴倒轉原則。

缺點

1.要求產品子類的類型差很少，使用的方法名都相同，若是類比較多，而全部的類又必需要添加一種方法，則會是很是麻煩的事情。或者是一種類另外一種類有幾種方法不相同，客戶端沒法知道是哪個產品子類，也就沒法調用這幾個不相同的方法。

2.每添加一個產品子類，都必須在工廠類中添加一個判斷分支，這違背了開放-封閉原則。

---

工廠模式

工廠模式基本與簡單工廠模式差很少，上面也說了，每次添加一個產品子類都必須在工廠類中添加一個判斷分支，這樣違背了開放-封閉原則，所以，工廠模式就是爲了解決這個問題而產生的。

既然每次都要判斷，那我就把這些判斷都生成一個工廠子類，這樣，每次添加產品子類的時候，只需再添加一個工廠子類就能夠了。這樣就完美的遵循了開放-封閉原則。但這其實也有問題，若是產品數量足夠多，要維護的量就會增長，好在通常工廠子類只用來生成產品類，只要產品子類的名稱不發生變化，那麼基本工廠子類就不須要修改，每次只須要修改產品子類就能夠了。

一樣工廠模式通常應該於程序中大部分地方都只使用其中一種產品，工廠類也不用頻繁建立產品類的狀況。這樣修改的時候只須要修改有限的幾個地方便可。

 

經常使用的場景

基本與簡單工廠模式一致，只不過是改進了簡單工廠模式中的開放-封閉原則的缺陷，使得模式更具備彈性。將實例化的過程推遲到子類中，由子類來決定實例化哪一個。

優勢

基本與簡單工廠模式一致，多的一點優勢就是遵循了開放-封閉原則，使得模式的靈活性更強。

缺點

與簡單工廠模式差很少。

---

抽象工廠模式

抽象工廠模式就變得比工廠模式更爲複雜，就像上面提到的缺點同樣，工廠模式和簡單工廠模式要求產品子類必需要是同一類型的，擁有共同的方法，這就限制了產品子類的擴展。因而爲了更加方便的擴展，抽象工廠模式就將同一類的產品子類歸爲一類，讓他們繼承同一個抽象子類，咱們能夠把他們一塊兒視做一組，而後好幾組產品構成一族。

此時，客戶端要使用時必須知道是哪個工廠而且是哪一組的產品抽象類。每個工廠子類負責產生一族產品，而子類的一種方法產生一種類型的產品。在客戶端看來只有AbstractProductA和AbstractProductB兩種產品，使用的時候也是直接使用這兩種產品。而經過工廠來識別是屬於哪一族產品。

產品ProductA_1和ProductB_1構成一族產品，對應於有Factory1來建立，也就是說Factory1老是建立的ProductA_1和ProductB_1的產品，在客戶端看來只須要知道是哪一類工廠和產品組就能夠了。通常來講， ProductA_1和ProductB_1都是適應同一種環境的，因此他們會被歸爲一族。

經常使用的場景

例如Linux和windows兩種操做系統下，有2個掛件A和B，他們在Linux和Windows下面的實現方式不一樣，Factory1負責產生能在Linux下運行的掛件A和B，Factory2負責產生能在Windows下運行的掛件A和B，這樣若是系統環境發生變化了，咱們只須要修改工廠就好了。

優勢

1.封裝了產品的建立，使得不須要知道具體是哪一種產品，只須要知道是哪一個工廠就好了。

2.能夠支持不一樣類型的產品，使得模式靈活性更強。

3.能夠很是方便的使用一族中間的不一樣類型的產品。

缺點

1.結構太過臃腫，若是產品類型比較多，或者產品族類比較多，就會很是難於管理。

2.每次若是添加一組產品，那麼全部的工廠類都必須添加一個方法，這樣違背了開放-封閉原則。因此通常適用於產品組合產品族變化不大的狀況。