参数化工厂方法模式

解释很长，但实例非常简单和基本。参数化工厂方法模式

我想通过Factory Method Pattern创建一个Reader对象，因为实际上我有一个IniReader和一个XmlReader，都是Reader的子类。
具体类的选择是在运行时根据文件类型进行的，将来应用程序应处理其他文件格式。

我的问题是：对于这个简单的问题，尝试应用工厂方法模式是否合理？

应用此模式的尝试导致退化类仅包含new MyObject()调用。有时候，“简单”意味着“在未打破客户的情况下在未来可以轻易改变”，我认为这种吸气/调节方法通常是一线式的。但是这似乎并非如此。

我非常基本的实现：

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之间choiches决策者算法，在这种情况下会明显荒谬的（即实现一个XmlReaderConstructor create方法返回一个IniReader？）。

来源

2011-12-25 AgostinoX

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

来源

2011-12-26 00:14:33

参数化工厂方法模式

回答

相关问题