参数化工厂方法模式

Question

解释很长，但示例非常简单和基本。

我想通过工厂方法模式创建一个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之间选择的decision-maker算法，在这种情况下显然是荒谬的(实现返回IniReader的create方法的XmlReaderConstructor？)。

Answer 1

我现在会使用你的工厂方法习惯用法，甚至可以让它构造并返回适当的阅读器。这看起来像是Refactoring To Patterns的一个例子