0

説明は長いですが、例は非常に単純で基本的なものです。

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();
}

およびその 2 つの具象サブクラス:

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です。 ）。

4

1 に答える 1

1

今のところ、ファクトリメソッドのイディオムを使用して、適切なリーダーを構築して返すこともできます。これはパターンへのリファクタリングの例のようです

于 2011-12-26T00:14:33.273 に答える