代碼的優化離不開設計模式的使用,今天主要介紹一下工廠模式:java
工廠模式概念程序員
實例化對象,用工廠方法代替new操做設計模式
工廠模式包括工廠方法模式、抽象工廠模式ide
什麼狀況用
有一組類似的對象要建立
編碼時不能預見建立哪一些實例
考慮代碼的拓展性
低耦合,一個對象的改變不影響以來他的對象優化
具體實例ui
模擬需求:須要生產寶馬、奔馳、奧迪編碼
原始的作法:存在BMW、AUDI個類,經過new的方式建立多個對象spa
public class BMW { .net public BMW(){ |
客戶須要知道怎麼去建立一款車,客戶和車就緊密耦合在一塊兒了.爲了下降耦合,就出現了工廠類,
把創造車的操做細節都放到了工廠裏面去,客戶直接使用工廠的建立工廠方法,傳入想要的車型號就好了,而沒必要去知道建立的細節.這就是工業革命了:
簡單工廠模式
即咱們創建一個工廠類方法來製造新的對象
產品類:
public interface Car { public class AUDI implements Car { public class BMW implements Car{ |
工廠類
public class CarFactory { default: |
客戶端
public class Test { factory.creatCar("bmw"); factory.creatCar("audi"); |
簡單工廠模式又稱靜態工廠方法模式。重命名上就能夠看出這個模式必定很簡單。它存在的目的很簡單:定義一個用於建立對象的接口。
先來看看它的組成:
1) 工廠類角色:這是本模式的核心,含有必定的商業邏輯和判斷邏輯,用來建立產品
2) 抽象產品角色:它通常是具體產品繼承的父類或者實現的接口。
3) 具體產品角色:工廠類所建立的對象就是此角色的實例。在Java中由一個具體類實現。
下面咱們從開閉原則(對擴展開放;對修改封閉)上來分析下簡單工廠模式。當客戶再也不知足現有的車種類的時候,想要一種速度快的新型車,只要這種車符合抽象產品制定的合同,那麼只要通知工廠類知道就能夠被客戶使用了。因此對產品部分來講,它是符合開閉原則的;可是工廠部分好像不太理想,由於每增長一種新型車,都要在工廠類中增長相應的建立業務邏輯(createCar(String carType)方法須要新增case),這顯然是違背開閉原則的。可想而知對於新產品的加入,工廠類是很被動的。對於這樣的工廠類,咱們稱它爲全能類或者上帝類。
咱們舉的例子是最簡單的狀況,而在實際應用中,極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品,因此這可能會把咱們的上帝累壞了,也累壞了咱們這些程序員。
因而工廠方法模式做爲救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增長該車種類型對應工廠類的實現,這樣工廠的設計就能夠擴展了,而沒必要去修改原來的代碼。
5、工廠方法模式
工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性,使得它能夠被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力能夠由工廠方法模式裏不一樣的工廠子類來分擔。
工廠方法模式組成:
1)抽象工廠角色: 這是工廠方法模式的核心,它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
2)具體工廠角色:它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。
3)抽象產品角色:它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。
4)具體產品角色:具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。
工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的「上帝類」。正如上面所說,這樣便分擔了對象承受的壓力;並且這樣使得結構變得靈活 起來——當有新的產品產生時,只要按照抽象產品角色、抽象工廠角色提供的合同來生成,那麼就能夠被客戶使用,而沒必要去修改任何已有 的代碼。能夠看出工廠角色的結構也是符合開閉原則的!
代碼以下:
產品類:
public interface Car { public class AUDI implements Car { public class BMW implements Car{ |
工廠類
public interface CarFactory { }
public class BMWFactory implements CarFactory { } public class AUDIFactory implements CarFactory{ @Override
|
客戶端
public class Test { |
這裏還可使用家java的反射技術實現工廠模式
產品類:
public interface Car { public class AUDI implements Car { public class BMW implements Car{ |
工廠類
public class CarFactory { return car; } //讀取配置java類文件信息 public class PropertiesReader { //配置文件內容 bmw=com.hand.car.BMW |
客戶端
public class Test { public static void main(String[] args) throws IOException { |
工廠方法模式彷彿已經很完美的對對象的建立進行了包裝,使得客戶程序中僅僅處理抽象產品角色提供的接口,但使得對象的數量成倍增加。當產品種類很是多時,會出現大量的與之對應的工廠對象,這不是咱們所但願的。
參考http://blog.csdn.NET/hguisu/article/details/7505909
以上就是簡單工廠模式。