依存性注入の優れた説明(制御の反転)

依存性注入またはDI(以前は制御の反転と呼ばれていました)および関連するハリウッドの原則(「電話しないでください。電話します」)の説明をたくさん読みました。それらはすべて、非常に詳細な説明をすぐに掘り下げたり、説明を1つの特定のテクノロジーに具体的に結び付けたりするため、不明確になる傾向があります。パターンが失われるか、その単純さが失われるようなものです。これが私が見つけた最も明確な説明です-簡潔にするために少し編集されています(非常に良いSpring in Action、第2版、Craig Wallsによる):

「重要なアプリケーションは、互いに連携してビジネスロジックを実行する、2つ以上のクラスで構成されます。従来、各オブジェクトは、連携するオブジェクト(その依存関係)への独自の参照を取得する責任があります。DIを適用する場合、オブジェクトには、作成時に、システム内の各オブジェクトを調整する外部エンティティによって依存関係が与えられます。つまり、依存関係はオブジェクトに注入されます。」

それは非常に明確だと思います。

依存性注入は元々、制御の反転(IoC)と呼ばれていました。これは、通常の制御シーケンスでは、オブジェクトが依存するオブジェクトを検出して呼び出すためです。ここでは、これが逆になります。依存関係は、オブジェクトの作成時にオブジェクトに渡されます。これは、ハリウッドの原則が機能していることも示しています。依存関係を求めないでください。必要なときに依存関係を提供します。

DIを使用しない場合、なぜそれが大したことなのか疑問に思われるかもしれません。それは重要な利点を提供します:疎結合。オブジェクトは、渡したもの以外に依存しないため、他のオブジェクトとは独立して追加およびテストできます。従来の依存関係を使用する場合、オブジェクトをテストするには、すべての依存関係が存在し、テストする前に到達可能な環境を作成する必要があります。 DIを使用すると、オブジェクトを個別にテストして、作成したくない、または作成する必要のないモックオブジェクトを渡すことができます。同様に、クラスは自己完結型であるため、プロジェクトへのクラスの追加が容易になります。これにより、大規模なプロジェクトが頻繁に進化する「大きな毛玉」を回避できます。

DIの課題は、それを使用してアプリケーション全体を作成することです。いくつかのクラスは大したことではありませんが、アプリ全体ははるかに困難です。アプリケーション全体で、オブジェクト間の依存関係と相互作用を管理するフレームワークが必要になることがよくあります。DIフレームワークは、多くの場合、誰にいつ渡すかを指定するのに役立つXMLファイルによって駆動されます。SpringはフルサービスのJavaDIフレームワークです。他のより軽いDIフレームワークには、NanoContainerとさらに軽量なPicoContainerが含まれます。

これらのフレームワークのほとんどには、初心者が自分の道を見つけるのに役立つ優れたチュートリアルがあります。

このストーリー「依存性注入(制御の反転)の優れた説明」は、もともとJavaWorldによって公開されました。