制御の反転は、保守が容易な再利用可能なモジュール式ソフトウェアフレームワークの作成を支援するソフトウェアアーキテクチャの一般的な設計原則です。
これは、フローの制御がジェネリックで作成されたライブラリまたは再利用可能なコードから「受信」される設計原則です。
それをよりよく理解するために、コーディングの初期の頃のコーディング方法を見てみましょう。手続き型/従来型言語では、ビジネスロジックは通常、アプリケーションのフローを制御し、汎用または再利用可能なコード/関数を「呼び出し」ます。たとえば、単純なコンソールアプリケーションでは、制御フローはプログラムの命令によって制御されます。これには、いくつかの一般的な再利用可能な関数の呼び出しが含まれる場合があります。
print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);
//More print and scan statements
<Do Something Interesting>
//Call a Library function to find the age (common code)
print Age
対照的に、IoCでは、フレームワークはビジネスロジックを「呼び出す」再利用可能なコードです。
たとえば、Windowsベースのシステムでは、ボタン、メニュー、ウィンドウ、ダイアログボックスなどのUI要素を作成するためのフレームワークがすでに利用できます。アプリケーションのビジネスロジックを記述する場合、ビジネスロジックコードを呼び出すのはフレームワークのイベントであり（イベントが発生したとき）、その逆ではありません。
フレームワークのコードは私のビジネスロジックを認識していませんが、コードを呼び出す方法は認識しています。これは、イベント/デリゲート、コールバックなどを使用して実現されます。ここでは、フローの制御が「反転」されています。
したがって、静的にバインドされたオブジェクトの制御フローに依存する代わりに、フローはオブジェクトグラフ全体と異なるオブジェクト間の関係に依存します。
Dependency Injectionは、オブジェクトの依存関係を解決するためのIoC原則を実装する設計パターンです。
簡単に言うと、コードを記述しようとしているときは、さまざまなクラスを作成して使用することになります。1つのクラス（クラスA）は、他のクラス（クラスBまたはD、あるいはその両方）を使用できます。したがって、クラスBおよびDはクラスAの依存関係です。
簡単な例えはクラスカーです。車は、エンジン、タイヤなどの他のクラスに依存している場合があります。
Dependency Injectionは、Dependentクラス（ここではClass Car）が依存関係（Class EngineおよびクラスTyre）を作成する代わりに、クラスに依存関係の具象インスタンスを注入する必要があることを示唆しています。
より実用的な例で理解しましょう。独自のTextEditorを作成していると考えてください。特に、テキストのタイプミスをチェックする機能をユーザーに提供するスペルチェッカーを使用できます。このようなコードの簡単な実装は次のとおりです。
Class TextEditor
{
//Lot of rocket science to create the Editor goes here
EnglishSpellChecker objSpellCheck;
String text;
public void TextEditor()
{
objSpellCheck = new EnglishSpellChecker();
}
public ArrayList <typos> CheckSpellings()
{
//return Typos;
}
}
一見、バラ色に見えます。ユーザーがテキストを書き込みます。開発者はテキストをキャプチャしてCheckSpellings関数を呼び出し、ユーザーに表示するタイプミスのリストを見つけます。
一人のユーザーがエディターでフランス語を書き始める晴れた日まで、すべてがうまくいくようです。
より多くの言語のサポートを提供するには、より多くのSpellCheckersが必要です。おそらくフランス語、ドイツ語、スペイン語など。
ここでは、 "English" SpellCheckerがTextEditorクラスと密結合している密結合コードを作成しました。つまり、TextEditorクラスはEnglishSpellCheckerに依存しています。つまり、EnglishSpellChekerはTextEditorの依存関係です。この依存関係を削除する必要があります。さらに、テキストエディターには、実行時の開発者の裁量に基づいて、スペルチェッカーの具体的な参照を保持する方法が必要です。
したがって、DIの紹介で見たように、クラスに依存関係を注入する必要があることを示しています。したがって、呼び出されたクラス/コードにすべての依存関係を挿入するのは、呼び出しコードの責任である必要があります。したがって、コードを次のように再構成できます。
interface ISpellChecker
{
Arraylist<typos> CheckSpelling(string Text);
}
Class EnglishSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
Class FrenchSpellChecker : ISpellChecker
{
public override Arraylist<typos> CheckSpelling(string Text)
{
//All Magic goes here.
}
}
この例では、TextEditorクラスはISpellCheckerタイプの具象インスタンスを受け取る必要があります。
これで、コンストラクター、パブリックプロパティ、またはメソッドに依存関係を注入できます。
コンストラクターDIを使用してクラスを変更してみましょう。変更されたTextEditorクラスは次のようになります。
Class TextEditor
{
ISpellChecker objSpellChecker;
string Text;
public void TextEditor(ISpellChecker objSC)
{
objSpellChecker = objSC;
}
public ArrayList <typos> CheckSpellings()
{
return objSpellChecker.CheckSpelling();
}
}
そのため、呼び出しコードは、テキストエディターの作成中に、適切なSpellChecker TypeをTextEditorのインスタンスに注入できます。
ここで完全な記事を読むことができます