DIコンテナ【Dependency Injection Container】
DIコンテナは，「DI（Dependency Injection：依存性の注入）」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。 DIは，コンポーネント（クラス）間の依存関係をソースコードから取り除くことで，プログラムの実行時までコンポーネント同士が依存関係を持たないようにするデザインパターンです。 例えば，あるクラスAの中で別のクラスBのインスタンスを生成して利用しているとき，AはBに強く依存してしまっています。つまり，Bを別のクラスに差し替えたときなどにはAも変更しなければなりません。このような依存関係は，AとBを別の人が作っている場合などに特に困ります。 こうした依存性をクラスから取り除くのがDIパターンです。Bへの依存性をAから排除するには，まずBの機能を抽象化したインタフェースIを定義し，Iを実装したクラスとしてBを作ります。 Bの
[ThinkIT] 第4回：DIコンテナとの比較 (1/4)
今回は、ここ数年非常に注目されている技術であるDI（Dependency Injection）コンテナをテーマに取り上げます。 DIコンテナはアプリケーションのオブジェクトを疎結合にし、柔軟性を与えるものです。その結果得られる代表的なメリットとして表1のようなものがあげられます。いずれも品質向上に寄与する重要な効果です。 モックオブジェクトによるテスタビリティ向上 単体テストにモックオブジェクトを導入でき、テスタビリティを向上させられる。 トランザクション指定の簡易化 トランザクションを簡易に指定できるようになり、障害時処理の高品質化が実現される。 しかし、そもそもRailsにはDIコンテナという考え方が取り入れられていません。そこで表1にあげたDIのメリットに関するRailsでの対応・非対応の状況を比較するという形で進めていきます。 なお、DIコンテナから得られるメリットはDIコンテナ上
なぜDIコンテナを使うのか
本記事は2005年に執筆されたものです。Spring、DI、AOP全般の最新情報は＠IT Java Solutuionのカテゴリ「DI×AOP（Spring／Seasarなど）」をご参照ください。 私がDIコンテナを使う理由 前回までで、Spring Framework（以下Spring）やDIの概念について説明してきました。最近では、実際の開発現場でもSpringのようなDIコンテナを利用するケースが増えてきているようです。 現場のエンジニアはDIの“機能”や“役割”は理解できるようです。しかしながら、「なぜそれが必要なのかピンと来ない」「学習してまで導入するほどの効果があるのか疑わしい」という声をよく耳にします。そのほかにも、自分自身はメリットを十分に理解して開発プロジェクトに導入したい気持ちがあるけれど、導入するためには上司や関係者を説得しなくてはならず、どのように説得すればよいか分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
