デザインパターンというものは、日ごろ普通に使ってるしくみに名前がついているだけで、あえて新しい気づきなどにはつながらないということがあるが、そのしくみに名前がついているものだから、その名前と意味を知っている人同士の会話はスムースに運び、もしかしたら会話の中で新しい気づきに繋がってしまうかも知れないという可能性もあり、知っていて損はないのである。
今回はコンポジットパターンについてのメモ。書いておかないと絶対また忘れるし。
コンポジットパターンというものは、言ってしまえば木構造のデータ構造を設計する上での一つの定石ということになろう。即ち右図のような関係。以上。つまりそれはLeafとComposite（Componentを入れられるもの）を、等しく扱えるような共有の操作を組み込みたいものだから、二つともComponentを継承した形で設計しようというもの。そして（ルートノードは別だけど）、Component、つまりLeafかCompositeには必ず一つ親Compositeがいるし、Composite には複数の子Componentつまり子Leafか子Compositeが付き得るという様子を表している。
例えばMFCとかではウィンドウもボタンも全てCWndを継承して作られていて、つまりCWndのメソッドがボタンだろうがウィンドウだろうが共通に使えるし、ウィンドウは複数のボタンやウィンドウ自身をそのチャイルドとして持てるようになっているという例がそう。
あるいは3Dのシーングラフとかで全てのモデルはModelクラスを継承して作られていて、任意のモデルは任意の複数モデルをチャイルドとして持つことができるなんていう設計もコンポジットパターンと言えるわけです。って、口でそう言えばいいじゃんっていう噂もある。
でも「え、ちょっと待って、コンポジットパターンで言うところのComponentはどれにあたるのよ」だとか、「TakochanクラスはCompositeパターンで言うところのComponentです。」「ああ、そういうことか、Takochanて何かと思ったよ」なんて言う会話、したことないけど、もしかしたら会話の内容が簡潔になってるのかも知れない。それは職場環境によるのだろうな。
