設計模式 三種工廠模式（Factory）

三種工廠模式

工廠模式能夠分爲三類：

• 簡單工廠模式（Simple Factory）
• 工廠方法模式（Factory Method）
• 抽象工廠模式（Abstract Factory）

這三種模式從上到下逐步抽象，而且更具通常性。
GOF在《設計模式》一書中將工廠模式分爲兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。將簡單工廠模式（Simple Factory）看爲工廠方法模式的一種特例，二者歸爲一類。
這三種工廠模式在設計模式的分類中都屬於建立型模式。

建立型模式(Creational Pattern)對類的實例化過程進行了抽象，可以將軟件模塊中對象的建立和對象的使用分離。爲了使軟件的結構更加清晰，外界對於這些對象只須要知道它們共同的接口，而不清楚其具體的實現細節，使整個系統的設計更加符合單一職責原則。

建立型模式在建立什麼(What)，由誰建立(Who)，什麼時候建立(When)等方面都爲軟件設計者提供了儘量大的靈活性。

建立型模式隱藏了類的實例的建立細節，經過隱藏對象如何被建立和組合在一塊兒達到使整個系統獨立的目的。

工廠模式是建立型模式中比較重要的。工廠模式的主要功能就是幫助咱們實例化對象的。之因此名字中包含工廠模式四個字，是由於對象的實例化過程是經過工廠實現的，是用工廠代替new操做的。

這樣作的好處是封裝了對象的實例化細節，尤爲是對於實例化較複雜或者對象的生命週期應該集中管理的狀況。會給你係統帶來更大的可擴展性和儘可能少的修改量。

接下來咱們分別介紹下這三種工廠模式。

簡單工廠模式
簡單工廠模式又叫作靜態工廠方法（Static Factory Method）模式。簡單工廠模式是由一個工廠對象決定建立出哪種產品類的實例。簡單工廠模式是工廠模式家族中最簡單實用的模式，能夠理解爲是不一樣工廠模式的一個特殊實現。

簡單工廠模式總結

工廠類是整個簡單工廠模式的關鍵。包含了必要的邏輯判斷，根據外界給定的信息，決定究竟應該建立哪一個具體類的對象。經過使用工廠類，外界能夠從直接建立具體產品對象的尷尬局面擺脫出來，僅僅須要負責「消費」對象就能夠了。而沒必要管這些對象究竟如何建立及如何組織的。明確了各自的職責和權利，有利於整個軟件體系結構的優化。

可是因爲工廠類集中了全部實例的建立邏輯，違反了高內聚責任分配原則，將所有建立邏輯集中到了一個工廠類中；它所能建立的類只能是事先考慮到的，若是須要添加新的類，則就須要改變工廠類了。

當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不一樣條件建立不一樣實例的需求．這種對條件的判斷和對具體產品類型的判斷交錯在一塊兒，很難避免模塊功能的蔓延，對系統的維護和擴展很是不利；

這些缺點在工廠方法模式中獲得了必定的解決。

 

工廠方法模式

工廠方法模式(Factory Method Pattern)又稱爲工廠模式，也叫虛擬構造器(Virtual Constructor)模式或者多態工廠(Polymorphic Factory)模式，它屬於類建立型模式。

工廠方法模式是一種實現了「工廠」概念的面向對象設計模式。就像其餘建立型模式同樣，它也是處理在不指定對象具體類型的狀況下建立對象的問題。

工廠方法模式用途

工廠方法模式和簡單工廠模式雖然都是經過工廠來建立對象，他們之間最大的不一樣是——工廠方法模式在設計上徹底徹底符合「開閉原則」。

在如下狀況下可使用工廠方法模式：

一個類不知道它所須要的對象的類：在工廠方法模式中，客戶端不須要知道具體產品類的類名，只須要知道所對應的工廠便可，具體的產品對象由具體工廠類建立；客戶端須要知道建立具體產品的工廠類。

一個類經過其子類來指定建立哪一個對象：在工廠方法模式中，對於抽象工廠類只須要提供一個建立產品的接口，而由其子類來肯定具體要建立的對象，利用面向對象的多態性和里氏代換原則，在程序運行時，子類對象將覆蓋父類對象，從而使得系統更容易擴展。

將建立對象的任務委託給多個工廠子類中的某一個，客戶端在使用時能夠無須關心是哪個工廠子類建立產品子類，須要時再動態指定，可將具體工廠類的類名存儲在配置文件或數據庫中。

 

工廠方法模式包含以下角色：

Product：抽象產品（Operation）

ConcreteProduct：具體產品(OperationAdd)

Factory：抽象工廠(IFactory)

ConcreteFactory：具體工廠(AddFactory)

 

抽象工廠模式

抽象工廠模式(Abstract Factory Pattern)：提供一個建立一系列相關或相互依賴對象的接口，而無須指定它們具體的類。抽象工廠模式又稱爲Kit模式，屬於對象建立型模式。

抽象工廠模式提供了一種方式，能夠將同一產品族的單獨的工廠封裝起來。在正常使用中，客戶端程序須要建立抽象工廠的具體實現，而後使用抽象工廠做爲接口來建立這一主題的具體對象。客戶端程序不須要知道（或關心）它從這些內部的工廠方法中得到對象的具體類型，由於客戶端程序僅使用這些對象的通用接口。抽象工廠模式將一組對象的實現細節與他們的通常使用分離開來。

抽象工廠模式用途

抽象工廠模式和工廠方法模式同樣，都符合開放-封閉原則。可是不一樣的是，工廠方法模式在增長一個具體產品的時候，都要增長對應的工廠。可是抽象工廠模式只有在新增一個類型的具體產品時才須要新增工廠。也就是說，工廠方法模式的一個工廠只能建立一個具體產品。而抽象工廠模式的一個工廠能夠建立屬於一類類型的多種具體產品。工廠建立產品的個數介於簡單工廠模式和工廠方法模式之間。

在如下狀況下可使用抽象工廠模式：

一個系統不該當依賴於產品類實例如何被建立、組合和表達的細節，這對於全部類型的工廠模式都是重要的。

系統中有多於一個的產品族，而每次只使用其中某一產品族。

屬於同一個產品族的產品將在一塊兒使用，這一約束必須在系統的設計中體現出來。

系統提供一個產品類的庫，全部的產品以一樣的接口出現，從而使客戶端不依賴於具體實現。

抽象工廠模式實現方式

抽象工廠模式包含以下角色：

AbstractFactory(抽象工廠)：用於聲明生成抽象產品的方法

ConcreteFactory(具體工廠)：實現了抽象工廠聲明的生成抽象產品的方法，生成一組具體產品，這些產品構成了一個產品族，每個產品都位於某個產品等級結構中；

AbstractProduct(抽象產品)：爲每種產品聲明接口，在抽象產品中定義了產品的抽象業務方法；

Product(具體產品)：定義具體工廠生產的具體產品對象，實現抽象產品接口中定義的業務方法。

 

三種工廠模式對比

簡單工廠模式的優缺點

• 優勢：
  • 一、屏蔽產品的具體實現，調用者只關心產品的接口。
  • 二、實現簡單
• 缺點：
  • 一、增長產品，須要修改工廠類，不符合開放-封閉原則
  • 二、工廠類集中了全部實例的建立邏輯，違反了高內聚責任分配原則

工廠方法模式的優缺點

• 優勢：
  • 一、繼承了簡單工廠模式的優勢
  • 二、符合開放-封閉原則
• 缺點：
  • 一、增長產品，須要增長新的工廠類，致使系統類的個數成對增長，在必定程度上增長了系統的複雜性。

抽象工廠模式的優缺點

• 優勢：
  • 一、隔離了具體類的生成，使得客戶並不須要知道什麼被建立
  • 二、每次能夠經過具體工廠類建立一個產品族中的多個對象，增長或者替換產品族比較方便，增長新的具體工廠和產品族很方便；
• 缺點
  • 增長新的產品等級結構很複雜，須要修改抽象工廠和全部的具體工廠類，對「開閉原則」的支持呈現傾斜性。



簡單工廠 ： 用來生產同一等級結構中的任意產品。（對於增長新的產品，主要是新增產品，就要修改工廠類。符合單一職責原則。不符合開放-封閉原則）

工廠方法 ：用來生產同一等級結構中的固定產品。（支持增長任意產品，新增產品時不須要更改已有的工廠，須要增長該產品對應的工廠。符合單一職責原則、符合開放-封閉原則。可是引入了複雜性）

抽象工廠 ：用來生產不一樣產品族的所有產品。（增長新產品時，須要修改工廠，增長產品族時，須要增長工廠。符合單一職責原則，部分符合開放-封閉原則，下降了複雜性）

最後，三種工廠模式各有優缺點，沒有最好的，只有最合適的！

 

參考連接：https://www.hollischuang.com/archives/3709