遅刻してしまいましたが、ひがさんも遅刻された(?)ようで意外と発表の最初のほうから聞くことが出来ました。DIコンテナの存在がパターン(ここではGoFの23パターン)に対してどのような影響を与えるかという内容。私にとってはGoFのパターンを別の視点から見るいい機会になりました。やはり生成系のパターンは軒並みDIコンテナが代替する感じですね。参加者の数がいつになく多く(過去最多らしい)、ひがさんパワーに脱帽です。おそらく初めてパターンWGに来られた方も多かったのではないでしょうか。
#以下追記。議事録のページからリンクされたので(^^;)
ひがさんにとってコンポーネントとは「オブジェクトが単体であれ、複数であれ、ある一定の機能を提供しているもの」。
発表後のQ&Aにてインタフェース中心の設計のほうがソースが追いにくい(Eclipseなどを使ってソースを追いかけるとすぐにインタフェースにぶつかってしまい逆引きが進まない)という意見がありました。これに対するひがさんの答えはS2においては大体インタフェースと実装の数の比率は1:1なので類推が効くというものだったような...(すみません、うろ覚えです)。
ひがさん曰く、「DIコンテナが使えないかな、と考えてみよう」。こう考えてみると、資料の30ページ、StateパターンにもDIコンテナは適用できるかもと考えました。StateパターンのConcreteStateの方は状態を持たずに振る舞いのみという実装もあるので、その場合にはConcreteStateオブジェクトはしばしばSingletonに当てはまるとGoF本にも書いてあるからです。たとえば結城さんの本のサンプルはSingletonで実装されています。このような場合にはStateに応じた振る舞いの実装クラスの変更が楽になるのでDIコンテナ向きかなと考えます。
参考URL
- http://c2.com/cgi/wiki?StatePattern
- http://c2.com/cgi/wiki?StateHasNoState
- http://c2.com/cgi/wiki?ContextParameter
ただ、DIコンテナに関しては、手段の目的化にならないように気をつけたいと思います。DIコンテナを使うのが目的ではなくて、目的に対してアプローチする際にDIコンテナもその選択肢の一つとなるのだと考えます。DIコンテナを強力なカードとして選択肢に入れておくのは、これからの開発現場において重要になるのではないでしょうか。
