考慮一個狀況,您所經營的工廠正在生產一個新的電視機產品,現在有一個問題發生了,您的電視機產品所有的組件都可以自行生產,像是操作面版、電源、搖控裝置等等等,但螢幕卻必須依賴另一個廠商或子廠商供應,這時您怎麼辦?
您不能將生產進度停下了,相反的您必須確定一些事情,您知道有關於螢幕控制的所有介面,您可以將這些對介面的操作溝通先實現,等到螢幕到了,直接將螢幕與您的半成品組合起來,一個完整的成品即可出廠。
Factory Method模式在一個抽象類中留下某個創建元件的抽象方法沒有實作,其它與元件操作相關聯的方法都先依賴於元件所定義的介面,而不是依賴於元件的實現,當您的成品中有一個或多個元件無法確定時,您先確定與這些元件的操作介面,然後用元件的抽象操作介面先完成其它的工作,元件的實作(實現)則推遲至實現元件介面的子類完成,一旦元件加入,即可完成您的成品。
再舉一個例子,假設您要完成一個文件編輯器,您希望這個編輯器可以適用於所有類型的檔案編輯,例如RTF、DOC、TXT等等,儘管這些文件有著不同的格式,您先確定的是這些文件必然具備的一些操作介面,例如儲存、開啟、關閉等等,您用一個IDocument類型來進行操作,這麼一來這個框架就無需考慮實際的儲存、開啟等細節是如何進行的。
以 UML 類別圖來表現以下的概念:
AbstractEditor中的createDocument()方法是個抽象方法,因為框架不知道您將實現一個什麼類型的文件,這個抽象方法將推遲至繼承AbstractEditor的子類中實現。
這個架構可用以下簡單的示意程式來作示範,當中實現了一個RTFDocument,雖然在AbstractEditor中並不知道我們會套用這個RTFDocument,但您可以看到,透過多型操作,您的框架可以進行對文件的相關操作。
public abstract class AbstractEditor {
private IDocument document;
public abstract IDocument createDocument();
public void newDocument() {
document = createDocument();
document.open();
}
public void saveDocument() {
if(document != null)
document.save();
}
public void closeDocument() {
if(document != null)
document.close();
}
}
public interface IDocument {
public void open();
public void save();
public void close();
}
public class RTFEditor extends AbstractEditor {
public IDocument createDocument() {
return new RTFDocument();
}
}
public class RTFDocument implements IDocument {
public RTFDocument() {
System.out.println("建立RTF文件");
}
public void open() {
System.out.println("開啟文件");
}
public void save() {
System.out.println("儲存文件");
}
public void close() {
System.out.println("關閉文件");
}
}
將Factory Method的結構繪出如下:
Factory Method中的AbstractOperator中擁有一個抽象的factoryMethod()方法,它負責生成一個IProduct類型的物件,由於目前還不知道將如何實現這個類型,所以將之推遲至子類別中實現,在AbstractOperator中先實現IProduct操作介面溝通的部份,只要介面統一了,利用多型操作即可完成各種不同的IProduct類型之物件操作。
也就是說,對AbstractOperator來說,其操作的IProduct是可以抽換的。