java三種工廠模式

適用場合：
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.系統不該依賴於產品類實例如何被建立、組合和表達的細節


3、簡單工廠模式
顧名思義，這個模式自己很簡單，並且使用在業務較簡單的狀況下。
它由三種角色組成（關係見下面的類圖）：
一、工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯。在java中它每每由一個具體類實現。
二、抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。在java中由接口或者抽象類來實現。
三、具體產品角色：工廠類所建立的對象就是此角色的實例。在java中由一個具體類實現。
那麼簡單工廠模式怎麼用呢？我來舉個例子吧，我想這個比講一大段理論上的文字描述要容易理解的多！下面就來給那個暴發戶治病: P
在使用了簡單工廠模式後，如今暴發戶只須要坐在車裏對司機說句："開車"就能夠了。來看看怎麼實現的：
//抽象產品角色
public interface Car{
public void drive();
}
//具體產品角色
public class Benz implements Car{
public void drive() {
System.out.println("Driving Benz ");
}
}
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。 程序中類之間的關係以下：
這即是簡單工廠模式了。下面是其好處：
首先，使用了簡單工廠模式後，咱們的程序不在"有病"，更加符合現實中的狀況；並且客戶端免除了直接建立產品對象的責任，而僅僅負責"消費"產品（正如暴發戶所爲）。
下面咱們從開閉原則上來分析下簡單工廠模式。當暴發戶增長了一輛車的時候，只要符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。那麼對於產品部分來講，它是符合開閉原則的--對擴展開放、對修改關閉；可是工廠部分好像不太理想，由於每增長一輛車，都要在工廠類中增長相應的商業邏輯和判斷邏輯，這顯天然是違背開閉原則的。
對於這樣的工廠類（在咱們的例子中是爲司機師傅），咱們稱它爲全能類或者上帝類。
咱們舉的例子是最簡單的狀況，而在實際應用中，極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝類壞了，進而累壞了咱們可愛的程序員:(
正如我前面提到的簡單工廠模式適用於業務將簡單的狀況下。而對於複雜的業務環境可能不太適應阿。這就應該由工廠方法模式來出場了！！
4、工廠方法模式
先來看下它的組成吧：
一、抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
二、具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。在java中它由具體的類來實現。
三、抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。
四、具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在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)
{ }
}
}
工廠方法使用一個抽象工廠角色做爲核心來代替在簡單工廠模式中使用具體類做爲核心。讓咱們來看看工廠方法模式給咱們帶來了什麼？使用開閉原則來分析下工廠方法模式。當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有的代碼。看來，工廠方法模式是徹底符合開閉原則的！
使用工廠方法模式足以應付咱們可能遇到的大部分業務需求。可是當產品種類很是多時，就會出現大量的與之對應的工廠類，這不該該是咱們所但願的。因此我建議在這種狀況下使用簡單工廠模式與工廠方法模式相結合的方式來減小工廠類：即對於產品樹上相似的種類（通常是樹的葉子中互爲兄弟的）使用簡單工廠模式來實現。
固然特殊的狀況，就要特殊對待了：對於系統中存在不一樣的產品樹，並且產品樹上存在產品族，那麼這種狀況下就可能可使用抽象工廠模式了。
5、小結
讓咱們來看看簡單工廠模式、工廠方法模式給咱們的啓迪：
若是不使用工廠模式來實現咱們的例子，也許代碼會減小不少--只須要實現已有的車，不使用多態。可是在可維護性上，可擴展性上是很是差的（你能夠想象一下，添加一輛車後要牽動的類）。所以爲了提升擴展性和維護性，多寫些代碼是值得的。
6、抽象工廠模式
先來認識下什麼是產品族：位於不一樣產品等級結構中，功能相關聯的產品組成的家族。若是光看這句話就能清楚的理解這個概念，我不得不佩服你啊。仍是讓咱們用一個例子來形象地說明一下吧。
圖中的BmwCar和BenzCar就是兩個產品樹（產品層次結構）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個產品族。他們均可以放到跑車家族中，所以功能有所關聯。同理BmwBussinessCar和BenzSportsCar也是一個產品族。
回到抽象產品模式的話題上，能夠這麼說，它和工廠方法模式的區別就在於須要建立對象的複雜程度上。並且抽象工廠模式是三個裏面最爲抽象、最具通常性的。抽象工廠模式的用意爲：給客戶端提供一個接口，能夠建立多個產品族中的產品對象。並且使用抽象工廠模式還要知足一下條件：
1.系統中有多個產品族，而系統一次只可能消費其中一族產品
2.同屬於同一個產品族的產品以其使用。
來看看抽象工廠模式的各個角色（和工廠方法的一模一樣）：
抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。
具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。
看過了前兩個模式，對這個模式各個角色之間的協調狀況應該內心有個數了，我就不舉具體的例子了。只是必定要注意知足使用抽象工廠模式的條件哦，否則即便存在了多個產品樹，也存在產品族，可是不能使用的