解释很长,但示例非常简单和基本。
我想通过工厂方法模式创建一个 Reader 对象,因为实际上我有一个 IniReader 和一个 XmlReader,它们都是 Reader 的子类。
具体类的选择是在运行时根据文件的类型进行的,将来应用程序应该处理其他文件格式。
我的问题是:对于这个简单的问题,尝试应用工厂方法模式是否有意义?
应用这种模式的尝试导致了只包含一个new MyObject()
调用的退化类。有时“简单”意味着“将来可以轻松更改而不会破坏客户端”,我认为 getter/setter 方法通常是单行的。但情况似乎并非如此。
我非常基本的实现:
public interface Reader {
//does nothing, it's a sample!
//obviously it would have at least a read method declaration
}
//my concrete IniReader
public class IniReader implements Reader{}
//my concrete XmlReader
public class XmlReader implements Reader{}
然后,在我的工厂方法模式的核心,我有一个抽象的 ReaderCreator:
public abstract class ReaderCreator {
abstract Reader create();
}
及其两个具体子类:
public class IniReaderCreator extends ReaderCreator {
@Override Reader create() {
return new IniReader();
}
}
public class XmlReaderCreator extends ReaderCreator{
@Override Reader create() {
return new XmlReader();
}
}
此时,我需要确定我拥有的文件,实例化正确的 ReaderCreator 并让它实例化正确的阅读器。
我很想为 ReaderCreator 抽象创建一个参数化的工厂方法(因此该方法必须是静态的),如下所示:
public static ReaderCreator newInstance(File f) {
if (f.getName().endsWith(".ini")) {
return new IniReaderCreator();
} else if (f.getName().endsWith(".xml")) {
return new XmlReaderCreator();
} else {
throw new IllegalArgumentException("File type not handled");
}
}
但这不是参数化的工厂方法,而是工厂模式的另一种“工厂方法”习语。
尽管如此,在我看来,这似乎是该模式最明显的实现。我刚刚将在 IniReaderCreator 和 XmlReaderCreator 之间决定的方法(可能在客户端)引入 ReaderCreator。
参数化工厂方法确实有些不同,因为它声明 ReaderCreator 的所有子类都重新实现了在 IniReader 和 XmlReader 之间选择的决策者算法,在这种情况下显然是荒谬的(实现create
返回 IniReader 的方法的 XmlReaderConstructor? )。