簡單工廠模式、工廠方法模式、抽象工廠模式 、策略模式及策略與工廠之間的區別
一.前言
話說十年前，有一個爆發戶，他家有三輛汽車（Benz（賓士）、Bmw（寶馬）、Audi（奧迪）），還僱了司機為他開車。不過，爆發戶坐車時總是這樣：上Benz車後跟司機說“開賓士車！”，坐上Bmw後他說“開寶馬車！”，坐上 Audi後他說“開奧迪車！”。
你一定說：這人有病！直接說開車不就行了？！而當把這個爆發戶的行為放到我們程式語言中來，我們發現C語言一直是通過這種方式來坐車的
幸運的是這種有病的現象在OO語言中可以避免了。下面以Java語言為基礎來引入我們本文的主題：工廠模式！
二.簡介
工廠模式主要是為建立物件提供了介面。工廠模式按照《Java與模式》中的提法分為三類：
- 簡單工廠模式(Simple Factory)
- 工廠方法模式(Factory Method)
- 抽象工廠模式(Abstract Factory)
這三種模式從上到下逐步抽象，並且更具一般性。還有一種分類法，就是將簡單工廠模式看為工廠方法模式的一種特例，兩個歸為一類。兩者皆可，這本為使用《Java與模式》的分類方法。
在什麼樣的情況下我們應該記得使用工廠模式呢？大體有兩點：
1.在編碼時不能預見需要建立哪種類的例項。
2.系統不應依賴於產品類例項如何被建立、組合和表達的細節
工廠模式能給我們的OOD、OOP帶來哪些好處呢？？
三.簡單工廠模式
這個模式本身很簡單而且使用在業務較簡單的情況下。一般用於小專案或者具體產品很少擴充套件的情況（這樣工廠類才不用經常更改）。
它由三種角色組成：
工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯，根據邏輯不同，產生具體的工廠產品。如例子中的Driver類。
抽象產品角色：它一般是具體產品繼承的父類或者實現的介面。由介面或者抽象類來實現。如例中的Car介面。
具體產品角色：工廠類所建立的物件就是此角色的例項。在java中由一個具體類實現，如例子中的Benz、Bmw類。
來用類圖來清晰的表示下的它們之間的關係：
下面就來給那個暴發戶治病：在使用了簡單工廠模式後，現在暴發戶只需要坐在車裡對司機說句：“開車”就可以了。來看看怎麼用程式碼實現的：（為方便起見，所有的類放在一個檔案中，故有一個類被宣告為public）
//抽象產品
abstract class Car{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class Benz extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class Bmw extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//簡單工廠
class Driver{
public static Car createCar(String car){
Car c = null;
if("Benz".equalsIgnoreCase(car))
c = new Benz();
else if("Bmw".equalsIgnoreCase(car))
c = new Bmw();
return c;
}
}
//老闆
public class BossSimplyFactory {
public static void main(String[] args) throws IOException {
//老闆告訴司機我今天坐賓士
Car car = Driver.createCar("benz");
car.setName("benz");
//司機開著賓士出發
car.drive();
}如果老闆要坐奧迪，同理。
這便是簡單工廠模式了。那麼它帶了了什麼好處呢？
首先，符合現實中的情況；而且客戶端免除了直接建立產品物件的責任，而僅僅負責“消費”產品（正如暴發戶所為）。
下面我們從開閉原則上來分析下簡單工廠模式。當暴發戶增加了一輛車的時候，只要符合抽象產品制定的合同，那麼只要通知工廠類知道就可以被客戶使用了。（即建立一個新的車類，繼承抽象產品Car）那麼 對於產品部分來說，它是符合開閉原則的——對擴充套件開放、對修改關閉；但是工廠類不太理想，因為每增加一輛車，都要在工廠類中增加相應的商業邏輯和判 斷邏輯，這顯自然是違背開閉原則的。
而在實際應用中，很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝類壞了。
正如我前面提到的簡單工廠模式適用於業務簡單的情況下或者具體產品很少增加的情況。而對於複雜的業務環境可能不太適應了。這就應該由工廠方法模式來出場了！！
四.工廠方法模式
抽象工廠角色： 這是工廠方法模式的核心，它與應用程式無關。是具體工廠角色必須實現的介面或者必須繼承的父類。在java中它由抽象類或者介面來實現。
具體工廠角色：它含有和具體業務邏輯有關的程式碼。由應用程式呼叫以建立對應的具體產品的物件。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的介面。在java中一般有抽象類或者介面來實現。
具體產品角色：具體工廠角色所建立的物件就是此角色的例項。在java中由具體的類來實現。
來用類圖來清晰的表示下的它們之間的關係：
話說暴發戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機師傅了，什麼車它都要記得，維護，都要經過他來使用！於是暴發戶同情他說：我給你分配幾個人手，你只管管好他們就行了！於是工廠方法模式的管理出現了。程式碼如下：
//抽象產品
abstract class Car{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class Benz extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class Bmw extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//抽象工廠
abstract class Driver{
public abstract Car createCar(String car) throws Exception;
}
//具體工廠（每個具體工廠負責一個具體產品）
class BenzDriver extends Driver{
public Car createCar(String car) throws Exception {
return new Benz();
}
}
class BmwDriver extends Driver{
public Car createCar(String car) throws Exception {
return new Bmw();
}
}
//老闆
public class Boss{
public static void main(String[] args) throws Exception {
Driver d = new BenzDriver();
Car c = d.createCar("benz");
c.setName("benz");
c.drive();
}
}使用開閉原則來分析下工廠方法模式。當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就可以被客戶使用，而不必去修改任何已有的程式碼。（即當有新產品時，只要建立並基礎抽象產品；新建具體工廠繼承抽象工廠；而不用修改任何一個類）工廠方法模式是完全符合開閉原則的！
使用工廠方法模式足以應付我們可能遇到的大部分業務需求。但是當產品種類非常多時，就會出現大量的與之對應的工廠類，這不應該是我們所希望的。所以我建議在這種情況下使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對於產品樹上類似的種類（一般是樹的葉子中互為兄弟的）使用簡單工廠模式來實現。
當然特殊的情況，就要特殊對待了：對於系統中存在不同的產品樹，而且產品樹上存在產品族（下一節將解釋這個名詞）。那麼這種情況下就可能可以使用抽象工廠模式了。
五、小結
讓我們來看看簡單工廠模式、工廠方法模式給我們的啟迪：
如果不使用工廠模式來實現我們的例子，也許程式碼會減少很多——只需要實現已有的車，不使用多型。但是在可維護性上，可擴充套件性上是非常差的（你可以想象一下新增一輛車後要牽動的類）。因此為了提高擴充套件性和維護性，多寫些程式碼是值得的。
六、抽象工廠模式
先來認識下什麼是產品族： 位於不同產品等級結構中，功能相關聯的產品組成的家族。
圖中的BmwCar和BenzCar就是兩個產品樹（產品層次結構）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個產品族。他們都可以放到跑車家族中，因此功能有所關聯。同理BmwBussinessCar和BenzBusinessCar也是一個產品族。
可以這麼說，它和工廠方法模式的區別就在於需要建立物件的複雜程度上。而且抽象工廠模式是三個裡面最為抽象、最具一般性的。抽象工廠模式的用意為：給客戶端提供一個介面，可以建立多個產品族中的產品物件。
而且使用抽象工廠模式還要滿足一下條件：
1.系統中有多個產品族，而系統一次只可能消費其中一族產品
2.同屬於同一個產品族的產品以其使用。
來看看抽象工廠模式的各個角色（和工廠方法的如出一轍）：
抽象工廠角色： 這是工廠方法模式的核心，它與應用程式無關。是具體工廠角色必須實現的介面或者必須繼承的父類。在java中它由抽象類或者介面來實現。
具體工廠角色：它含有和具體業務邏輯有關的程式碼。由應用程式呼叫以建立對應的具體產品的物件。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的介面。在java中一般有抽象類或者介面來實現。
具體產品角色：具體工廠角色所建立的物件就是此角色的例項。在java中由具體的類來實現。
//抽象產品（Bmw和Audi同理）
abstract class BenzCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品（Bmw和Audi同理）
class BenzSportCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzSportCar-----------------------");
}
}
class BenzBusinessCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzBusinessCar-----------------------");
}
}
abstract class BmwCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BmwSportCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwSportCar-----------------------");
}
}
class BmwBusinessCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwBusinessCar-----------------------");
}
}
abstract class AudiCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class AudiSportCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiSportCar-----------------------");
}
}
class AudiBusinessCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiBusinessCar-----------------------");
}
}
//抽象工廠
abstract class Driver3{
public abstract BenzCar createBenzCar(String car) throws Exception;
public abstract BmwCar createBmwCar(String car) throws Exception;
public abstract AudiCar createAudiCar(String car) throws Exception;
}
//具體工廠
class SportDriver extends Driver3{
public BenzCar createBenzCar(String car) throws Exception {
return new BenzSportCar();
}
public BmwCar createBmwCar(String car) throws Exception {
return new BmwSportCar();
}
public AudiCar createAudiCar(String car) throws Exception {
return new AudiSportCar();
}
}
class BusinessDriver extends Driver3{
public BenzCar createBenzCar(String car) throws Exception {
return new BenzBusinessCar();
}
public BmwCar createBmwCar(String car) throws Exception {
return new BmwBusinessCar();
}
public AudiCar createAudiCar(String car) throws Exception {
return new AudiBusinessCar();
}
}
//老闆
public class BossAbstractFactory {
public static void main(String[] args) throws Exception {
Driver3 d = new BusinessDriver();
AudiCar car = d.createAudiCar("");
car.drive();
}
}其中：BenzSportCar和BenzBusinessCar屬於產品樹；同理BmwSportCar和BmwBusinessCar。而BenzSportCar和BmwSportCar和AudiSportCar屬於產品族。
所以抽象工廠模式一般用於具有產品樹和產品族的場景下。
抽象工廠模式的缺點：如果需要增加新的產品樹，那麼就要新增三個產品類，比如VolvoCar，VolvoSportCar,VolvoSportCar，並且要修改三個工廠類。這樣大批量的改動是很醜陋的做法。
所以可以用簡單工廠配合反射來改進抽象工廠：
UML圖略。
abstract class BenzCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BenzSportCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzSportCar-----------------------");
}
}
class BenzBusinessCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzBusinessCar-----------------------");
}
}
abstract class BmwCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BmwSportCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwSportCar-----------------------");
}
}
class BmwBusinessCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwBusinessCar-----------------------");
}
}
abstract class AudiCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class AudiSportCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiSportCar-----------------------");
}
}
class AudiBusinessCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiBusinessCar-----------------------");
}
}
/**
* 簡單工廠通過反射改進抽象工廠及其子工廠
* @author Administrator
*
*/
class Driver3{
public static BenzCar createBenzCar(String car) throws Exception {
return (BenzCar) Class.forName(car).newInstance();
}
public static BmwCar createBmwCar(String car) throws Exception {
return (BmwCar) Class.forName(car).newInstance();
}
public static AudiCar createAudiCar(String car) throws Exception {
return (AudiCar) Class.forName(car).newInstance();
}
}
//客戶端
public class SimpleAndAbstractFactory {
public static void main(String[] args) throws Exception {
AudiCar car = Driver3.createAudiCar("com.java.pattendesign.factory.AudiSportCar");
car.drive();
}
}策略模式
舉例：匯出成EXCEL，WORD，PDF檔案的功能，這三類匯出雖然具體操作略有不同，但是大部分都相同。
策略模式與工廠模式從uml圖上來說，基本一致。只是強調的封裝不同。我們以工廠模式和策略模式的比較來講解策略模式。
工廠模式我們可以做如下理解：假設有Audi的公司生產汽車，它掌握一項核心的技術就是生產汽車，另一方面，它生產的汽車是有不同型號的，並且在不同的生產線上進行組裝。當客戶通過銷售部門進行預定後，Audi公司將在指定的生產線上為客戶生產出它所需要的汽車。
策略(Strategy)模式在結構上與工廠模式類似，唯一的區別是工廠模式例項化一個產品的操作是在服務端來做的，換句話說客戶端傳達給服務端的只是某種標識，服務端根據該標識例項化一個物件。而策略模式的客戶端傳達給服務端的是一個例項，服務端只是將該例項拿過去在服務端的環境裡執行該例項的方法。這就好比一個對汽車不甚瞭解的人去買車，他在那一比劃，說要什麼什麼樣的，銷售部門根據他的這個“比劃”來形成一份訂單，這就是工廠模式下的工作方式。而策略模式下那個顧客就是個行家，他自己給出了訂單的詳細資訊，銷售部門只是轉了一下手就交給生產部門去做了。通過兩相對比，我們不難發現，採用工廠模式必須提供足夠靈活的銷售部門，如果使用者有了新的需求，銷售部門必須馬上意識到這樣才可以做出合適的訂單。所以倘一款新車出來了，生產部門和銷售部門都需要更新，對顧客來說也需要更新對新車的描述所以需要改動的地方有三處。而策略模式中的銷售部門工作比較固定，它只負責接受訂單並執行特定的幾個操作。當一款新車出來時，只需要對服務端的生產部門和客戶端的程式碼進行更新，而不需要更新銷售部門的程式碼。
技術支援： 簡單工廠和策略的基礎都是因為面向物件的封裝與多型。他們實現的思想都是先設定一個抽象的模型並從該模型派生出符合不同客戶需求的各種方法，並加以封裝。
工廠模式和策略模式的區別在於例項化一個物件的位置不同，對工廠模式而言，例項化物件是放在服務端的，即放在了工廠類裡面；
而策略模式例項化物件的操作在客戶端，服務端的“銷售部門”只負責傳遞該物件，並在服務端的環境裡執行特定的操作。。。
工廠模式要求服務端的銷售部門足夠靈敏，而策略模式由於對策略進行了封裝，所以他的銷售部門比較傻，需要客戶提供足夠能區分使用哪種策略的引數，而這最好的就是該策略的例項了。
//抽象產品
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//銷售部門----服務端
class CarContext {
AudiCar audiCar = null;
public CarContext(AudiCar audiCar) {
this.audiCar = audiCar;
}
public void orderCar(){
this.audiCar.makeCar();
}
}
//客戶----客戶端（這個客戶是內行，什麼都懂，他說我要A6，銷售部門立刻給他a6，所以銷售部門不用很懂）
public class SimplyFactoryAndStrategy2 {
public static void main(String[] args) throws IOException {
//客戶說我要什麼什麼樣子的車子，銷售人員才知道他要什麼樣子的車子
AudiCar car = new AudiA6();
car.setName("a6");
CarContext context = new CarContext(car);
context.orderCar();
}
}
//工廠模式---與上面的策略模式比較
//抽象產品
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//簡單工廠---銷售部門----服務端
class CarFactroy{
public static AudiCar createCar(String car){
AudiCar c = null;
if("A6".equalsIgnoreCase(car))
c = new AudiA6();
else if("A4".equalsIgnoreCase(car))
c = new AudiA4();
return c;
}
}
//客戶----客戶端（這個客戶是外行，什麼都不懂，只要隨便描述下車，銷售部門才能知道他要那款車，所以銷售部門比較牛）
public class SimplyFactoryAndStrategy {
public static void main(String[] args) throws IOException {
System.out.print("請輸入您要坐的車：（A6、A4）");
String carName = new BufferedReader(new InputStreamReader(System.in)).readLine();
//客戶說我要什麼什麼樣子的車子，銷售人員才知道他要什麼樣子的車子
AudiCar car = CarFactroy.createCar(carName);
car.setName(carName);
car.makeCar();
}
}策略模式的優缺點
策略模式的主要優點有：
1.策略類之間可以自由切換，由於策略類實現自同一個抽象，所以他們之間可以自由切換。
2.易於擴充套件，增加一個新的策略對策略模式來說非常容易，基本上可以在不改變原有程式碼的基礎上進行擴充套件。
3.避免使用多重條件，如果不使用策略模式，對於所有的演算法，必須使用條件語句進行連線，通過條件判斷來決定使用哪一種演算法，在上一篇文章中我們已經提到，使用多重條件判斷是非常不容易維護的。
策略模式的缺點主要有兩個：
1.維護各個策略類會給開發帶來額外開銷，可能大家在這方面都有經驗：一般來說，策略類的數量超過5個，就比較令人頭疼了。
2.必須對 客戶端（呼叫者）暴露所有的策略類，因為使用哪種策略是由客戶端來決定的，因此，客戶端應該知道有什麼策略，並且瞭解各種策略之間的區別，否則，後果很嚴 重。例如，有一個排序演算法的策略模式，提供了快速排序、氣泡排序、選擇排序這三種演算法，客戶端在使用這些演算法之前，是不是先要明白這三種演算法的適用情況？ 再比如，客戶端要使用一個容器，有連結串列實現的，也有陣列實現的，客戶端是不是也要明白連結串列和陣列有什麼區別？就這一點來說是有悖於迪米特法則的。
適用場景
做面向物件設計的，對策略模式一定很熟悉，因為它實質上就是面向物件中的繼承和多型，在看完策略模式的通用程式碼後，我想，即使之前從來沒有聽說過策略模式，在開發過程中也一定使用過它吧？至少在在以下兩種情況下，大家可以考慮使用策略模式，
1.幾個類的主要邏輯相同，只在部分邏輯的演算法和行為上稍有區別的情況。
2.有幾種相似的行為，或者說演算法，客戶端需要動態地決定使用哪一種，那麼可以使用策略模式，將這些演算法封裝起來供客戶端呼叫。
策略模式是一種簡單常用的模式，我們在進行開發的時候，會經常有意無意地使用它，一般來說，策略模式不會單獨使用，跟模版方法模式、工廠模式等混合使用的情況比較多。
大粒度的 if –else if…可以使用 工廠+策略模式搞定。