asp.Netにおける制御反転の理解(文字+コード)
1745 ワード
IOCに対する解釈は、「Inversion of control is a common characteristic of frameworks,so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.」
私はこの概念に対して個人的な説明を実行して、私の理解を便利にしたいと思っています.制御反転とは、文字通り、制御権が受動的から能動的になったり、受動的になったり、受動的になったりして受動的になったりすることを意味する.この角度から言えば、IOCは非常に理解しやすくなりました.例えば、あなたの責任者はあなたに一つのことを要求しています.この時、こんなに多くのプロセスが存在します.主管はあなたに仕事をするように命令します(この時の主導権は主管で、あなたは受動的です)あなたは命令を受けて仕事をします(この時のテーマはあなたで、あなたは主導的で、制御権はあなたの手にあります)あなたは仕事を完成します(この時のテーマは依然としてあなたで、制御権はあなたの手にあります)主管が仕事をしたことを報告します(主導権はまた主管の手に渡しました)
上記のプロセス全体でIOCが完了したことから、IOCの基本思想は制御権の転換プロセスであることがわかります.
コードの例を挙げます:もしClass A,Class Bがあるならば、Aの内部で1つのBを原始化することができて、Bの1つの要領を呼び出します
Main関数では、A a=new A(); a.Excute();
この2行のコードを見ると、事実上IOCの流れも存在し、a——>b——>a、理解の鍵はAの内部でExcuteを呼び出すときにb.DoMethodの実行を要領する.IOCを理解し、DIをもう一度見てみましょう.上のA呼び出しBから、Aのインスタンスをオリジナル化する際にも、Bをインスタンス化しなければなりません.つまり、BやBに疑問がなければ、Aはインスタンス化できません.これは、A依存、すなわち、A依存、B依存、という依存が設計の観点から結合であり、明らかに高集約低結合の要求を満たすことができません.この時にはデカップリングが必要であり,もちろんデカップリングには多くの要領があり,DIはその一つである.いずれのデカップリング要領も,AとBを全く連絡させないというのではなく,このような連絡の実現を曖昧にし,それほど直接的ではないが,実現しやすく,拡張しやすく,上のコードのように直接new 1つのBが出てくるわけではない.では、なぜ私たちはいつもIOCとDIを結びつけているのでしょうか.DIの基本思想がIOCなので、IOCの思想を体現する要領はもう一つあります.それはService Locatorです.この要領は少ないようです.実はこれらはjavaから派生したもので、本人はもう何年もjavaを使っていませんが、SpringはIOC、DIに使われています.彼らは密接につながっているようです.
私はこの概念に対して個人的な説明を実行して、私の理解を便利にしたいと思っています.制御反転とは、文字通り、制御権が受動的から能動的になったり、受動的になったり、受動的になったりして受動的になったりすることを意味する.この角度から言えば、IOCは非常に理解しやすくなりました.例えば、あなたの責任者はあなたに一つのことを要求しています.この時、こんなに多くのプロセスが存在します.主管はあなたに仕事をするように命令します(この時の主導権は主管で、あなたは受動的です)あなたは命令を受けて仕事をします(この時のテーマはあなたで、あなたは主導的で、制御権はあなたの手にあります)あなたは仕事を完成します(この時のテーマは依然としてあなたで、制御権はあなたの手にあります)主管が仕事をしたことを報告します(主導権はまた主管の手に渡しました)
上記のプロセス全体でIOCが完了したことから、IOCの基本思想は制御権の転換プロセスであることがわかります.
コードの例を挙げます:もしClass A,Class Bがあるならば、Aの内部で1つのBを原始化することができて、Bの1つの要領を呼び出します
DoMethod public Class B
{
public void DoMethod（）
{
/// do somthing；
}
}
public Class A
{
public void Excute（）
{
B b = new B（）；
b.DoMethod（）；
}
}Main関数では、A a=new A(); a.Excute();
この2行のコードを見ると、事実上IOCの流れも存在し、a——>b——>a、理解の鍵はAの内部でExcuteを呼び出すときにb.DoMethodの実行を要領する.IOCを理解し、DIをもう一度見てみましょう.上のA呼び出しBから、Aのインスタンスをオリジナル化する際にも、Bをインスタンス化しなければなりません.つまり、BやBに疑問がなければ、Aはインスタンス化できません.これは、A依存、すなわち、A依存、B依存、という依存が設計の観点から結合であり、明らかに高集約低結合の要求を満たすことができません.この時にはデカップリングが必要であり,もちろんデカップリングには多くの要領があり,DIはその一つである.いずれのデカップリング要領も,AとBを全く連絡させないというのではなく,このような連絡の実現を曖昧にし,それほど直接的ではないが,実現しやすく,拡張しやすく,上のコードのように直接new 1つのBが出てくるわけではない.では、なぜ私たちはいつもIOCとDIを結びつけているのでしょうか.DIの基本思想がIOCなので、IOCの思想を体現する要領はもう一つあります.それはService Locatorです.この要領は少ないようです.実はこれらはjavaから派生したもので、本人はもう何年もjavaを使っていませんが、SpringはIOC、DIに使われています.彼らは密接につながっているようです.