考虑一个状况,您所经营的工厂正在生产一个新的电视机产品,现在有一个问题发生了,您的电视机产品所有的组件都可以自行生产,像是操作面版、电源、摇控装置等等等,但荧幕却必须依赖另一个厂商或子厂商供应,这时您怎么办?
您不能将生产进度停下了,相反的您必须确定一些事情,您知道有关于荧幕控制的所有介面,您可以将这些对介面的操作沟通先实现,等到荧幕到了,直接将荧幕与您的半成品组合起来,一个完整的成品即可出厂。
Factory Method模式在一个抽象类中留下某个创建元件的抽象方法没有实作,其它与元件操作相关联的方法都先依赖于元件所定义的介面,而不是依赖于元件的实现,当您的成品中有一个或多个元件无法确定时,您先确定与这些元件的操作介面,然后用元件的抽象操作介面先完成其它的工作,元件的实作(实现)则推迟至实现元件介面的子类完成,一旦元件加入,即可完成您的成品。
再举一个例子,假设您要完成一个文件编辑器,您希望这个编辑器可以适用于所有类型的档案编辑,例如RTF、DOC、TXT等等,尽管这些文件有着不同的格式,您先确定的是这些文件必然具备的一些操作介面,例如储存、开启、关闭等等,您用一个IDocument类型来进行操作,这么一来这个框架就无需考虑实际的储存、开启等细节是如何进行的。
以 UML 类别图来表现以下的概念:
这个架构可用以下简单的示意程式来作示范,当中实现了一个RTFDocument,虽然在AbstractEditor中并不知道我们会套用这个RTFDocument,但您可以看到,透过多型操作,您的框架可以进行对文件的相关操作。
- AbstractEditor.java
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();
}
}
- IDocument.java
public interface IDocument {
public void open();
public void save();
public void close();
}
- RTFEditor.java
public class RTFEditor extends AbstractEditor {
public IDocument createDocument() {
return new RTFDocument();
}
}
- RTFDocument.java
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的结构绘出如下:
也就是说,对AbstractOperator来说,其操作的IProduct是可以抽换的。
本文介绍了 Factory Method 设计模式的应用场景与实现方式,通过电视机生产和文件编辑器的例子,阐述了如何通过定义抽象方法和接口来延迟具体产品的创建,使得框架能够独立于具体的实现。
684

被折叠的 条评论
为什么被折叠?



