工廠模式簡述

代碼的優化離不開設計模式的使用，今天主要介紹一下工廠模式：

工廠模式概念

　　實例化對象，用工廠方法代替new操作

 　工廠模式包括工廠方法模式、抽象工廠模式

什么情況用
有一組相似的對象要創建
編碼時不能預見創建哪一些實例
考慮代碼的拓展性
低耦合，一個對象的改變不影響以來他的對象

 

具體實例

模擬需求：需要生產寶馬、奔馳、奧迪

原始的做法：存在BMW、AUDI個類，通過new的方式創建多個對象

public class BMW { 

　　public BMW(){
　　　　System.out.println("這是-->BMW");
　　}
}

public class AUDI {
　　public AUDI(){
　　　　System.out.println("這是-->AUDI");
　　}
}


public class {
public static void main(String[] args) {
　　BMW bmw = new BMW();
　　AUDI audi = new AUDI();
}
}

 

 

 

 

 

 

 

 

 

 

 

 

 

客戶需要知道怎么去創建一款車,客戶和車就緊密耦合在一起了.為了降低耦合,就出現了工廠類,

把創造車的操作細節都放到了工廠里面去,客戶直接使用工廠的創建工廠方法,傳入想要的車型號就行了,而不必去知道創建的細節.這就是工業革命了：

簡單工廠模式

即我們建立一個工廠類方法來制造新的對象

 

 產品類：

 

public interface Car {
　　public void carBrand();
}

public class AUDI implements Car {
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->AUDI");
　　}
}

public class BMW implements Car{
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->BMW");
　　}
}

 

 

 

 

 

 

 

 

 

 

 

 

工廠類

public class CarFactory {
public Car creatCar(String carType){
　　switch (carType ) {
　　case "bmw":
　　　　return new BMW();
　　case "audi":
　　　　return new AUDI();

　　default:
　　break;
　　}
　　return null;
　　}
}

 

 

 

 

 

 

 

 

 

 

客戶端

public class Test {
CarFactory  factory = new CarFactory();

 　　factory.creatCar("bmw");

 　　 factory.creatCar("audi");
}

 

 

 

 

 

 

簡單工廠模式又稱靜態工廠方法模式。重命名上就可以看出這個模式一定很簡單。它存在的目的很簡單：定義一個用於創建對象的接口。 
      先來看看它的組成： 
         1) 工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯，用來創建產品
         2) 抽象產品角色：它一般是具體產品繼承的父類或者實現的接口。         
         3) 具體產品角色：工廠類所創建的對象就是此角色的實例。在Java中由一個具體類實現。 

 

 

下面我們從開閉原則（對擴展開放；對修改封閉）上來分析下簡單工廠模式。當客戶不再滿足現有的車種類的時候，想要一種速度快的新型車，只要這種車符合抽象產品制定的合同，那么只要通知工廠類知道就可以被客戶使用了。所以對產品部分來說，它是符合開閉原則的；但是工廠部分好像不太理想，因為每增加一種新型車，都要在工廠類中增加相應的創建業務邏輯（createCar(String carType)方法需要新增case），這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類，我們稱它為全能類或者上帝類。 
        我們舉的例子是最簡單的情況，而在實際應用中，很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝累壞了，也累壞了我們這些程序員。
        於是工廠方法模式作為救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增加該車種類型對應工廠類的實現,這樣工廠的設計就可以擴展了,而不必去修改原來的代碼。
五、工廠方法模式 
        工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它可以被子類繼承。這樣在簡單工廠模式里集中在工廠方法上的壓力可以由工廠方法模式里不同的工廠子類來分擔。 
工廠方法模式組成： 
       1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 
       2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。 
       3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。 
       4)具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。 
       工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的“上帝類”。正如上面所說，這樣便分擔了對象承受的壓力；而且這樣使得結構變得靈活 起來——當有新的產品產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那么就可以被客戶使用，而不必去修改任何已有 的代碼。可以看出工廠角色的結構也是符合開閉原則的！ 

代碼如下： 

 產品類：

 

public interface Car {
　　public void carBrand();
}

public class AUDI implements Car {
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->AUDI");
　　}
}

public class BMW implements Car{
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->BMW");
　　}
}

 

 

 

 

 

 

 

 

 

 

 

 

工廠類

public interface CarFactory {
　　public Car creatCar();

}

 

public class BMWFactory implements CarFactory {
　　@Override
　　public Car creatCar() {
　　　　return new BMW();
　　}

　}

 public class AUDIFactory implements CarFactory{

　　@Override
　　public Car creatCar() {
　　　　return new AUDI();
　　}
　　}

 

 

 

 

 

 

 

 

 

 

 

 

 　　

 

 

客戶端

public class Test {
public static void main(String[] args) {
　　BMWFactory bmwFactory = new BMWFactory();
　　Car bwm = bmwFactory.creatCar();
　　AUDIFactory audiFactory = new AUDIFactory();
　　　　Car audi = audiFactory.creatCar();
　　　　}
　　}

 

 

 

 

 

 

這里還可以使用家java的反射技術實現工廠模式

產品類：

 

public interface Car {
　　public void carBrand();
}

public class AUDI implements Car {
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->AUDI");
　　}
}

public class BMW implements Car{
　　@Override
　　public void carBrand() {
　　　　System.out.println("這是-->BMW");
　　}
}

 

 

 

 

 

 

 

 

 

 

 

 

工廠類

public class CarFactory {
public Car creatCar(String carType) throws IOException {
　　Car car = null;
　　　try {
　　　　PropertiesReader propertiesReader = new PropertiesReader();
　　　　Map<String, String> carClassMap = propertiesReader.getProperties();
　　　　String carClass = carClassMap.get(carType);
　　　　car = (Car) Class.forName(carClass).newInstance();
　　} catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) {
　　// TODO Auto-generated catch block
　　e.printStackTrace();
　　}

　　　　return car;

}

 //讀取配置java類文件信息

public class PropertiesReader {
　　　　public Map<String,String> getProperties() throws IOException{
　　　　Properties props= new Properties();
　　　　Map<String,String> map = new HashMap<String,String>();

　　InputStream in = getClass().getResourceAsStream("type.properties");
　　　　props.load(in);

　　Map<String, String> map1 = new HashMap<String, String>((Map) props);
　　　　return map1;
　　　　}
}

//配置文件內容

bmw=com.hand.car.BMW
audi=com.hand.car.AUDI

 

 

 

 

 

 

 

 

 

 

 

 　　

 

 

 

 

 

 

 

 

 

客戶端

public class Test {

public static void main(String[] args) throws IOException {
　　　　CarFactory carFactory = new CarFactory();
　　　　Car bmw = carFactory.creatCar("bmw");
　　　　bmw.carBrand();
　　　　}
　　}

 

 

 

 

 

 

 

  

 

 工廠方法模式仿佛已經很完美的對對象的創建進行了包裝，使得客戶程序中僅僅處理抽象產品角色提供的接口，但使得對象的數量成倍增長。當產品種類非常多時，會出現大量的與之對應的工廠對象，這不是我們所希望的。

參考http://blog.csdn.NET/hguisu/article/details/7505909

 以上就是簡單工廠模式。