0

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

我想通过工厂方法模式创建一个 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？ ）。

4

1 回答 1

1

我现在会使用您的工厂方法习语，甚至可以构建并返回适当的阅读器。这似乎是重构为模式的一个例子

于 2011-12-26T00:14:33.273 回答