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

あえとす @aetos382

「デザインパターンとか古の遺物」みたいな意見も聞くけど、今回、GoFの23パターンを調べてみて、全く古びてないなと思った。 まぁTemplate Methodなんかはパターンっていうほどのもんかよ？ と思うし、ObserverとかIteratorは言語に組み込まれてるけども。

あえとす @aetos382

あとは、よく似ていて違いが分かりにくいパターンもある。でも、自分の書いているコードが、これはどっちのパターンなんだろう？ とか悩む必要は全くないよね。要は「っぽさ」があればいいのよ。パターンに合致することが目的じゃないからさ。

あえとす @aetos382

そしてやっぱり、これはプログラミング初心者が教科書として学ぶべきものではない、という気がするよ。 俺自身は何を教科書に学んだのかもう覚えてないけれども。ある程度経験を積んだ上で見た方が、明らかに面白いと思うよ。

あえとす @aetos382

最後に一つ。Interpreter パターンだけは生涯使わないと思います。おしまい。寝る。

あえとす @aetos382

やはり世の中の Factory Method パターンの説明は、完全に誤りとは言えないまでも適切ではないものが大半である、という思いを新たにした。

あえとす @aetos382

この前、このあたりのスレッドでつらつらと考察していたけど、今日改めて考えた。 twitter.com/aetos382/statu…

あえとす @aetos382

まずね、GoFの23のパターンの中には、Factory MethodパターンとAbstract Factoryパターンがある。あと、23のパターンに含まれないんだけど、FactoryパターンとかSimple Factoryパターンというらしいのを一緒に紹介しているサイトもある。

2017-11-01 02:34:30

あえとす @aetos382

Factory 系パターンには、以下のものがある。 ・Factory Method パターン ・Simple Factory パターン ・Abstract Factory パターン

あえとす @aetos382

Simple Factory パターンは GoF の 23 パターンには含まれないが、しばしば一緒に解説されている。 また、この名前はウチにあった「C# デザインパターン」という本によっており、同じものが「Factory パターン」と呼ばれている場合もある。

あえとす @aetos382

ところでデザイン パターンというものは、繰り返しコードに現れる設計をまとめたもの、つまり、設計を抽象化したものである。 ここでは、パターン自体を抽象的に考えるということが重要であるということを改めて表明したい。

あえとす @aetos382

先の 3 パターンを抽象化して、便宜上 ・Factory Method パターン ・Factory Object パターン に分類する。 前者はそのまま Factory Method パターンが属し、Simple Factory パターンと Abstract Factory パターンは Factory Object パターンに属する。

あえとす @aetos382

このことは Wikipedia にも書かれている。 "Factory Method パターンは「クラスパターン」に分類されている。一方Abstract Factory パターンは「オブジェクトパターン」に分類されている。" というのがそれを指すが、ちょっとわかりにくい。 ja.wikipedia.org/wiki/Factory_M…

あえとす @aetos382

このグループ化が何を意味するかと言うと、「Factory Method と Simple Factory / Abstract Factory は全然似ていない」ということである。これ重要。

あえとす @aetos382

Factory Object パターン（Simple Factory / Abstract Factory）は「オブジェクトの新しいインスタンスを生成し、初期化し、外部に提供することを主たる責務とするオブジェクト」を導入するパターンである。

あえとす @aetos382

対して、Factory Method パターンは、Template Method パターンの特化版であり、基底クラスが必要とするオブジェクトの生成処理を派生クラスに移譲するというパターンである。ここには「オブジェクトの生成を主責務とするクラス」は存在しない。

あえとす @aetos382

では、世の中に何故、適切でない Factory Method パターンの説明が多いのかと言うと、このクラス図のせいである。 ja.wikipedia.org/wiki/Factory_M…

あえとす @aetos382

この図に「Creator」というのが登場する。この名前が良くない。このせいで、このクラスは「オブジェクトの生成を主責務とするクラス」であるという誤解を生んでいる。

あえとす @aetos382

実際にその下の Java のサンプルコードを見ると「Creator」という名前を持つクラスは無い。このサンプルコードには「オブジェクトの生成を主責務とするクラス」は登場しないのである。

あえとす @aetos382

しかしながら、世の中の多くの Factory Method のサンプルには「Factory」という名前のクラスが登場する。これはつまり「オブジェクトの生成を主責務とするクラス」である。 故に、こういうサンプルは Factory Method を誤解していると言える。

あえとす @aetos382

ただし、最初に言ったように「完全に間違いとまでは言えない」という例が多い。 何故なら、一応、オブジェクトの生成を派生クラスに移譲するようにはなっているからである。

あえとす @aetos382

このような誤解されたサンプルは何かというと、Factory Object パターンと Factory Method が融合してしまっているのである。 つまり、Factory Object を実装するための手段として Factory Method パターンを用いていると分析することができる。

あえとす @aetos382

まぁつまり、結果として書かれたサンプルコードを見ると、Factory Method になっていないとは言えない。 しかし、Factory Method のエッセンスを抽出することには失敗している。 そして、そのサンプルコードを書いた人も、おそらくは誤解している。

あえとす @aetos382

念のために言っておくと、そのような「Factory Method と Factory Object が融合したような設計がまずい」、と言っているのではないことに注意されたい。 それはあくまで「Factory Method パターンの説明としてはまずい」のであって、実際の設計として妥当かどうかはまた別の問題である。

あえとす @aetos382

ちょっと補足したくなった。 この Wikipedia のサンプルコードでは、DictionaryOrderListPrinter とか LengthOrderListPrinter といったクラスが、comparator の生成しかしていない。 そのため、結果的に見ればこれらが「オブジェクトの生成を主責務とするクラス」に見える。 twitter.com/aetos382/statu…

あえとす @aetos382

しかし、Factory Method パターンが Template Method パターンの類型であることを考えれば、もうちょっと実践的なサンプルであれば、派生クラスは他の仕事もするのではないかと考えられる。

あえとす @aetos382

つまり、現実的には、派生クラスは「オブジェクトの生成を主責務とするクラス」ではないんだよ、ということが言いたい。