DI：依存性の注入とは何か？：Spring Frameworkで理解するDI（1）（3/3 ページ）

» 2005年04月29日 00時00分公開

[山本大，クロノス]

前のページへ 1|2|3 　　　　　　

コンポーネント指向プログラミングの促進

■コンポーネントのメリット

　DIの主目的の1つはアプリケーションのコンポーネント化を促進することです。アプリケーションをコンポーネント化することで以下のようなメリットが得られます。

コンポーネント単位で機能を強化・改訂することができる
バグや故障を局所化できる
ベンダ提供のコンポーネント等と付け替えることができる
テストが容易になる

参考：コンポーネントのメリットについては、「ソフトウェア開発4つの課題」（@IT FYI）に詳しいので参照してください。

■コンポーネント指向の実現性

　コンポーネントはメリットが多いのですが、設計や実装は難しいといわれてきました。その理由は、多くのプロジェクトにとっての主目的がアプリケーションの開発であり、コンポーネント化は副産物という位置付けにあるためではないでしょうか。主目的のアプリケーション開発では疎結合など意識せずに設計や実装を行う方が簡単です。従って何の規定もなく設計や実装を行うと、疎結合やコンポーネント化にメリットがあると分かっていても結合度の高いプログラムを作ってしまいがちです。ところが、コンポーネントにしようとした機能の中に十分に疎結合化されていないオブジェクトが混入すると、部品に必要な情報（依存性）が多くなりコンポーネントとして切り出すことが難しくなってしまうのです。

　それならばまず初めにコンポーネントを開発し、その後にコンポーネントを使ったアプリケーションを開発すればよいと考えるかもしれません。しかし、コンポーネントそのものの開発を行う場合にも、設計の段階で「使い勝手」と「利用価値」の両面でパフォーマンスの高いコンポーネントを作成しておくことは難しい作業です。具体的な利用方法や要求があいまいな状態でコンポーネントを設計すると、必要以上に機能を盛り込んだコンポーネントとなってしまうか、必要な機能が含まれていないコンポーネントなどを作ってしまいがちです。せっかく手間を掛けたのに、結果としてあまり利用価値がないコンポーネントを作ってしまうのでは意味が半減してしまいます。

　こういったことを考えてみると何もないところからコンポーネントを作り出すよりも、アプリケーションの実装中または実装後に部品の価値が評価され、コンポーネント化されるというプロセスを経る方が自然な流れだといえるのではないでしょうか。以前から「コンポーネント指向」というプログラムの作り方にメリットがあることはいわれていましたが、こういった理由から機能のコンポーネント化の実現性はあまり高くないのが現実でした。

■DIによるコンポーネント化の促進

　通常、十分な疎結合を実現するためにはアプリケーション全体が互いの依存性を気にしながら設計・実装されなくてはなりません。そこでDIをフレームワークとして使用することで、アプリケーションが強制的に疎結合の意識された構造となるのです。よって、アプリケーションの実装後に、利用価値の高い部品をコンポーネントとして抽出することも容易になります。つまりDIを導入することで、無理をすることなく自然な流れでアプリケーションをコンポーネント化することができるのです。

　こうして出来上がったアプリケーションはコンポーネント指向のメリットを受けることができるため、当然カスタマイズや追加開発に強いものになります。しかし、それよりもむしろDIによるコンポーネント化の一番のメリットは「開発中」に表れます。特に仕様変更やバグの修正で影響範囲を限定できるというところに大きなメリットを感じることになるでしょう。ぜひとも一度DIを利用し、仕様を変更させるという経験をしてみてください。その影響範囲の狭さに驚きを感じるはずです。仕様変更の依頼にYESと答えることが病みつきになるかもしれません。また、単体テストのためにモックオブジェクト（テスト用のダミーオブジェクト）を入れ替える作業は、設定ファイルを入れ替えるだけで済んでしまいます。

　これらのメリットは体感してみなければ分からないものですので、これ以上は詳しく解説しませんが、実際にDIを使ってアプリケーションを開発してみると期待以上の効果を感じることができると思います。そこで次回は、Springを使ったサンプルアプリケーションを作りながら「設定を利用から分離する」ことのメリットを体感し、さらにSpringの各種機能やほかのオープンソースツールとの組み合わせ方などを紹介していくことにします。

まとめ

　DIは、オブジェクトを構成するために必要なほかのオブジェクトとの関係を外部設定に分離することで、アプリケーションをコンポーネントの集合として組み立てるためのデザインパターンです。そして、DIフレームワークを利用することで容易にアプリケーションのコンポーネント化を促進することができ、コンポーネント化によって開発中や開発後の仕様変更やデバッグにも強いアーキテクチャを構築することができます。