簡單工廠模式有稱爲靜態工廠模式,屬於設計模式中的建立型模式。簡單工廠模式經過對外提供一個靜態方法來統一爲類建立實例。簡單工廠模式的目的是實現類與類之間解耦,其次是客戶端不須要知道這個對象是如何被穿建立出來的,只須要調用簡單工廠模式的方法來統一建立就能夠了,從而明確了各個類的職責。java
第一步:聲明一個抽象類(接口),以及對應的抽象方法,由實現類分別去實現這個方法。設計模式
第二步: 建立具體實現類,實現抽象方法。iphone
第三步:建立一個簡單工廠類,聲明一個靜態方法,根據傳入的不一樣的類型來肯定建立抽象類的具體實現類。ide
第四步:客戶端經過工廠類獲取實例對象。性能
下面以製造手機爲例子,在現實生活中可能有不少工廠能夠建立不一樣品牌的手機,這些工廠能夠根據不一樣的需求來建立不一樣的手機。根據上面的步驟,首先咱們須要一個抽象類,因此咱們須要知道不一樣品牌的手機其實都是屬於手機這種類別,所以咱們能夠將手機抽出來作成一個抽象類:優化
/** * 手機類 */ public interface Phone { //製造手機的方法,留給具體的實現類來製造 void create(); }
第二步咱們須要開始製造不一樣品牌的手機了:設計
製造華爲手機對象
public class Huawei implements Phone { @Override public void create() { System.out.println("====正在製造華爲手機======"); } }
蘋果手機blog
public class Iphone implements Phone { @Override public void create() { System.out.println("====正在製造蘋果手機======"); } }
第三步咱們須要建立一個工廠方法,返回手機類。具體制造什麼品牌的手機,須要根據傳進來的手機名字來決定,所以咱們能夠這麼寫:接口
public class SimpleFactory { public static Phone createPhone(String name) { if ("huawei".equals(name)) return new Huawei(); else return new Iphone(); } }
第四步,手機建立好了,咱們就可使用了,即客戶端調用工廠方法建立對象實例
public class Client {
public static void main(String[] args) {
Phone huawei = SimpleFactory.createPhone("huawei");
huawei.create();
Phone iphone = SimpleFactory.createPhone("iphone");
iphone.create();
}
}
//輸出結果
====正在製造華爲手機======
====正在製造蘋果手機======
到這裏,簡單工廠模式基本已經寫完了,仔細看會發現這種方法建立對象違反了ocp原則,每次增長不一樣品牌手機的時候都須要在工廠方法裏添加不一樣的條件判斷。若是手機品牌愈來愈多,代碼看起來很是臃腫,很不利於後期的代碼維護。所以,咱們改進一下,不要經過手機品牌名稱來判斷須要建立哪一中對象了,而是客戶端想要建立什麼對象,只須要傳入具體的實現類就能夠了,而後經過Java的反射來建立對象。
public class SimpleFactory2 { public static Phone create(Class<? extends Phone> clazz) { try { return clazz.newInstance(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } return null; } }
客戶端調用
public class Client { public static void main(String[] args) { Phone huawei = SimpleFactory2.create(Huawei.class); huawei.create(); Phone iphone = SimpleFactory2.create(Iphone.class); iphone.create(); } }
//運行結果
====正在製造華爲手機======
====正在製造蘋果手機======
通過修改以後,每次增長新的手機品牌時就不用修改工廠方法的邏輯了。可是,仍是有一個問題,就是每次建立對象都是經過反射來建立的,因此在性能上是有必定的損耗的。
一、簡單優化了軟件體系結構,明確了各自功能模塊的職責和權利
二、經過工廠類,外界不須要直接建立具體產品對象,只須要負責消費,不須要關心內部如何建立對象
一、改進前的簡單工廠模式所有建立邏輯都集中在一個工廠類中,能建立的類只能是考慮到的,若是須要添加新的類,就必須改變工廠類了
二、改進前的簡單工廠模式隨着具體產品的不斷增多,可能會出現共產類根據不一樣條件建立不一樣實例的需求,這種對條件的判斷和對具體產品類型的判斷交錯在一塊兒,很難避免功能模塊的蔓延,對系統的維護和擴展不利
三、改進後的簡單工廠模式主要是使用反射效率會低一些