定義
工廠方法模式使用的頻率非常高，在我們?nèi)粘５拈_發(fā)中總能見到它的身影。其定義如下：
Define an interface for creating an object, but let subclasses decide which class to instantiate.
定義一個(gè)用于創(chuàng)建對象的接口，讓子類決定實(shí)例化哪一個(gè)類。工廠方法使用一個(gè)類的實(shí)例化延遲到其子類。
工廠方法模式的通用類圖如下：
在工廠方法模式中，抽象產(chǎn)品類Product負(fù)責(zé)定義產(chǎn)品的共性，實(shí)現(xiàn)了對事物最抽象的定義；Creator為抽象創(chuàng)建類，也就是抽象工廠，具體如何創(chuàng)建產(chǎn)品類是由具體的實(shí)現(xiàn)工廠ConcreteCreator完成的。
通用框架
工廠方法模式的變種較多，我們來看一個(gè)比較實(shí)用的通用源碼。
抽象產(chǎn)品類：
public abstract class Product {
// 產(chǎn)品類的公共方法
public void bizComm() {
// 業(yè)務(wù)邏輯處理
}
// 抽象方法
public abstract void methodXXX();
}
具體產(chǎn)品類：
public class ConcreteProduct1 extends Product {
public void methodXXX() {
// 業(yè)務(wù)邏輯處理
}
}
public class ConcreteProduct2 extends Product {
public void methodXXX() {
// 業(yè)務(wù)邏輯處理
}
}
抽象工廠類
public abstract class Creator {
// 創(chuàng)建一個(gè)產(chǎn)品對象，其輸入?yún)?shù)類型可以自行設(shè)置，
// 通常為String, Enum, Class等，當(dāng)然也可以為空
public abstract <T extends Product> T createProduct(Class<T> c);
}
具體工廠類
public class ConcreteCreator extends Creator {
public <T extends Product> T createProduct(Class<T> c) {
Product product = null;
try {
product = (Product) Class.forName(c.getName()).newInstance();
} catch (Exception e) {
// 異常處理
}
return (T) product;
}
}
場景類的具體調(diào)用方法如下：
public class Client {
public static void main(String[] args) {
Creator creator = new ConcreteCreator();
Product product = creator.createProduct(ConcreteProduct1.class);
// 其他業(yè)務(wù)處理
}
}
優(yōu)點(diǎn)
首先，良好的封裝性，代碼結(jié)構(gòu)清晰，一個(gè)對象的創(chuàng)建是有條件約束的，如一個(gè)調(diào)用者需要一個(gè)具體的產(chǎn)品對象，只要知道這個(gè)產(chǎn)品的類名就可以了，不用知道創(chuàng)建對象的艱辛過程，降低模塊間的耦合。
其次，工廠方法模式的擴(kuò)展性非常優(yōu)秀，在增加產(chǎn)品類的情況下，只要適當(dāng)?shù)匦薷木唧w的工廠類或擴(kuò)展一個(gè)工廠類，就可以完成“擁抱變化”。
再次，屏蔽了產(chǎn)品類。產(chǎn)品類的實(shí)現(xiàn)如何變化，調(diào)用者都不需要關(guān)心，它只需要關(guān)心產(chǎn)品的接口，只要接口保持不變，系統(tǒng)中的上層模塊就不要發(fā)生變化。
最后，工廠方法模式是典型的解耦框架。高層模塊只需要知道產(chǎn)品的抽象類，其他實(shí)現(xiàn)類都不用關(guān)心，符合迪米特法則，我不需要的就不要去交流；也符合依賴倒置原則，只依賴產(chǎn)品類的抽象；當(dāng)然也符合里氏替換原則，使用產(chǎn)品子類替換產(chǎn)品父類。
