Java EEの進化を取り込んで保守性と生産性を高めよ!--Javaシステムでの“モダナイゼーション”の在り方

森英幸
2013-05-23 16:01:00
  • このエントリーをはてなブックマークに追加

CDI

 CDI(Contexts and Dependency Injection)は、Java EE 6から導入された、コンテキスト対応型のDI機能である。これもJSFと同様に、DRYを実践するうえで重要なコンポーネントになるという。

 簡単に説明すると“DI(Dependency Injection)”とは、ソフトウェアのコンポーネント化を推進するための機能であり、実行時に依存性を注入することで、コンポーネント間の静的な依存関係をコードから排除することを可能にする。すなわち、各コンポーネントの独立性を高めて、テストや保守、再利用をしやすくする機能だ。

 DIのフレームワークとしては、「Spring」や「Seasar2」が広く使われているが、CDIにはJava EE標準である(別途追加する必要がない)ことのほかにも、さまざまなアドバンテージがある。

 まず、タイプセーフなインジェクションが可能であること。クラス名だけに頼らず、型のチェックも行うため、コンパイル時に型の不適合エラーを検出できる。また、拡張モジュールSPIを使って、Java EEの標準に則ったかたちでCDIの機能を拡張することが可能だ。

 さらに、CDIではインジェクトするインスタンスをコンテキスト(スコープ)に紐付けて管理している。同一スコープ内であれば、そのスコープで最初にインジェクトする際に生成されたインスタンスが自動的にインジェクトされる。そのため、従来のようにパラメータでインスタンスを持ちまわるようにしたり、共通のインスタンスを取るための仕掛けを裏側に用意したりする必要がない。

 このCDIの有効な活用方法として大橋氏が挙げたのは、現在のJava EEに足りない機能をサードパーティフレームワークで補う際に、CDIを使ってフレームワークへの依存度を弱めるという使い方だ。

 たとえば、現在使用しているサードパーティのログ出力モジュール(ロガー)を将来的にJava EEのロギング機能で置き換えたいとしよう。このとき、アプリケーションから直接ロガーを呼び出すのではなく、ロガーのインタフェースを作成してアプリケーションにインジェクトする。ロガーの実装をアプリケーションから隠ぺいすることで、スムーズな置き換えが可能になるという。

 つまり、CDIを上手に利用することで、DRYのところでも触れた、Java EEのロードマップを見据えたコンポーネントのライフサイクルマネジメントが実現できるわけだ。

 このほか、CDIの有効な利用例としては、CDIのイベント通知機能を利用してアプリケーションやフレームワークの部品間で通信を行わせる例や、CDIのインスタンス動的取得機能により、ロードするインスタンスを自動判別させる例などが紹介された。

 以上のように、大橋氏のセッションでは、J2EEスタイルに代わる、Java EE時代のアプリケーション開発の方法論が示された。大橋氏によると、確立されたJ2EEスタイルを捨てることに難色を示すSI企業が多い一方で、開発や保守のコストを削減したいユーザー企業ではJava EEへの期待が高まっているという。こうした中、大幅な機能拡張を受けて、6月にリリースされるJava EE 7は、J2EEからJava EEへの本格的な移行を促す起爆剤となるだろう。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]