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 回答