【デザインパターン】Factory Methodパターンでは具象クラスとの依存度を下げることはできない。

Question

デザインパターンの一つであるFactory Methodを調べていて気になった点を質問させてください。

Factoryパターンのメリット
Factory Methodに限らず、一般的にオブジェクトの生成のためのFactoryを設けることのメリットは以下の通りと認識しています。

・ インスタンスの生成処理を隠蔽化できる
・ そのためクライアントが利用したいオブジェクトの具象から分離される。（具象オブジェクトをnewしない）

interface Producer {
    // いくつかのメソッド
}
class AProducer implements Producer {
    // Producerの実装
}

// ファクトリ
class ProducerFactory() {
    public Producer createProducer() {
        return new AProducer();
    }
}

// クライアント
class Main() {
    public static void main(String[] args) {
        Producer p = ProducerFactory.createProducer()
    }
}

Factory Methodパターン
Factory Methodパターンの場合、生成したいオブジェクトの種類に応じてファクトリを用意することになるので、
「クライアントが利用したいオブジェクトの具象から分離される。」メリットを完全に失っている気がします。

※実際に利用したいオブジェクトには依存してませんが、そのオブジェクトを生成するためのファクトリに依存している（newしている）ため。利用するオブジェクトが変われば当然ファクトリも変えざるを得ず、クライアントのコードに修正が発生します。

interface Producer {
    // いくつかのメソッド
}
class AProducer implements Producer {
    // Producerの実装
}

class BProducer implements Producer {
    // Producerの実装
}

// ファクトリ
abstract class ProducerFactory {
    public abstract Producer createProducer();
}
class AProducerFactory extends ProducerFactory {
    public Producer createProducer() {
        return new AProducer();
    }
}
class BProducerFactory extends ProducerFactory {
    public Producer createProducer() {
        return new BProducer();
    }
}

// クライアント
class Main() {
    public static void main(String[] args) {
        Producer ap = new AProducerFactory().createProducer()
        Producer ap = new BProducerFactory().createProducer()
    }
}

このようにFactory Methodパターンはクライアントと具象クラスが密結合になってしまうデメリットがあると考えます。
オブジェクトの生成処理においてテンプレートメソッドを利用する場合は意味があるとは思いますが、
それ以外の場合に敢えてFactory Methodを用意するメリットはありますでしょうか？
むしろオブジェクトの生成処理は1ファクトリクラスに集約したほうが、疎結合なつくりにできるのではないかと考えています。

ご意見頂けますと幸いです。

参考
http://think-on-object.blogspot.jp/2011/11/factoryfactory-methodabstract-factory.html
http://d.hatena.ne.jp/asakichy/20090414/1239718537
http://d.hatena.ne.jp/asakichy/20090331/1238472501
http://www.nulab.co.jp/designPatterns/designPatterns2/designPatterns2-2.html

Answer 1

#結論
Factory Methodパターンはインターフェースに依存した作りにすることで、
よりメリットを享受できるようになります。

#内容
サンプルのソースコードを確認いたしましたところ、
実クラスごとにFactoryクラスを作ってしまっており、メリットが「依存性の委譲」のみになってしまっているように見えました。

interface Producer {
    // いくつかのメソッド
}
class AProducer implements Producer {
    // Producerの実装
}

class BProducer implements Producer {
    // Producerの実装
}

// ファクトリ
class ProducerFactory() {
    public Producer createProducer( String type ) {

        if ( "A".equals( type ) ) {
            // Aが指定されたのでAProducerを生成
            return new AProducer();
        }

        if ( "B".equals( type ) ) {
            // Bが指定されたのでBProducerを生成
            return new BProducer();
        }
        // 何らかのエラー処理
    }
}

// クライアント
class Main() {
    public static void main(String[] args) {
        ProducerFactory producerFactory = new ProducerFactory();
        
        // 中身はAProducer
        Producer ap = producerFactory.createProducer("A");

        // 中身はBProducer
        Producer bp = producerFactory.createProducer("B");
    }
}

このようにFactoryクラスをインターフェースに依存するように作成し、
引数で指定できるようにゆとりを持たせると、
新しくCproducerが必要になった際に、ProducerFactoryクラスの改修のみですみます。

また、Mainから見た際に、引数のみ知っていれば、実クラスのことを全く知らなくても、
オブジェクトを生成することができます。

#追記
また、JavaであればSpringBootなどのフレームワークを使用することで、コンストラクタインジェクションや、DIでFactoryクラスの生成処理を他に委譲しさらに抽象度を高めることもできます。

Comments

[maisumakun]

domのdocument.createElement()みたいに、「同じファクトリーが共通のインターフェースだけど、違う子クラスを返す」ような実装も可能ですからね。

Answer 2

クライアントと具象クラスが密結合になってしまう

本当になっていますか？Mainの側から見れば、どのファクトリーを使うにしても、「ProducerFactoryのインスタンスに対してcreateProducer()をすればProducerが生成する」という点では共通していますので、生成物をProducerとして扱えればよい場面では、ファクトリーを適宜差し替えることができます。

Producerの実際のクラスを気にするのであれば、それはもうポリモーフィズムを適用できないので、まったくの別問題です。