Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2004-08-21

デザインパターン

くーす本の中で、DIContainerあるいはAOPの出現によって、

GoFデザインパターンがどのように実現されるのか、

あるいはなくなるのか、まとめたいと思います。

DIとStrategyパターン

Strategyパターンは、アルゴリズムカプセル化し、

交換可能にするものですが、それをDIを使って実現するには、

どうしたら良いのでしょうか。

Strategyが静的なものなら、普通にDIするだけです。

問題は、Strategyがデータに応じて動的に変わる場合です。

その場合は、StrategyのFactoryをDIするようにします。

そして、必要なときに、データをStrategyのFactory

渡して、適切なStrategyを手に入れるのです。

Dependency Injectionパターン

Dependency Injectionパターンとは、

  1. コンポーネント同士は、インターフェースを通じてのみ会話するようにする。
    • 実装クラスに依存してはいけない。
  2. コンポーネントの生成や、依存関係の解決は、コンテナがおこなう。

ものだと、いえるのではないかと思います。

2の部分がDependency Injectionなわけですね。

1のおかげで、実装クラスを簡単に差し替えできるようになるので、

などのメリットがあります。


くーすの中に登場する幾つかの概念名前をつけて、

わかりやすくパターン化したいと思ってます。

既存のパターンも、私が勝手名前をつけたものも

あります。

分かりづらいところがあれば突っ込みよろしくお願いします。

agtagt 2004/08/21 17:36 StrategyのFactoryをDIするようにします < これいいっすね。この場合Factoryもインターフェイスですよね?

higayasuohigayasuo 2004/08/21 17:41 はい、そうです。

太田@会社太田@会社 2004/08/23 11:01 DIを使うと,間接オブジェクトのfactory, facade, singleton等が減るというのもメリットとして大きいかな〜と思いますが,どうでしょうか?

higayasuohigayasuo 2004/08/23 13:03 デザインパターンは一言ではかけないくらい変わるような気がしてます。1つずつ検証していきたいと思います。

太田@会社太田@会社 2004/08/23 13:17 おおっ,既存のJ2EE系のパターンはオセロのようにひっくり返りそうな気も・・・

Connection: close