説明は長いですが、例は非常に単純で基本的です。パラメータ化工場メソッドパターン
実際に私はIniReaderとXmlReaderの両方のReaderのサブクラスを持っているので、FactoryメソッドパターンでReaderオブジェクトを作成したいと思います。
具体的なクラスの選択は、ファイルのタイプに基づいて実行時に行われ、将来、アプリケーションは他のファイル形式を処理する必要があります。
私の質問です：この単純な問題については、ファクトリメソッドパターンを適用しようとすると意味がありますか？
このパターンを適用しようとすると、ちょうどnew MyObject()コールを含む縮退クラスが発生しました。時には "シンプル"とは、 "クライアントを壊さずに将来容易に変更可能"を意味します。私はゲッター/セッターメソッドによく似ています。しかし、これはそうではないようです。
私の非常に基本的な実装：
public abstract class ReaderCreator {
abstract Reader create();
}
とその2つの具象サブクラス：
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 class IniReaderCreator extends ReaderCreator {
@Override Reader create() {
return new IniReader();
}
}
public class XmlReaderCreator extends ReaderCreator{
@Override Reader create() {
return new XmlReader();
}
}
この時点で、私は持っているファイルを特定し、適切なReaderCreatorをインスタンス化し、正しいリーダーをインスタンス化させる必要があります。
Iは、（したがって、メソッドが静的である必要があります）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のすべてのサブクラスは、この場合には（実装XmlReaderConstructor明らかに不合理であろうと、IniReaderとXmlReaderの間choiches意思決定アルゴリズムを再実装することを述べているので
は、パラメータ化ファクトリメソッドは、本当に別の何かでありますcreate IniReaderを返すメソッド）。