目錄
- 簡單工廠模式缺陷
- 簡單工廠模式改造
- 工廠方法模式定義
- 工廠方法模式結構
- 工廠方法模式分析
- 優點分析
- 缺點分析
- 參考文獻
簡單工廠模式缺陷
大白話簡單工廠模式（Simple Factory Pattern）中通過買車的經歷解釋了簡單工廠模式，但熟悉設計模式的朋友會發現一些問題，
- 工廠類集中了所有實體（產品）的創建邏輯，一旦這個工廠不能正常作業，整個系統都會受到影響，用日產車工廠的例子來形容就是日產汽車的工廠負責所有車型的制造，當發生停電、火災等情況時，汽車無法正常制造，大大影響汽車的銷售，使企業陷入困境
- 違背“開放 - 關閉原則”，一旦添加新產品就不得不修改工廠類的邏輯，這樣就會造成工廠邏輯過于復雜，這句話的意思是當企業發布新產品，該工廠需要重新學習新車型的制造，加大工人壓力，
所以，隨著企業的發展，日產公司決定將每種車型進行分工廠制造，解決了上述問題，這種方法在設計模式中被稱為工廠方法模式
簡單工廠模式改造
下面我們從代碼的角度進行分析，4S店賣車首先要有車，這里只取日產部分車型逍客，軒逸和天籟，
代碼片段1 日產車父類，所有車型都繼承此類，
/**
* 日產車
* @author coderzcr
*/
abstract class NissanCar {
String name;
void printCar(){
System.out.println(name+"汽車已制造完成");
}
}
代碼片段2 車型：逍客
/**
* 車型：逍客
* @author coderzcr
*/
class Xtrail extends NissanCar {
Xtrail(){
this.name = "逍客";
}
}
代碼片段3 車型：軒逸
/**
* 車型：軒逸
* @author coderzcr
*/
class Sylphy extends NissanCar {
Sylphy(){
this.name = "軒逸";
}
}
代碼片段4 車型：天籟
/**
* 車型：天籟
* @author coderzcr
*/
class Altima extends NissanCar {
Altima(){
this.name="天籟";
}
}
有了具體的車型要求，我們需要對不同車型建立工廠，
代碼片段5 日產工廠父類，所有工廠都繼承此類，
/**
* 日產車工廠
* @author coderzcr
*/
public abstract class NissanCarFactory {
/**
* 生產汽車
*/
abstract NissanCar createCar() ;
}
代碼片段6 天籟工廠，
/**
* 天籟工廠
* @author coderzcr
*/
public class AltimaFactory extends NissanCarFactory {
@Override
NissanCar createCar() {
return new Altima();
}
}
代碼片段7 逍客工廠，
/**
* 逍客工廠
* @author coderzcr
*/
public class XtrailFactory extends NissanCarFactory {
@Override
NissanCar createCar() {
return new Xtrail();
}
}
代碼片段8 軒逸工廠，
/**
* 軒逸工廠
* @author coderzcr
*/
public class SylphyFactory extends NissanCarFactory {
@Override
NissanCar createCar() {
return new Sylphy();
}
}
圖1 多工廠類圖
工廠方法模式定義
工廠方法模式(Factory Method Pattern)又稱為工廠模式，也叫虛擬構造器(Virtual Constructor)模式或者多型工廠(Polymorphic Factory)模式，它屬于類創建型模式，在工廠方法模式中，工廠父類負責定義創建產品物件的公共介面，而工廠子類則負責生成具體的產品物件，這樣做的目的是將產品類的實體化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應該實體化哪一個具體產品類，
工廠父類（日產車工廠）
工廠子類（軒逸工廠、天籟工廠、逍客工廠）
即產品的制造分配給子工廠，緩解單一工廠的壓力，
工廠方法模式結構
圖2 工廠方法模式結構
工廠方法模式包含如下角色：
- Product：抽象產品
- ConcreteProduct：具體產品
- Factory：抽象工廠
- ConcreteFactory：具體工廠
工廠方法模式分析
優點分析
- 工廠方法模式的優點包括簡單工廠方法模式的優點：用戶只需要關心所需產品對應的工廠，無須關心創建細節，甚至無須知道具體產品類的類名，
- 而且解決了簡單工廠存在的不符合開閉原則問題，
在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的介面，無須修改客戶端，也無須修改其他的具體工廠和具體產品，而只要添加一個具體工廠和具體產品就可以了，這樣，系統的可擴展性也就變得非常好，完全符合“開閉原則”，
缺點分析
添加新產品時，需要添加一個具體工廠和具體產品，在一定程度上增加了系統的復雜度，有更多的類需要編譯和運行，會給系統帶來一些額外的開銷，
參考文獻
2. 工廠方法模式(Factory Method Pattern) — Graphic Design Patterns
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/32507.html
標籤：設計模式
上一篇：大話設計模式筆記（二十六）の總結