參數化工廠方法模式

解釋很長，但實例非常簡單和基本。參數化工廠方法模式

我想通過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

參數化工廠方法模式

回答

相關問題