設計模式（一）工廠模式

**編寫出來是為了給別人（client）呼叫的：

所以，為了簡化**的協作使用及管理維護，必須想盡辦法簡化**邏輯，實現必要的【分離】。下面我分別介紹幾種工廠模式。

我們使用手機來作為測試，首先上**圖：

public class iphone }public class huawei }public class oppo public class xiaomi public class vivo

最原始的方式：如果我們要建立多個不同品牌的手機，那麼就要new多個不同品牌的手機類，如果這樣的**提供給客戶端呼叫，必須要將所有類的名稱以及對應的方法暴露給客戶端，這樣的方式非常原始，也很簡單，但是**的邏輯不清晰，暴露的內容過多。為此，我們有乙個解決方案：抽象邏輯（抽取其中的一些邏輯），提供乙個介面這樣可以減少方法呼叫的複雜度，也便於抽象跟**管理。

**圖：

public inte***ce phone

所有手機類都實現phone 介面，然後將暴露給客戶端呼叫的邏輯都封裝在play方法裡，那麼客戶端（呼叫者）需要知道的api就減少到了兩種：phone 的介面資訊；phone 的介面有哪些實現類。

但是這種工廠模式的缺點也很大：

客戶端（呼叫者），必須知道手機類的具體名稱，如果有 1000 個手機需要呼叫，則我們需要記住 1000 個手機的名稱，這對於呼叫者來說不可能的。

客戶端的呼叫，跟提供的**是耦合的，例如有一天手機新增了乙個功能，然後我們修改了介面的方法，同時成百上千個手機類也實現了這個介面，則全部手機類都是需要修改的，其可擴充套件性就減少了，維護的成本也隨之增加了。

通過原始工廠模式的演變，為了更好的符合實際環境。

原理：通過在介面與實現類中間新增一層，來解決需要記住名稱過多和耦合問題。我們只要記住，**耦合的話，可以通過兩者之間新增一層來解決。

**圖：

public
class
phonefactory
elseif(
"vivo"
.equals
(tag)
)elseif(
"huawei"
.equals
(tag))}
}

我們在原始工廠模式的基礎上，再建立乙個phonefactory類，裡面只定義乙個專門生產手機的方法，通過客戶端呼叫者傳進來的手機品牌然後生產對應的手機。

然後客戶端呼叫者就可以直接呼叫相應的手機品牌的方法了：

phonefactory pf =
newphonefactory()
;pf.
createphone
("iphone").
play()
;pf.
createphone
("vivo").
play()
;pf.
createphone
("huawei").
play()
;

簡單工廠模式，本身已經為解耦合做出了很好的方案。但是事情都是有兩面性的，所以它也有缺點：

phonefactory類**跟phone**有耦合每次要新增/刪除/修改某乙個 phone，都需要修改 phonefactory這個類

為此，簡單工廠繼續演變，就有工廠方法模式。

在簡單工廠的基礎上，首先為 phone 專門建立乙個生產手機的工廠（父工廠）。

public inte***ce phonefactory

如果我們需要增加一款產品，比如是 iphone ，那麼，只需要建立乙個只生產 iphone 的（子）工廠就可以了；如果再增加一款產品，比如 huawei，那麼只需要增加另外一條只生產 huawei 手機的（子）工廠就可以了。

public class huaweifactory implements phonefactory

}

客戶端呼叫者，只需其中乙個手機品牌工廠實現 phone 工廠（介面）就可以了，就是乙個手機品牌對應乙個手機工廠，從而達到了解耦合。

phonefactory huaweipf =
newhuaweifactory()
;huaweipf .
createphone()
.play()
;phonefactory iphonepf =
newiphonefactory()
;iphonepf .
createphone()
.play()
;

工廠方法模式的缺點：

**容易膨脹，例如：我們每增加乙個手機產品，相應的也要增加乙個子工廠。

不容易反應產品與產品之間的關係。

事情是兩面性的，耦合解決了也會產生另外一方面的問題，所以就要根據實際情況選擇相應的對策來。就工廠方法模式來說，是目前最標準的一種工廠模式，也是應用廣泛的一種模式了。

設計模式（一） 工廠模式

設計模式 工廠設計模式 一

設計模式（一） 工廠模式

設計模式（一） 工廠模式

相關推薦

設計模式（一）工廠模式

設計模式工廠設計模式一

設計模式（一）工廠模式

設計模式（一）工廠模式