Spring基礎編の初識DIとAOP

前言
Javaの開発に携わる私たちとして、Springの重要性は言うまでもなく、あなたは毎日Springフレームワークと付き合っているかもしれません.Springはその名の通りjavaアプリケーションの開発に春のような快適さをもたらした.Springは、どのjava開発者も技術の高次への必須基礎と言える.もちろん、Springをマスターするには、特にSpringの底の原理を理解するのは容易ではありません.多くの時間と精力を費やして研究し、実際のプロジェクトの中で絶えず試行錯誤と総括をしてこそ、自分の思考理解を形成することができます.Springに対する最初の認識は浅く、プロジェクトで問題に遭遇したのは度娘に頼っても大まかに解決できるだろう.しかし、Springと接触して1年以上の間、そのフレームワーク体系に対する認知は比較的に雑然としていて、深層技術は依然として霧の中で花を見るのが普通で、自分の認知と理解を形成していないので、これはプログラミング技術の向上に非常に不利です.これに鑑みて、頭から最後までシステムの学習Springフレームワークを静かにし、ブログの形式で学習点滴を記録し、技術知識を共有することにしたのは、レンガを投げて玉を引くことだろう.さて、雑談は控えて、本題に入りましょう――
Springフレームワークのコア紹介
DI(Dependency Injection)は、注入に依存し、私たちがよく聞くもう一つの概念であるIOC(制御反転)と実は結局実現する機能は同じであり、同じ機能が異なる角度から述べられているだけだ.ここのブロガーは多くの弁析に行ったことがなく、度娘にはたくさんの解釈がある.依存注入とは何か、なぜ依存注入とは何かを知る必要があります.この二つの点を明らかにして、Springの勉強は思想的には上道だと思います.
Springを使用していない場合――つまり依存注入がない場合、javaアプリケーションのクラスとクラスの間で相互の機能協力を実現するのは難しいですが、あるクラス(A)がその機能を実現するには別のクラス(B)の協力に依存する必要がある場合は、AクラスでBクラスのオブジェクトを自発的に作成する必要があります.Bクラスのメソッドを使用して機能を完了することができます(ここでは、静的メソッドなどにこだわる必要はありません).これは、AクラスがBクラスオブジェクトのライフサイクル全体の管理を担当する必要があることに等しい.極めて単純な場合、1つのクラスでnewが別のクラスのオブジェクトを出すのは問題ないようですが、複雑なアプリケーションクラスとクラスのコラボレーション関係は多岐にわたっており、1つのクラス機能の実装がどれだけの別のクラスオブジェクトに依存してコラボレーションするかは分かりません.そのため、クラスでオブジェクトを作成し、オブジェクトのライフサイクル全体を管理します.コードの高度な結合と想像できない複雑さをもたらします.では、オブジェクトのライフサイクルをサードパーティコンポーネントに渡して管理することができれば、あるクラスが別のオブジェクトを必要とする場合、サードパーティコンポーネントが直接作成されて渡し、クラスは他のクラスオブジェクトのライフサイクルを管理することなく、自分の機能の実現に専念することができ、このようなクラスの機能は単純に多くなります.はい、Spring(容器)はこのサードパーティ製のコンポーネントです.Spring(コンテナ)がどのオブジェクトを管理する必要があるかを教えるだけでいいので、Springフレームワークがどのようにオブジェクトを作成するかに関心を持つ必要はありません.このように、クラスAがクラスBオブジェクトを必要とする場合、クラスBがSpingコンテナ管理に渡されたと宣言した場合、プログラムがクラスAがクラスBを必要とするまで実行されると、Springコンテナは、注入に依存することによってクラスBオブジェクトをクラスAに注入して業務機能の完了を支援する.サードパーティ製コンポーネントの依存注入により、オブジェクトはクラスとクラス間の依存関係を独自に作成および管理する必要がなくなります.オブジェクトの作成依存注入の方式も多様であり,例えばインタフェース注入,構造方法注入,setter方法注入などである.ここまで言うと、依存注入については比較的率直な認識があるはずです.なぜ注入に依存するのかについては,コード内のコンポーネント間の結合度を減らすために,まず簡単な例を用いて,自分の管理対象よりも注入に依存するメリットを直感的に感じておきましょう.

public class Man implements Human {
  private QQCar car;
  public Man() {
    this.car = new QQCar();
  }
  @Override
  public void xiabibi() {
  }
  public void driveCar(){
    car.drive();
  }
}

インタフェースCarはしばらく2つの実現があります:ベンツ車とQQ車、以上のMan類とQQQCar類が高度に結合したコードの中で、古い運転手はコンストラクタを通じてQQ車のオブジェクトだけを作成したので、QQ車しか運転できません.では、古い運転手はベンツを運転したいと思っていますが、ベンツ車のオブジェクトを再作成させますか?このような高度に結合されたコードは仕方がないようですが、オブジェクトを注入することで上記のコードを改善します.

public class Man implements Human {
  private Car car;
  public Man(Car car) {
    this.car = car;
  }
  @Override
  public void xiabibi() {
  }

  public void driveCar() {
    car.drive();
  }
}

以上のコードは多態特性に基づいて,コンストラクタインタフェース注入により具体的なオブジェクト実装を遮断し,ベテランドライバーが何を運転したいのかを考えることができるようになった.これが注入に依存するメリットです.
AOP(Aspect Oriented Programming)は、フェースプログラミング向け.日常の開発の中で、私達はある業務の機能を完成する時、たくさんのコードを書いて、最後のコードの最適化の時に発見して、本当に業務を完成するコードはそんなに2つの文かもしれなくて、残りはすべてこの部分の業務と関連度が大きくなくて、ただある技術のコードを実現するために、完全に引き出すことができて、そこでとても自然で、私たちはそれをツールクラスに抽出します.このように、使用する場所はツールメソッドを呼び出すだけでokになります.さらに高く見ると、各ビジネスモジュールの機能コンポーネントには、関連するビジネス機能を完了するほか、ログ、トランザクション、セキュリティ制御などの追加の操作などがあります.これらはモジュールのコア機能ではありませんが、欠かせません.これらの追加機能をコードに追加すると、ビジネスシステムの各コンポーネントが重複しすぎて、ビジネスコードが混乱し、純粋ではありません.この時、あなたは神に聞いて、あなたの業務コードを業務の実現だけに集中させて、どんなログ、事務などの関係のないものを管理しないことができますか?ああ、神様は大丈夫だと言って、AOPがありました.依存注入の目的が相互に協力するコンポーネントを比較的緩やかな結合状態に保つことであるとすれば,AOPはアプリケーションのあちこちに広がる機能を分離して再利用可能なコンポーネントを形成することである.一般的に言えば、ログ、トランザクションなどはすべて再利用可能なコンポーネントであり、ビジネスコードのあちこちに分散したログ、トランザクション、セキュリティなどの機能コードを抽出して個別のツールコンポーネントにすることができ、Springの構成でそれを機能の断面として宣言し、Springがどこにいたいのか、これらの再利用可能なコンポーネントをいつ使うか(切り込み)がいいです.これが私の面に向かっての簡単な意味です.この編は引用子にすぎないので、ブロガーは概念を簡単に述べるだけで、具体的なコード、配置の実現をしないで、後続の博文の中で続々と奉納して、レンガを撮ることを歓迎します.