Nate Kohari氏は Ninject という .NET 用の依存性注入コンテナのバージョン 1.0 をリリースしました。依存性注入はこのところ人気の話題で、その関心の高さからこの技術を活用する新たなツールが生み出されてきています。
Ninject は超高速・超軽量な .NET アプリケーション用の依存性インジェクタであると宣伝されています。開発者がアプリケーションを粗結合で凝集度の高い要素の集合に分割し、後でそれらを柔軟な方法で再結合する手助けを行います。あなたのソフトウェアのアーキテクチャのサポートに Ninject を用いることで、コードの記述、再利用、テストおよび修正がより簡単になるでしょう。
Ninject のウェブサイト上では、Ninject について以下のように説明しています。
- 集中的。 あまりにも多くの既存の依存性注入プロジェクトがさほど頻繁には必要とされない機能のために使い勝手を犠牲にしています。Ninject に機能が追加される際には常にその利点と日々の利用に加わる複雑さについて十分に比較検討されます。我々の目標は、導入への障壁 - Ninject を使用するにあたって必要とされる知識の基準レベル - を可能な限り低く保つことです。Ninject には数多くの高度な機能がありますが、基本的な機能を利用するためにはそれらを理解する必要はありません。
- 小綺麗。 一部のプロジェクトにとってフレームワークの肥大化は大きな懸念事項ですが、その点 Ninject の中核機能は .NET のベースクラスライブラリ以外への依存無しに単一のアセンブリに収められています。この単一アセンブリの占有領域はリリース用にコンパイルされた場合でおおよそ110KBです。
- 高速。 Ninject は呼び出しをリフレクションに頼る代わりに CLR バージョン 2.0 の簡易コード生成機能を活用することができます。これにより多くの場面で劇的（8?50倍）なパフォーマンス改善が得られます。
- 的確。 Ninject を使うことで開発者は最初から物事を正しく行うことができます。コンポーネントをつなぎ合わせるために XML マッピングファイルや文字列の識別子を用いる代わりに、Ninject は堅牢なドメイン固有言語を提供します。これは Ninject が言語の機能（型の安全性など）や IDE の機能（IntelliSense やコード補完など）をうまく生かすということを意味します。
- アジャイル。 Ninject はカスタマイズと進化を念頭に置き、コンポーネント指向のアーキテクチャに基づいて設計されています。システムの側面の多くは各プロジェクトの要求にあわせて拡張あるいは修正することができます。
- 忍びやか。 .NET の属性プログラミングを使用しているにもかかわらず、Ninject があなたのコード内に侵入してくることはないでしょう。あなたはプロジェクト内で簡単に Ninject への依存関係を単一のアセンブリに分離することができます。
- 強力。 Ninject には多数の先進的な機能が含まれています。例えば、Ninject はリクエスト時のコンテキストに応じて異なる具体的なサービスの実装が注入される場合がある、というようなコンテキスト依存の結合をサポートする一番最初の依存性インジェクタです。
InfoQ はこのフレームワークについて、それがどのようなものでまた開発者にとってどう役に立つのか、Nate氏とお話する機会を得ました。
Robert Bazinet (RB): 自己紹介を頂けますか？
Nate Kohari (NK): 私は25才のオハイオ州 Akron 在住のソフトウェア・アーキテクトです。特注ソフトウェアやビジネス・インテリジェンス・ソリューションを開発する Commercial Timesharing, Inc. (CTI) というコンサルティング会社に勤務しています。CTI での私の任務は .NET プロジェクトにおけるアーキテクチャに関して助言を提供することですが、開発の役割も担っています -- 私は紛れもなく "第一線" のアーキテクトです。大学時代からキャリアの最初の頃までの間は Linux 上で C、C++、PHP そして Perl でたくさんの作業を行いましたが、おそらくそのことが現在の私がオープンソースの積極的な支持者である理由だと思います。
RB: Ninject とはどういったものでしょうか？
NK: Ninject は依存性注入フレームワーク、あるいは "制御反転コンテナ" と言っても構いません。皆さんはファクトリ・パターンはご存知ですよね？そうですね、Ninject はあなたが用意する手がかりを基にどのような種類のオブジェクトについても作成する方法を知っている "スーパー・ファクトリ" のようなものの一種です。簡単に言えば、仮にあなたのアプリケーションがジグソーパズルのようなものだとすれば、どのピースを使ってそれらをどのように組み合わせるのかを伝えると Ninject はそのパズルを完成させてくれるのです。そして、もしあなたが後々になってパズルの見た目を変えたくなった場合は、ちょっと組み合わせ方を変更すれば、残りの作業は Ninject がやってくれます。
RB: なぜ依存性の注入が重要なのでしょうか？
NK: 格言によれば "変わらないことは、変わるということだけ" ですが、これは何よりソフトウェア関しては真実なのです。Fred Brooks は彼の論文 No Silver Bullet でこの点について記しています -- ソフトウェアは（相対的に言って）"たやすく" 変更できるため、人々はそれを変更する理由を見出すでしょう。プロジェクトは徐々に発展し、要件の変更が発生し、そして前触れも無くあなたの小さなプロトタイプアプリケーションはミッション・クリティカルな企業規模のシステムへと変化します。制御の反転 -- 依存性の注入によってしばしば実践されてきたプラクティス -- は始めからあなたのソフトウェアに必要とされる柔軟性の設計を織り込むことを手助けし、否応無しに変更が発生した場合でもあなたのソフトウェアは十分に改変に耐えられます。またこの柔軟性によって、テストの最中は実際のコンポーネントをモックオブジェクトに差し替えることができるため、あなたのコードのユニットテストがもっともっと簡単になります。
RB: なぜ新たな依存性注入コンテナを作成されたのでしょうか？
NK: 依存性注入フレームワークは伝統的にアプリケーションのコンポーネントを結びつけるのに必要なメタデータを定義するのに XML に頼ってきました。XML の記述は煩わしいだけではなく、うまくスケールしません。アプリケーションが成長するにつれ、メタデータを定義する XML ファイルはあっという間に肥大化してしまいます。Ninject は Java 界隈で比較的新しい DI フレームワークである Google Guice のアプローチを採用しており、流れるようなインターフェースでソフトウェアの様々な部品をつなぎ合わせることができます。Ninject の目標はどのような規模のプロジェクトでも依存性の注入を実行可能とし、プロジェクトの成長は続けたままメタデータの管理をより簡単にすることです。私は依存性注入の、言うなれば "導入への障壁" を低くしたかったのです。そのために私は最も軽く、最も速く、最も使いやすい依存性注入フレームワークを作成しました。
RB: なぜ StructureMap、Unity、Windsor、あるいはその他の製品ではなく Ninject を使用するのがよいのでしょう？
NK: 誤解しないでください、それらは皆すばらしいプロジェクトです。しかしながら、それらは皆私が考察した "XML 有りき" という発想に悩まされています。Ninject はコンポーネントの組み立てにコードを使用することができるので、XML を記述する時には使えない、C# や VB.NET のコードを記述する際に利用できる言語や IDE の機能 -- 型の安全性やコード補完といったもの -- を活用することができます。他のフレームワークの中には XML による設定を補助するための巧みなインターフェイスを備えたものもありますが、概して API の点では見劣りします。
Ninject はアプリケーションの設計に依存性の注入を組み込む手助けになります。Ninject では、アプリケーションの部品をつなぎ合わせる役目を担う１つ以上の "モジュール" を宣言します。これらのモジュールは単なるクラスなので、ビルドは非常にシンプルで、より知的な -- 例えば、コマンドライン引数を受け取る、特定の型についてアセンブリをスキャンする、あるいは設定をデータベスから削除するなど -- XML ではできないようなことが可能になります。また Ninject は "コンテキスト依存結合" という非常に強力かつ先進的な機能を備えており、特定の型に対して複数の結合方法を宣言しておいて、オブジェクトを作成する際のコンテキストに基づいてどの方法を使用するべきかを Ninject に判断させることができます。最後に、Ninject はまたとにかく非常に高い拡張性を備えています -- フレームワーク内のいずれの部品も確実にカスタマイズ可能で他の様々なライブラリと統合可能であるよう細心の注意が払われています。
RB: Ninject は既存のプロジェクトで利用できるような形で設計されていますか？もしそうであれば、一般的には、開発者が Ninject を入手して効果的に使用するにあたり、コードをリファクタリングするのかそれとも新規にコードを作成していくのか、どのような形で進めるのが良いでしょうか。
NK: 制御の反転は概念であり、（フレームワークの有無に関わらず）いずれの種類の依存性注入でも制御の反転を目的として設計されたソフトウェアが必要になります。レガシーなソフトウェアは誤った凝集（下手な関心の分離）や、オブジェクトが自身の依存関係にあるオブジェクトを作成する役割を担っている "制御の問題" というやっかい事を抱えている場合がよくあります。ソフトウェアの中にこのような制御の反転に対するアンチ・パターンがあればあるほど、Ninject を -- あるいはどのような依存性注入技術であっても、正しく動作させるように作り替えるのはますます難しくなるでしょう。とは言っても、もちろんそれは可能です。Ninject を使えば依存関係の解決は極めてシンプルになるため、一度使い始めればそれらのアンチ・パターンを修正するのはより簡単になります。最初のステップはあなたのコンポーネントの中から適切な分離を見つけ出して作成し、それらを Ninject でつなぎ合わせることです。それが終われば、インターフェースを経由してあなたのコンポーネントが相互に作用するよう修正することにより柔軟性を取り入れ始めることができます。アプリケーションの小さな断片から始めて、時間の許す限り徐々に残りの部分に広げて行きます。また、一度使い始めるとそれはあなたのコードの至る所へと広がって行く傾向があるため、新規のコードに対して依存性の注入を用いるのにも役立ちます。忘れないでください、これは良いことなのです -- すなわちそれはあなたのコードがより柔軟になっているということです！
RB: Ninject は全ての開発者が利用できる製品なのでしょうか、あるいは Ninject もしくは他の DI コンテナは実際はアーキテクトのような高いレベルの人や上級職の開発者によって使用されるもなのでしょうか？
NK: 制御の反転はプロジェクトの成功のためには関係する全ての開発者が受け入れ関与するべきものです -- ですので、今述べた通り、それは実際には間違った考え方です。Ninject は、高度な機能については理解する必要は無く誰にでも簡単に参加できるフレームワークであるという意味において、"導入への障壁の低さ" を備えるよう設計されました。とはいえ、一般的には制御の反転はチームによって積極的に取り入れられるので、主導的な開発者やアーキテクトの指示によって採用されるべきものです。ときには管理層を納得させるのが難しい場合もありますが（"このフレームワークを使わなければならないってどういうことだ？どうして単に 'new' を使えないんだ？"）、しかし重要なのは設計負債 (design debt) なのです。プロジェクトの早い段階で依存性注入フレームワークを利用することは、クレジット決済ではなく現金で支払するようなものです -- 必然的に変更が発生した時に、新たな要求にソフトウェアを適応させるのがより簡単になるでしょう。私の経験から言うと、一旦 "大きなリファクタリング" が新しいバージョンの実装および結合の置き換えと同じくらいシンプルになれば、制御の反転の真価がよりはっきりとしてきます。制御の反転を念頭においてソフトウェアを記述すると、テストの際に実際の実装をモックに置き換えられるので、ユニットテストがもっともっと簡単になります。もし今ユニットテストを書いていないなら、やらなきゃだめですよ！
RB: Ninject は Silverlight 2.0 Beta 2 をサポートしているとのことですが、この点について詳しく説明していただけますか？
NK: はい！Ninject プロジェクトの主な目標の一つに、どのようなサイズや種類のアプリケーションでも依存性の注入を利用可能にするというものがありました。そのため、Ninject 1.0 は .NET Framework のバージョン 2.0、3.0 および 3.5 のみならず、.NET Compact Framework バージョン 2.0 および 3.5、そして Silverlight 2.0 の最新のベータ版 (ベータ2) をサポートしています。この多数のプラットフォームのサポートは私がたくさんの労力を費やしてきた所で、特に誇りに思っている部分でもあります。私は依存性の注入は大規模な "エンタープライジー (enterprise-y) な" プロジェクトに対してのみ効果的に適用可能であるという誤解が存在しているように思いますが、Ninject は .NET ランタイムを実行可能なほぼ全ての場所で動作させるのに十分なほど軽量かつ高速なのです。個人的には .NET Compact Framework が動作する携帯用デバイス用に構築したアプリケーションで Ninject を利用することで多くの成功を収めています。
RB: Ninject はオープンソースですが、他の開発者はどのようにしてコードの提供に関与することができますか？
NK: はい、Ninject は Apache License 2.0 の下にリリースされていますので、どのような種類のプロジェクトにおいても利用の際にはソースコードの再配布の必要はありません。私は常にフレームワークを改善する方法についてのフィードバックを期待していますので、もしあなたが共有したい何かクールなものを作成したならば、いつでもパッチを送ってください。パッチを提出する一番良い方法は、ユーザーグループに投稿することです。Ninject のウェブサイト(リンク)の "speak your mind" (リンク)からリンクされています。また、もしチュートリアル、実例、あるいはその他を含めた追加的な文書の寄稿に興味がありましたら、文書化 wiki (リンク)に参加することができます。オープンソースで最も重要なのはディスカッションとコミュニティであり、Ninject はデフォルトでは "頑固なソフトウェア" ですが、私はコミュニティのニーズに合致するソリューションを提供することに大いに関心を持っています。
RB: 開発者が Ninject 1.0 を入手して今すぐにあるいはごく簡単に始める一番良い方法は？
NK: Ninject のウェブサイト(リンク)でバージョン 1.0 のバイナリもしくはソースを入手するか、あるいはもし開発の最先端に興味がありましたら Subversion のリポジトリから最新の trunk を取得してビルドすることもできます。もしパッチを提供する予定があれば、必ず Subversion から最新版をチェックアウトしてあることを確認してください。
RB: Ninject には詳細な文書およびコードの実例やベスト・プラクティスは用意されていますか？
NK: もちろんです！道場をご覧ください(リンク)。そこには Ninject の始め方についてのわかりやすい一通りの説明や、より高度な機能をいくつか実演しているアプリケーションの実例も用意されています。道場はまだ未完成ではありますが、バージョン 1.0 がリリースされたからには、もっと文書の記述に時間を使いたいと考えています。オープンソース・ソフトウェアはしばしば良質な文書に欠けるという問題がありますが、Ninject には二の舞を演じさせたくはありません！
RB: Nateさん、貴重なお時間を割いていただいて大変ありがとうございました。
Ninject 1.0 についてのより多くの情報、ならびに詳細なドキュメンテーション、ダウンロードそしてサポートに関する情報は会社のウェブサイトへ(リンク)。フレームワークの作者である Nate Kohari氏に関する情報は彼のブログ(リンク)で知ることができます。
原文はこちらです：http://www.infoq.com/articles/ninject10-released
（このArticleは2008年6月17日に原文が掲載されました）