爲何須要建立型模式以及簡單工廠模式(二)

 

建立型模式  

建立型模式不一樣於其餘模式,由於程序語言自己是支持建立對象實例的 
好比使用new關鍵字,好比經過反射建立,經過clone()方法建立對象
也能夠在構造方法中對建立邏輯進行干預
那麼,爲何還須要建立型模式?  

建立型概念特色

先看下前文說過的建立型模式概念
建立型模式是用來建立對象的模式,抽象了實例化的過程,封裝了建立邏輯
1. 將系統所使用的具體類的信息封裝起來
2. 隱藏了類的實例是如何被建立和組織的
 
實例的建立與使用分離
建立型模式的最基本功能就是將對象的建立和使用進行了分離
客戶端程序不在關注對象的建立,經過建立型模式進行對象的獲取
對象的建立和使用分離就能保證,對象的建立過程所有都被封裝在建立型模式之中了
再也不會散亂的存在於使用的類中, 更加便於維護,也符合依賴倒置原則
 
隱藏細節類型
一旦使用建立型模式,就 對客戶端程序隱藏了對象建立的細節
甚至能夠隱藏對象的具體類型,客戶端程序能夠僅僅面向抽象編程便可
不須要關注實際使用對象的具體類型, 下降了耦合度
 
邏輯清晰 個性化
構造方法雖然能夠封裝建立初始化邏輯
可是,構造方法全都是同樣的名字,使用建立型模式---好比工廠模式的話,你哪怕什麼都不作
只是給多種用途的構造方法設置更加有自解釋含義清晰的名字,都會 增長可讀性
另外
好比建立型的單例模式,僅僅返回一個對象的實例,若是將這種邏輯植入到構造方法中
將會顯得不三不四,由於new關鍵字構造方法就是單純的建立對象
不該該將過多的業務邏輯植入其中,它僅適合用於一些初始化操做
使用單獨的建立型模式, 邏輯更加清晰
 

場景

當你須要對客戶端程序 隱藏實際的對象類型時
當你想要 隱藏實例對象的業務建立邏輯時
當你想要 把對象的使用與建立進行分離時
等等想要 更加個性化定製對象的建立過程的時候
均可以考慮使用建立型模式   
 

簡單工廠模式


而工廠模式是簡單經常使用的一種建立型模式

概念

工廠模式是最基本的建立型模式,他有三種形式, 簡單工廠,工廠方法,抽象工廠
其中最基本的是簡單工廠形式, 簡單工廠形式簡單到不少時候不被稱爲一種模式,更像是一種經驗習慣 
簡單工廠模式藉助於工廠類的靜態方法,根據參數的不一樣狀況建立不一樣的對象
簡言之就是:有一個類,他有一個靜態方法, 這個靜態方法根據條件判斷須要建立的對象的類型
 

示例代碼

考慮下面的這種場景
有水果類(抽象類、接口)Fruit用於描述水果
另有具體的水果(實現類)蘋果Apple 橘子Orange
有一個簡單的水果店SimpleFruitFactory 可以銷售提供全部的水果
image_5be1399f_7e53
ps:包名不該該有大寫,應該儘量地使用一個單詞,實在沒法避免也不要駝峯命名,所有小寫
 
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public interface Fruit {
String description();
}
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Apple implements Fruit {
@Override
public String description() {
return "apple";
}
}
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Orange implements Fruit {
@Override
public String description() {
return "Orange";
}
}
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public enum FruitType {
APPLE,
ORANGE
}
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class SimpleFruitFactory {
public static Fruit create(FruitType fruitType){
if(fruitType.equals(FruitType.APPLE)){
return new Apple();
}else if(fruitType.equals(FruitType.ORANGE)){
return new Orange();
}
return null;
}
}
測試代碼
image_5be1399f_4868

結構

經過示例能夠看得出來,簡單工廠模式的確很簡單
關鍵點就是這個靜態create方法,內部使用if else結構或者switch結構
因爲一般都是靜態方法,因此又叫作靜態工廠方法模式
模式以下圖所示
 
image_5be1399f_34dd
工廠類根據傳入的參數決定建立哪種類型的具體產品
工廠類Factory
通常就是具體的Java實現類,在客戶端程序的請求下直接建立具體的產品,提供靜態工廠方法
抽象產品 Product
工廠所建立對象的父類或者公共接口,通常是接口或者抽象類
具體產品 ConcreteProduct
建立的具體的實例對象
 

特色

簡單工廠模式特色:
靜態方法根據參數肯定待建立對象的類型
固然,也能夠不在一個方法中處理, 也能夠建立多個方法來建立不一樣的具體產品對象
 
並且,若是產品只有一種的話,也能夠省略抽象的產品Product角色
image_5be1399f_54d5
 
簡單工廠模式 處於產品實例化的核心位置
他知道每一個產品,也就是內部直接清楚建立的對象類型
他決定哪個產品類應該被實例化
容許客戶端程序與具體產品的建立過程獨立,在系統引入新產品時,不須要修改客戶端代碼
因此說站在客戶端程序的視角看待的話, 算是符合開閉原則
對於簡單的場景,簡單工廠模式是一個不錯的選擇,既可以得到工廠型模式的優勢
又足夠的簡便清晰
 
簡單工廠模式根本特色就是一個工廠類包打天下,建立全部的產品
 

簡單工廠模式缺點

既然叫作簡單工廠模式,他的優勢之一天然是簡單
全部的建立邏輯都封裝在了一個工廠類中,以不變應萬變,全部產品的建立都盡在其中
可是 面對複雜的產品體系結構,優勢就變成了缺點 ,可能就會過於臃腫複雜不易維護複用
 
好比,若是新增長了子類,怎麼辦?
顯然須要修改工廠的靜態方法
想要擴展功能必須修改工廠類的代碼,也就是 站在工廠類的角度,不符合開閉原則
並且,面對複雜的產品體系結構,這個工廠類提供全部的建立邏輯
成了一個功能大而全的類,顯然這 違背了單一職責原則
也會更容易出現問題
相關文章
相關標籤/搜索