春には3つのコアコンセプトがあります：、他の技術の春は、構築するために3つのコア技術に依存しているので、春を再生するには、まずこれらの3つの概念を深く理解している必要があります。
スプリングの紹介
クラスはA、Bの2種類：
public class A{
public void m1(){}
}
public class B{
public void m1();
}
上の2つのクラスはどちらも同じm1メソッドを持っています。
Bのm1メソッドはAのm1メソッドを呼び出す必要があるので、Bのコードは次のようになります：
public class B{
private A a; // @1
public B(){
this.a = new A(); //@2
}
public void m1(){
this.a.m1(); //@3
}
}
上のコードを分析してください：
1: クラスBは型Aの属性を宣言しています。
2: 新しいAオブジェクトが作成され、a属性に割り当てられます。
3: クラスBのm1メソッドは、a.m1()をコールしてビジネス・オペレーションを完了させます。
まず、依存関係とは何でしょうか？
オブジェクトaが何らかの操作を完了するためにオブジェクトbのメソッドを呼び出す必要がある場合、それはaがオブジェクトbに依存していることを意味します。
上のコードでBのm1がAのm1メソッドを呼び出す必要があるのは、BがAに依存していることを示しています。
上記のコードにはいくつかの問題があります。
Bクラスのaオブジェクトの生成はBのコンストラクタ・メソッドに書かれているため、異なるBオブジェクトを生成する際に異なるaオブジェクトを使用したい場合、現時点ではどうすることもできません。また、Bのaオブジェクトの生成はコンストラクタ・メソッドに書かれているため、Bの異なるaオブジェクトの効果をテストしたい場合、現時点ではBのコンストラクタ・メソッドを修正するしかありません。
上記のコードは最適化する必要があり、Bのaオブジェクトの作成は死ぬまで書くことはできません：
public class B{
private A a;
public B(A a){
this.a = a;
}
public void m1(){
this.a.m1();
}
}
上記のコードは、外部で作成されたaオブジェクトが渡されたときにBオブジェクトを作成するために使用することができます：
A a = new A();
B b = new B(a);
b.m1();
もしBクラスがまだAと同じようなオブジェクトに依存する必要がある場合、例えばC、D、E、Fやそれ以上のオブジェクトに依存する必要がある場合、まずBのコンストラクタのメソッドを調整する必要があります。
しかし、Bを使うと次のようになります：
A a = new A();
C c = new C();
D d = new D();
E e = new E();
F f = new F();
...
B b = new B(a,c,d,e,f,...);
b.m1();
ユーザーがBオブジェクトを作成するには、まずB依存オブジェクトを作成する必要がありますし、Bオブジェクトに渡されたこれらのオブジェクトに依存するBは、多くの場所がある場合、オブジェクトのB型を使用する必要がある、この新しい書き込み方法を使用している、コードの量が比較的大きいだけでなく、維持するために不便な、Bの新しい依存関係が、良いオブジェクトを作成するために、新しい最初の方法で使用する必要がある場合は、オブジェクトに依存しているオブジェクトに入力されるオブジェクトに依存しています。Bオブジェクト。
オブジェクトの作成の上では、まず良いを作成するための新しい方法を介してオブジェクトに依存する必要がありますし、Bに渡すと、これらのジョブは、Bのユーザーが自分自身を行うには、オブジェクトのすべての作成は、ユーザー自身によって制御され、上記の欠点はまた、コードの量も比較的大きく、コードのカップリングが比較的高く、拡張に資するものではありません。
では、これらの問題を解決する良い方法はあるのでしょうか？
上記のBオブジェクトとBの依存オブジェクトは、その作成を制御するために、ユーザー自身のイニシアチブである、我々はこのようなサードパーティにリストを与えるように、このことを行うには、サードパーティを見つけることができます、リストは、私はBオブジェクトを使用する必要があることをサードパーティに指示し、Bはオブジェクトに依存する必要があり、その後、サードパーティは、Bオブジェクトの作成とアセンブリを担当する必要があります、ユーザーは、Bオブジェクトを使用する必要があります唯一のサードパーティの検索を開始する必要がある、サードパーティは、Bオブジェクトを持っている場合、直接Bオブジェクトの内部アセンブリに戻ることができます。ルックアップは、もしBオブジェクトのサードパーティ側は、直接Bオブジェクトの内部アセンブリに戻るには、リストで使用する必要があるすべてのオブジェクトのシステム全体は、サードパーティが作成を支援するように、使用するだけで、サードパーティに依頼する必要があります。は、このことの春を達成するために役立っています。
spring
スプリングコンテナのコンセプトは、この名前のコンテナは非常に良いです、コンテナは多くのものを置くことができます、プログラムは、起動時にスプリングコンテナを作成し、スプリングコンテナにオブジェクトとオブジェクトの依存関係を作成する必要があるリストを与えるでしょう、スプリングコンテナは、オブジェクトの良いリストを作成し、組み立て、スプリングコンテナにこれらのオブジェクトを格納し、プログラムが使用する必要があるときに、コンテナを取得し、直接それを使用するために見つけることができます。コンテナは、プログラムが使用する必要があるときに、あなたが取得するコンテナを見つけることができますし、直接使用します。
IOC制御反転
Bオブジェクトを使用するユーザーは、独自のオブジェクトを作成し、組み立てる必要があり、現在、これらの作成と組み立てが完了するためにスプリングコンテナに与えられている、ユーザーは唯一のその上にオブジェクトを使用する必要性を見つけるためにスプリングコンテナに行く必要があります。Bオブジェクトを作成し、組み立てるこのプロセスは、制御するために、ユーザー自身のイニシアチブであり、現在、オブジェクトの構築プロセスを作成し、組み立てるためにスプリングコンテナに与えられている反転しているので、それは制御の反転と呼ばれています。IOCは、設計原理におけるオブジェクトプログラミングの面であり、主にシステムコードの結合を減らし、システムの保守と拡張を容易にします。
DI依存性の注入
IOC制御の反転は、設計思想であり、オブジェクトの作成とスプリングコンテナへの権利のアクティブ制御のアセンブリを行うには、アクションの制御がシステムの結合を減らし、システムの保守と拡張を助長し、主にそれを行うには、権利の反転を制御する権利のアセンブリのオブジェクトを使用する必要性を指し、それを行うには、独自のものであり、今行うには、スプリングコンテナに引き渡されます。
スプリングコンテナ：主にコンテナオブジェクトの作成、アセンブリ、オブジェクトの検索、オブジェクトのライフサイクル管理、その他の操作を担当します。
次回は、バネの使い方について詳しく解説します。
