Question

解释很长，但这些例子非常简单和基本。

我想通过Factory Method Pattern创建一个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");
    }
}

但这不是参数化的工厂方法，而是工厂模式的另一种“工厂方法”。
然而，在我看来，这似乎是该模式最明显的实现。我刚刚在ReaderCreator中引入了（可能在客户端中）在IniReaderCreator和XmlReaderCreator之间决定的方法。

参数化的工厂方法实际上是不同的，因为它声明ReaderCreator的所有子类重新实现了在IniReader和XmlReader之间选择的决策者算法，在这种情况下显然是荒谬的（实现{{1的XmlReaderConstructor）返回IniReader的方法？）。

Answer 1

我现在用你的工厂方法成语，甚至可能让它构建并返回适当的读者。这似乎是Refactoring To Patterns

的一个例子

参数化工厂方法模式

1 个答案: