適用場合：
7.3　工廠模式的適用場合

創建新對象最簡單的辦法是使用new關鍵字和具體類。只有在某些場合下，創建和維護對象工廠所帶來的額外復雜性才是物有所值。本節概括了這些場合。

7.3.1　動態實現

如果需要像前面自行車的例子一樣，創建一些用不同方式實現同一接口的對象，那么可以使用一個工廠方法或簡單工廠對象來簡化選擇實現的過程。這種選擇可以是明確進行的也可以是隱含的。前者如自行車那個例子，顧客可以選擇需要的自行車型號；而下一節所講的XHR工廠那個例子則屬于后者，該例中所返回的連接對象的類型取決于所探查到的帶寬和網絡延時等因素。在這些場合下，你通常要與一系列實現了同一個接口、可以被同等對待的類打交道。這是javaScript中使用工廠模式的最常見的原因。

7.3.2　節省設置開銷

如果對象需要進行復雜并且彼此相關的設置，那么使用工廠模式可以減少每種對象所需的代碼量。如果這種設置只需要為特定類型的所有實例執行一次即可，這種作用尤其突出。把這種設置代碼放到類的構造函數中并不是一種高效的做法，這是因為即便設置工作已經完成，每次創建新實例的時候這些代碼還是會執行，而且這樣做會把設置代碼分散到不同的類中。工廠方法非常適合于這種場合。它可以在實例化所有需要的對象之前先一次性地進行設置。無論有多少不同的類會被實例化，這種辦法都可以讓設置代碼集中在一個地方。

如果所用的類要求加載外部庫的話，這尤其有用。工廠方法可以對這些庫進行檢查并動態加載那些未找到的庫。這些設置代碼只存在于一個地方，因此以后改起來也方便得多。

7.3.3　用許多小型對象組成一個大對象

工廠方法可以用來創建封裝了許多較小對象的對象?？紤]一下自行車對象的構造函數。自行車包含著許多更小的子系統：車輪、車架、傳動部件以及車閘等。如果你不想讓某個子系統與較大的那個對象之間形成強耦合，而是想在運行時從許多子系統中進行挑選的話，那么工廠方法是一個理想的選擇。使用這種技術，某天你可以為售出的所有自行車配上某種鏈條，要是第二天找到另一種更中意的鏈條，可以改而采用這個新品種。實現這種改變很容易，因為這些自行車類的構造函數并不依賴于某種特定的鏈條品種。本章后面rss閱讀器的例子演示了工廠模式在這方面的用途。


工廠模式主要是為創建對象提供了接口。工廠模式按照《Java與模式》中的提法分為三類：
1. 簡單工廠模式(Simple Factory)
2. 工廠方法模式(Factory Method)
3. 抽象工廠模式(Abstract Factory)
這三種模式從上到下逐步抽象，并且更具一般性。還有一種分類法，就是將簡單工廠模式看為工廠方法模式的一種特例，兩個歸為一類。下面是使用工廠模式的兩種情況：
1.在編碼時不能預見需要創建哪種類的實例。
2.系統不應依賴于產品類實例如何被創建、組合和表達的細節


三、簡單工廠模式
顧名思義，這個模式本身很簡單，而且使用在業務較簡單的情況下。
它由三種角色組成（關系見下面的類圖）：
1、工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯。在java中它往往由一個具體類實現。
2、抽象產品角色：它一般是具體產品繼承的父類或者實現的接口。在java中由接口或者抽象類來實現。
3、具體產品角色：工廠類所創建的對象就是此角色的實例。在java中由一個具體類實現。
那么簡單工廠模式怎么用呢？我來舉個例子吧，我想這個比講一大段理論上的文字描述要容易理解的多！下面就來給那個暴發戶治病: P
在使用了簡單工廠模式后，現在暴發戶只需要坐在車里對司機說句："開車"就可以了。來看看怎么實現的：
//抽象產品角色
public interface Car{
public void drive();
}
//具體產品角色
public class Benz implements Car{
public void drive() {
System.out.}
}
public class Bmw implements Car{
public void drive() {
System.out.println("Driving Bmw ");
}
}
。。。（奧迪我就不寫了:P）
//工廠類角色
public class Driver{
//工廠方法
//注意 返回類型為抽象產品角色
public static Car driverCar(String s)throws Exception {
//判斷邏輯，返回具體的產品角色給Client
if(s.equalsIgnoreCase("Benz")) return new Benz();
else if(s.equalsIgnoreCase("Bmw"))
return new Bmw();
......
else throw new Exception();
。。。
//歡迎暴發戶出場......
public class Magnate{
public static void main(String[] args){
try{
//告訴司機我今天坐奔馳
Car car = Driver.driverCar("benz");
//下命令：開車
car.drive();
。。。
如果將所有的類放在一個文件中，請不要忘記只能有一個類被聲明為public。 程序中類之間的關系如下：
這便是簡單工廠模式了。下面是其好處：
首先，使用了簡單工廠模式后，我們的程序不在"有病"，更加符合現實中的情況；而且客戶端免除了直接創建產品對象的責任，而僅僅負責"消費"產品（正如暴發戶所為）。
下面我們從開閉原則上來分析下簡單工廠模式。當暴發戶增加了一輛車的時候，只要符合抽象產品制定的合同，那么只要通知工廠類知道就可以被客戶使用了。那么對于產品部分來說，它是符合開閉原則的--對擴展開放、對修改關閉；但是工廠部分好像不太理想，因為每增加一輛車，都要在工廠類中增加相應的商業邏輯和判斷邏輯，這顯自然是違背開閉原則的。
對于這樣的工廠類（在我們的例子中是為司機師傅），我們稱它為全能類或者上帝類。
我們舉的例子是最簡單的情況，而在實際應用中，很可能產品是一個多層次的樹狀結構。由于簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝類壞了，進而累壞了我們可愛的程序員:(
正如我前面提到的簡單工廠模式適用于業務將簡單的情況下。而對于復雜的業務環境可能不太適應阿。這就應該由工廠方法模式來出場了??！
四、工廠方法模式
先來看下它的組成吧：
1、抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
2、具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。在java中它由具體的類來實現。
3、抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。
4、具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。
來用類圖來清晰的表示下的它們之間的關系：
我們還是老規矩使用一個完整的例子來看看工廠模式各個角色之間是如何來協調的。話說暴發戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機師傅了，什么車它都要記得，維護，都要經過他來使用！于是暴發戶同情他說：看你跟我這么多年的份上，以后你不用這么辛苦了，我給你分配幾個人手，你只管管好他們就行了！于是，工廠方法模式的管理出現了。代碼如下：
//抽象產品角色，具體產品角色與簡單工廠模式類似，只是變得復雜了些，這里略。
//抽象工廠角色
public interface Driver{
public Car driverCar();
}
public class BenzDriver implements Driver{
public Car driverCar(){
return new Benz();
}
}
public class BmwDriver implements Driver{
public Car driverCar() {
return new Bmw();
}
}
......//應該和具體產品形成對應關系，這里略...
//有請暴發戶先生
public class Magnate
{
public static void main(String[] args)
{
try{
Driver driver = new BenzDriver();
Car car = driver.driverCar();
car.drive();
}catch(Exception e)
{ }
}
}
工廠方法使用一個抽象工廠角色作為核心來代替在簡單工廠模式中使用具體類作為核心。讓我們來看看工廠方法模式給我們帶來了什么？使用開閉原則來分析下工廠方法模式。當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那么就可以被客戶使用，而不必去修改任何已有的代碼?？磥?，工廠方法模式是完全符合開閉原則的！
使用工廠方法模式足以應付我們可能遇到的大部分業務需求。但是當產品種類非常多時，就會出現大量的與之對應的工廠類，這不應該是我們所希望的。所以我建議在這種情況下使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對于產品樹上類似的種類（一般是樹的葉子中互為兄弟的）使用簡單工廠模式來實現。
當然特殊的情況，就要特殊對待了：對于系統中存在不同的產品樹，而且產品樹上存在產品族，那么這種情況下就可能可以使用抽象工廠模式了。
五、小結
讓我們來看看簡單工廠模式、工廠方法模式給我們的啟迪：
如果不使用工廠模式來實現我們的例子，也許代碼會減少很多--只需要實現已有的車，不使用多態。但是在可維護性上，可擴展性上是非常差的（你可以想象一下，添加一輛車后要牽動的類）。因此為了提高擴展性和維護性，多寫些代碼是值得的。
六、抽象工廠模式
先來認識下什么是產品族：位于不同產品等級結構中，功能相關聯的產品組成的家族。如果光看這句話就能清楚的理解這個概念，我不得不佩服你啊。還是讓我們用一個例子來形象地說明一下吧。
圖中的BmwCar和BenzCar就是兩個產品樹（產品層次結構）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個產品族。他們都可以放到跑車家族中，因此功能有所關聯。同理BmwBussinessCar和BenzSportsCar也是一個產品族。
回到抽象產品模式的話題上，可以這么說，它和工廠方法模式的區別就在于需要創建對象的復雜程度上。而且抽象工廠模式是三個里面最為抽象、最具一般性的。抽象工廠模式的用意為：給客戶端提供一個接口，可以創建多個產品族中的產品對象。而且使用抽象工廠模式還要滿足一下條件：
1.系統中有多個產品族，而系統一次只可能消費其中一族產品
2.同屬于同一個產品族的產品以其使用。
來看看抽象工廠模式的各個角色（和工廠方法的如出一轍）：
抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。
具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。
看過了前兩個模式，對這個模式各個角色之間的協調情況應該心里有個數了，我就不舉具體的例子了。只是一定要注意滿足使用抽象工廠模式的條件哦，不然即使存在了多個產品樹，也存在產品族，但是不能使用的