@aetos382さんのFactory系パターンに関するメモのつぶやき

あえとす @aetos382

Template Method パターンで基底クラスから依頼される仕事の中に、たまたま「新しいオブジェクトの生成」があるときに、それを Factory Method パターンと呼ぶ、くらいの説明でもいいのではないだろうか。

あえとす @aetos382

混乱させることを承知で敢えて言うならば、このユースケースには、Abstract Factory パターンとの類似性を見出すこともできる。

あえとす @aetos382

このクラス図を例にとると、ConcreteProduct1 と ConcreteProduct2 は、何らかの連携を取って動作するということが十分にあり得る。 ja.wikipedia.org/wiki/Abstract_…

あえとす @aetos382

たとえば、別の AnotherConcreateFactory があって、それが生成する AnotherConcreteProduct1 と AnotherConcreteProduct2 があるとする。 いずれも、Client からは Product1 と Product2 にしか見えない。

あえとす @aetos382

しかし、ConcreteProduct1 と AnotherConcreteProduct2 は組み合わせることができず、（Product1 と Product2 として扱うので）コンパイル エラーにはならないが、ランタイム エラーになるというのはあり得る話だと思う。

あえとす @aetos382

これを念頭に置いて Factory Method について考えてみる。 つまり、基底クラスは、派生クラスに依頼して作らせたインスタンスを、再度派生クラスに渡して処理させるということが、十分に考えられるだろうということである。

あえとす @aetos382

派生クラスが受け入れるオブジェクトは、静的な型は抽象的な型だが、実際の型は、自身が生成した（あるいはそれに何らかの関係がある）インスタンスでなければならない、ということはあり得る。

あえとす @aetos382

正直、このツイートから先は元の「Factory Method パターンの誤解を糺す」という目的からは外れた脱線である。 twitter.com/aetos382/statu…

あえとす @aetos382

その上で言うと、ここで見た Factory Method パターンと Abstract Factory パターンの類似性を、ひとつのパターンとしてまとめることも可能であるように思われる。 つまり、インスタンスを生成するオブジェクトと利用するオブジェクトに特定の（動的な）組み合わせの制約があるようなパターンである。

あえとす @aetos382

なお、前回も言ったけれども、Abstract Factory のパターンのエッセンスは「関連を持つ一連のインスタンスを生成すること」ではなく「クライアントから見て Factory の実際の型が隠されていること」であると考えている。 twitter.com/aetos382/statu…

あえとす @aetos382

あと、もうひとつ、看過できない過ちがあるんだけど。 Abstract Factory は「関連する複数のオブジェクトを生成するためのパターン」っていう説明ね。これはダメでしょう。

2017-11-01 02:58:16