上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

DI vs SL [2008/02/28 (木)]

DIとは…宮崎県知事HigashiKokubaruの言ったDogenkasentoIkanの略ではない。かの有名なプログラマMartinFowlerの言ったDependencyInjectionの略である。

いきなりですが、MartinFowlerは本当すごいと思うこの頃。プログラマとしてのセンスももちろん、何より右往左往する開発者の世論をいい方向に引っ張っていく所がかっくいい。POJOも彼が作った言葉らしい。…ちなみにおいらの場合、会社でどんなに提案してもほぼ全て却下…。社内では技術的には良いほうだった…。て事は…発言力が無いのか人格が無いのか…。人としてそっちの方がどうかと…みたいな…ぼろーん。

そんな暗い話は置いといて…実はついさっきまでDI大嫌いだった…。ServiceLocatorの方がはるかに柔軟だろう…と。オートワイヤリングっていうのかな?勝手につながっていくあれが嫌で嫌で。もちろん何でも自動でやってくれるのは大いに嬉しい。ただ、全自動でこちらの割り込む隙が少なそう。機能追加したいならライブラリの開発者に頼むしかない、そういうライブラリは何ていうか最初楽だけど将来が不安…そんな大学四回生(おいらの場合はそうだった)…みたいな。(そういう意味ではJPAを初めとする最近のORMappingもなんとかしてほしい)

で、何を見落としていたのかと言うと、ServiceLocatorの場合、最初から特定のServiceLocatorを想定してサービスを取り込む部品を設計する必要がある。つまり、どこの馬の骨か分からない部品はサービスの取り込み先として選べない。一方、DependencyInjectionの場合、依存性を注入する先の部品のコンストラクタやゲッタセッタを解析して依存性を注入する。つまり、DpendencyInjectionを意識して作りこまれた部品でなくても注入先として選べる場合が多い。
もち、柔軟性は劣るのだけど、このフットワークの軽さは最近の色んなライブラリが群雄割拠する時代には非常に有利に働く。そんなこんなでDIを取り入れたフレームワークが沢山でてきた…て事のようだ。(…なので、JavaEEは注入先が限定されているので利用価値が半減してる…標準を確立する意味としてはServiceLocatorの方が大きいはず(泣))

で、何で今頃そんな話に気付いたかと言うと…以前MartinFowlerのホームページを見た時は、苦手な英語を辞書片手に読んだからでした。分からない所は全て読み飛ばしてたみたい…。何と今日、日本語訳を発見!助かった~。。。


http://kakutani.com/trans/fowler/injection.html
スポンサーサイト

役に立ったらぽちっとよろしく。 人気ブログランキングへ

コメント
この記事へのコメント
コメントを投稿する

トラックバック
この記事のトラックバックURL
この記事へのトラックバック
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。