工廠方法模式 建立型 設計模式(三)

 
工廠方法模式是簡單工廠模式的進一步抽象
工廠方法模式既保持了簡單工廠模式的優勢,又克服了他的缺點
如不清楚簡單工廠模式,能夠查看前一篇
他是怎麼作到的呢?那就是:
核心的工廠角色,再也不是具體的工廠,也就是再也不負責全部具體產品的建立,進一步轉變爲抽象角色。
他僅僅提供具體工廠子類必須實現的接口  ,再也不關心應該實例化哪一個具體的產品類
具體建立的工做的細節所有交給子類工廠去作
簡言之, 從一個類包打天下(簡單工廠模式),轉換爲兄弟姐妹一塊兒上(工廠方法)

意圖

定義一個用於建立對象的接口,讓子類決定實例化哪個類
工廠方法模式使一個類的實例化,延時到其子類(就是在說,子類負責具體產品類的實例化)
別名:虛構造器
 

結構

image_5be8fa74_7142
 
抽象產品Product
產品抽象角色,工廠建立具體的對象的超類或共同接口
具體產品ConcreteProduct
實現了抽象產品Product,ConcreteProduct1 和ConcreteProduct2爲具體的產品
抽象工廠Creator
工廠模式的核心,與應用程序無關,全部的工廠都須要實現抽象工廠角色
具體工廠ConcreteCreator
實現了工廠接口的具體的Java類,用於產生具體的產品
 
工廠模式相對於簡單工廠模式,產品側的結構形式不變
而對於工廠,變化很清晰明顯
再也不是單一的Java類承擔全部的對象建立職責
而是存在工廠的體系結構
Creator做爲建立工廠的抽象角色,提供了建立協議,也就是一個方法,約定了咱們將要建立什麼範疇的產品
ConcreteCreator1和ConcreteCreator2 是具體的工廠,他們都實現Creator,針對不一樣的產品有不一樣的工廠 
也就是 產品等級結構是什麼樣的,就有一個相似結構的工廠等級結構
對應着的工廠建立對應着的產品
就像上圖中那樣,兩個圈中的層級結構是對稱的,一 一對應的
Creator對應Product
ConcreteCreator1對應ConcreteProduct1
ConcreteCreator2對應ConcreteProduct2
......
 
 

示例代碼

仍是以水果的爲例
Fruit Apple Orange與簡單工廠模式中同樣
此時,再也不是一個水果店賣全部的水果,而是不一樣的水果店銷售不一樣的水果
因此對應水果這種產品的等級結構,也有對應的工廠等級結構
Factory以及 AppleFactory和 OrangeFactory
image_5be8fa74_2504
Fruit Apple 和Orange與簡單工廠中的代碼相同,請參見上一篇文章,再也不贅述
package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public interface Factory {
Fruit create();
}

 

package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class AppleFactory implements Factory {
@Override
public Fruit create() {
return new Apple();
}
}

 

package factory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class OrangeFactory implements Factory {
@Override
public Fruit create() {
return new Orange();
}
}

 

測試代碼
image_5be8fa74_11cd
 
工廠方法模式的特色就是平行的等級結構 ,也就是工廠與產品有相對應的層級結構
而不是像簡單工廠模式中那樣,一個全能類包攬全部建立邏輯
 

對比

工廠方法模式,再也不將邏輯都集中在一個具體的工廠類上
而是藉助於抽象的工廠角色Creator,他是一個抽象角色,全部的工廠建立行爲分佈於他的實現類上
是簡單工廠模式的進一步抽象
 
對於工廠模式來講,若是省略抽象角色Creator,也就好像成了一個或者多個的簡單工廠模式
每一個工廠相似一個簡單工廠模式
因此 某種程度上說,簡單工廠模式是工廠方法模式的一個簡化形式或者說特例形式
 
工廠方法模式構造了一個建立對象的工廠框架
與產品等級結構對應的工廠等級結構不就是相等於一個建立框架嘛
由不一樣的子類工廠來具體化對象的建立
工廠方法模式還有一個名字叫作 多態性工廠模式
由於具體的工廠都有共同的接口或者共同的抽象父類,具體產品對象由具體的工廠子類建立
建立一個Creator引用指向實際的Creator子類實例,實際建立的對象根據工廠的多態性產生
 
若是系統須要加入一個新的產品時,只須要加入一個新的產品類以及對應的工廠類便可
不須要修改已有的抽象工廠角色,也不必修改其餘的具體的工廠角色
更不必修改客戶端的代碼,因此知足了開閉原則
並且 , 每一個工廠生產一種對應的產品,也符合單一職責原則 
 
在實踐中隨着業務模式的深刻變得複雜, 若是有多個簡單工廠模式,若是他們在某些方面有共性
也是能夠考慮將多個簡單工廠模式的應用提高爲工廠模式的

總結

工廠模式構造了一個與產品等級結構相同的工廠結構,每一個子類工廠建立對應的具體產品
工廠模式是簡單模式的進一步抽象
因此想要理解工廠模式只須要理解清楚簡單工廠模式便可
工廠模式就是把簡單工廠模式中的一類多能,上帝模式,轉換爲多個工廠類實例分攤職責
能夠認爲簡單工廠模式至關於封建專制,皇帝一我的說了算
工廠模式就至關於民主制度下了,你們羣策羣力一塊兒討論,每一個人負責一塊
 
抽象工廠角色Creator,可使用接口也可使用抽象類(不要用具體的類,由於這自己就是一個抽象角色)
若是具體的工廠之間有相同的邏輯
那麼這些邏輯應該被提取到抽象類中
不然,就應該使用接口的形式做爲抽象工廠角色Creator和抽象產品角色Product
 
須要注意的是,有不少類提供了不少的方法都可以返回一個具體的對象
好比toString方法,返回一個String
那些算是工廠模式麼?
嚴格的說那些並不屬於工廠方法模式
方法是業務邏輯處理,重點在於業務邏輯,而不在於對象的建立
出發點邏輯思想不是一回事,固然,這只是我的見解,是否是都沒什麼很大爭執的必要
相關文章
相關標籤/搜索