Google Guice 3.0を利用したアノテーション駆動による依存性注入

作者 Michael Floyd , 翻訳者 南 伸二 投稿日 2011年4月24日

セクション

エンタープライズ・アーキテクチャ,

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

アノテーション ,

Maven ,

Java ,

デザインパターン ,

言語 ,

オープンソース ,

Japanese Build systems ,

Patterns ,

プログラミング ,

設計 ,

Object Oriented Design ,

Aspect Oriented Programming

共有 |

原文(投稿日：2011/04/20)へのリンク

先月下旬Googleは開発者コミュニティに対しGuice 3.0をリリースし、その際、通常のバグフィックスとパッチに加えていくつかの拡張を追加した。Guiceは、2006年にはじめて紹介された依存性注入（Dependency Injection、DI）デザインパターンを実装するJavaフレームワークである。Guiceの裏にある動機は、手作業で依存性の注入を行う際に特有の、決まり切ったファクトリを書く必要性を減らすことで、プログラマがDIコードを書くことを容易にすることである。インジェクションを扱うためにファクトリを書く代わりに、開発者はそのインターフェースを実装にマッピングするモジュールを作成するだけである。その際、（@Injectのような）コンストラクタアノテーションを利用する。そのモジュールの中では、プログラマはたとえば次のように書くことができる： bind(myInterface.class).to(myImplementation.class);

いったんモジュールが設定されたら、あとは単にクライアントコードに@Injectアノテーションを追加する。インジェクターをブートストラップするのはたった4行のコードである：モジュールを指示するインジェクターを生成し、そのモジュールのgetInstance()に対してインジェクターを利用するだけだ。

上記の例では、コンストラクタインジェクションを利用している。しかし、Guiceはメソッド（セッター）インジェクションやフィールドインジェクションを含む他のタイプのインジェクションもサポートしている。後者の形式のインジェクションはより曖昧で、管理しやすくないコードを生成するという理由で批判されている。このため、Guiceチームはフィールドインジェクションの利用を勧めていない。

Guice主な特徴は、型チェックがコンパイル時に行われ、インジェクションが注入された型と同じ型を返す型安全性にある。スコープはアノテーションを利用して宣言的に取り扱われるため、開発者は単にアノテーションをつくることでスコープを定義することが可能だ。

3.0の新機能

Guice 3.0のもっとも注目すべき変更はJSR 330に完全に準拠したインジェクターを取り込んでいる、ということだ。（JSR 330は2009年にまとめられている。）事実、GuiceチームのDhanji Prasanna氏によれば“Guice 3.0はJSR 330のリファレンス実装である”。

まだファクトリーコードを書く必要があるため、Guice 3.0は、自働的にファクトリー実装を生成し、決まり切ったコードを書く必要性を緩和する補助インジェクション（assisted injection）を追加している。また、型、スコープ、既存のバインディング、あるいはそのすべてをもとにしたバインディングを返すことを可能にする、新しいBinderメソッドとインジェクションの強化が行われている。さらに、フレームワークはSPIを拡張し、サードパーティの拡張により導入された要素を表に出すことができるようにしている。それ以外の強化として、OSGiサポートの改善、数々のサーブレット拡張、シングルトンのサポート、Struts 2の統合などがある。また、次のような機能が含まれている：

* AOPが関係する時のよりシンプルなスタックトレースの利用
* バインディングが重複しているとき、例外を投げるのではなく、無視するようにした。
* cglibの再パッケージ、asm & guavaクラスはIDEの自動インポートからは見えなくなった。
* Mavenのサポート

Guice vs Spring

ディスカッショングループでよく言及されるように、Spring frameworkはすでに依存性注入をサポートしている。もっとも頻繁にあがる懸念は開発者はGuiceかSpringかを選択しなければならない、というものだ。GuiceはSpringのDIメソッドの代替を提供している一方で、Spring frameworkに取って代わるものではない。実際にはGuiceはSpringと共存可能であり、Springと独立にも一緒にも利用することができる。例えば、CuideはAOPメソッドインターセプターをサポートしていて、開発者がSpringのトランザクションインターセプターを利用することができる。また、SpringIntegration()クラスが存在し、Springビーンへのバインドを可能にする。Guiceがもたらしてくれるものは、型安全性であり、例外ハンドリングであり、抽象レイヤーとXML設定の必要性の両方を取り除いてシンプルにしてくれることなのである。

InfoQのインタビューの中で、Spring創始者Rod Johnson氏はSpring 2.5のアノテーション駆動インジェクション（アノテーションバインディング）がどれだけGuiceに触発されたかを話しており、同時に、Spring 3.0の@Configurationとの基本的な違いについても説明している。また、更新されたSpringとの比較がGoogle Codeに存在する。

MiniGuice

最後に、"Guice 4.1"がちょうど発表されたことも言及に値する。この発表は脚注にする以上のものである。というのも、4.1は必要最低限を備えた"MiniGuice"であり、非常に小さなアプリケーションに適しているからだ。GuiceチームメンバーSam Berlin氏がこれを提供して、"Guice 4.1 はGuice、依存性注入、そしてJavaライブラリがどう提供されるかを過激なまでに再検討したものだ"と述べている。Guice 4.1は単一のファイルで構成されていて、このようなシンプルなAPIで呼び出すことが可能である：

myApp program = MiniGuice.inject(myApp.class, new Module1(), new Module2());*

Guice 4.1ソースファイルはGoogle Codeにある。