6つの側面からIoC(制御の反転)とDI(依存性注入)を読む

序文

Springを初めて学び始めたとき、IoCに触れました。Springの最初のコアコンセプトとして、ソースコードを解釈する前に、Springを深く理解する必要があります。Springを初めて使用する人にとっては、IoCItを常に感じています。今日は、オンライン技術専門家によるSpringフレームワークIOCの理解について説明し、SpringIOCについての私の理解についてお話します。

「制御の反転」はテクノロジーではありません

Ioc-制御の反転、または「制御の反転」はテクノロジーではなく、設計のアイデアです。Java開発では、Iocは、オブジェクト内の従来の直接制御ではなく、設計されたオブジェクトをコンテナーに渡して制御することを意味します。Iocを理解する方法は?Iocを理解するための鍵は、「誰が誰を制御し、何を制御し、なぜ逆転するのか(逆転がある場合は前進する必要がある)、どの側面を逆転させるのか」を明確にすることです。次に、詳細に分析しましょう。

私はIOCコンテナを次のように理解しています。例としてバケットを取り上げます。大、小、金、銀、およびさまざまなものがあります。同じことがIOCコンテナにも当てはまります。コンテナの種類ごとに独自の機能がありますが、そのうちの1つを変更すること、つまり水を保持することはできません。これは、私たちが学んだIOCコンテナにも当てはまります。

IOCは、制御の反転の略語です。中間のサードパーティ、つまりIOCコンテナが導入されたため、無関係のクラスには共通の関係があり、ICOコンテナによって管理されるため、IOCコンテナは接着効果として機能します。

1.IOCのアイデア

まず、IoC(制御の反転)についてお話したいと思います。これが春の核心です。SpringフレームワークのいわゆるIoCは、Springがオブジェクトのライフサイクルとオブジェクト間の関係を制御する役割を果たします。これはどういう意味ですか、簡単な例として、どうやってガールフレンドを見つけるのですか?一般的な状況は、美しくて見栄えの良いmmsがどこにあるかを確認し、趣味、qq番号、電話番号、IP番号、iq番号などについて問い合わせて、それらを知る方法を見つけることです。 、そしてそれらに参加してください。あなたが望むものを与えるのは良いことです、そしてへへ...このプロセスは複雑で深遠です、私たちは自分たちで各リンクを設計し、直面しなければなりません。従来のプログラム開発についても同じことが言えます。オブジェクトで別のオブジェクトを使用する場合は、そのオブジェクトを取得し(新しいオブジェクトを自分で作成するか、JNDIからクエリを実行する)、使用後にオブジェクトを破棄する必要があります(接続など)。 。)。オブジェクトは常に他のインターフェースまたはクラスと結合されます。
「2020年の最新のJavaの基本と詳細なビデオチュートリアルおよび学習ルート!

1.1iocの利点

IOCの利点は、初期化プロセス中に多くの新しいものを書くことが避けられないことです。XMLまたは注釈を維持するだけで済みます。多くのコード変更は必要ありません。IOCコンテナは階層化されています。下から見つけてください。 BeanFactoryオンライン(ソースコードの解釈について詳しく説明します)では、クラスとクラスの間の分離を実現するために、コードを分離できます。各自が自分の部分を書くだけで、チームワークに役立ちます。

1.2IoCでできること

IoCはテクノロジーではなく、アイデアであり、オブジェクト指向プログラミングの重要な法則であり、疎結合でより優れたプログラムを設計する方法をガイドすることができます。従来のアプリケーションでは、クラス内で依存オブジェクトを積極的に作成するため、クラス間の結合度が高くなり、テストが困難になります。IoCコンテナでは、依存オブジェクトの作成と検索の制御がコンテナに与えられ、コンテナはInjectingCompositeです。オブジェクト、つまりオブジェクトとオブジェクトは疎結合であり、テストにも便利で、機能の再利用に役立ち、さらに重要なことに、プログラムのシステム構造全体が非常に柔軟になります。
「2020年の最新のJavaの基本と詳細なビデオチュートリアルおよび学習ルート!

実際、IoCがプログラミングにもたらす最大の変更はコードからではなく、イデオロギーから、「マスター/スレーブ転置」の変更が発生しました。アプリケーションは元々上司であり、取得する必要のあるすべてのリソースはプロアクティブでしたが、IoC / DIの考え方では、アプリケーションはパッシブになり、IoCコンテナーが必要なリソースを作成して注入するのをパッシブに待機していました。

IoCは、オブジェクト指向の設計原則の1つであるハリウッドのルール「私たちを見つけないでください。私たちはあなたを見つけます」をうまく具体化しています。つまり、IoCコンテナは、オブジェクトが対応する依存オブジェクトを見つけて、オブジェクトの代わりにそれらを注入するのに役立ちます。積極的に探しています。

2. SpringIoCの概要

SpringのIoCコンテナは、制御の反転と依存性注入を実装するプロセスで2つの段階に分けることができます。

コンテナ起動
フェーズBeanインスタンス化フェーズ
これらの2つのフェーズでは、IoCコンテナは次のことを行いました。

ここに写真の説明を挿入

ここではこれらがまったく理解できないかもしれませんが、問題ではありません。SpringのIoCコンテナは制御の反転と依存性注入機能を一晩で実行しないことを知っているので、基本的な印象を与えるだけです。 2つのステージに分かれており、2つのステージで何が行われているのかを大まかに印象づけます。以下では、各ステージの各作業について詳しく説明しますので、辛抱強くお読みください。

3つ、IoCとDI

DI依存性注入、つまり「依存性注入」:コンポーネント間の依存性は、実行時にコンテナーによって決定されます。より鮮明に言うと、コンテナーは特定の依存性をコンポーネントに動的に注入します。依存性注入の目的は、ソフトウェアシステムにより多くの機能をもたらすことではなく、コンポーネントの再利用の頻度を増やし、システムの柔軟で拡張可能なプラットフォームを構築することです。依存性注入メカニズムにより、コードを使用せずに単純な構成でターゲットに必要なリソースを指定するだけで、特定のリソースがどこから誰によって提供されるかを気にすることなく、独自のビジネスロジックを完成させることができます。

DIを理解するための鍵は、「誰が誰に依存するのか、なぜ依存する必要があるのか​​、誰が誰を注入するのか、何が注入されるのか」です。次に、詳細に分析しましょう。

●誰が誰に依存するか:もちろん、アプリケーションはIoCコンテナに依存します。

●信頼する必要がある理由:アプリケーションには、オブジェクトに必要な外部リソースを提供するためのIoCコンテナが必要です。

●誰が誰を注入するか:明らかに、IoCコンテナは、アプリケーションのオブジェクト、つまりアプリケーションが依存するオブジェクトを注入します。

●注入内容:オブジェクトに必要な外部リソース(オブジェクト、リソース、定数データなど)を注入します。

3.1 IoCとDIの関係は何ですか?

IoCとDIの関係は何ですか?実際、それらは異なる角度からの同じ概念の記述です。制御の反転の概念はかなり曖昧であるため(コンテナ制御オブジェクトのレベルとしてのみ理解される可能性があるため、誰がオブジェクトの関係を維持するかを考えるのは困難です) )、2004年のマスターMartin Fowlerに新しい名前が付けられました:「依存性注入」。IoCと比較して、「依存性注入」は「注入されたオブジェクトはIoCコンテナ構成依存オブジェクトに依存する」ことを明確に説明しています。

春のIocの理解についての記事をたくさん読んだことがありますが、IocやDIの説明がわかりづらくてわかりにくい人も多いのですが、とにかく説明がつかない、わかりにくい感じです。読んだ後も途方に暮れてしまい、オープンウェーブのような気がします。この技術専門家はとてもわかりやすく書いていて、IoC(制御の反転)とDI(依存性注入)のすべての単語を明確に説明し、それを読んだ後、人々に明確さを感じさせました。Springフレームワークに不慣れな人にとってIocを理解することは大きな助けになるはずだと私は信じています。

第四に、BromonのブログでIoCとDIのわかりやすい説明を共有します

4.1、IoC(制御の反転)

まず、IoC(制御の反転)についてお話したいと思います。これが春の核心です。SpringフレームワークのいわゆるIoCは、Springがオブジェクトのライフサイクルとオブジェクト間の関係を制御する役割を果たします。これはどういう意味ですか、簡単な例として、どうやってガールフレンドを見つけるのですか?一般的な状況は、美しくて見栄えの良いmmsがどこにあるかを確認し、趣味、qq番号、電話番号、IP番号、iq番号などを尋ねて、それらを知る方法を見つけることです。 、そしてそれらに参加してください。あなたが望むものを与えるのは良いことです、そしてへへ...このプロセスは複雑で深遠です、私たちは自分たちで各リンクを設計し、直面しなければなりません。従来のプログラム開発についても同じことが言えます。オブジェクトで別のオブジェクトを使用する場合は、そのオブジェクトを取得し(新しいオブジェクトを自分で作成するか、JNDIからクエリを実行する)、使用後にオブジェクトを破棄する必要があります(接続など)。 。)。オブジェクトは常に他のインターフェースまたはクラスと結合されます。

では、IoCはどのようにそれを行うのでしょうか?マッチメイキングエージェンシーでガールフレンドを探すようなもので、ガールフレンドと私の間で結婚相談所というサードパーティが紹介されました。結婚相談所は多くの男女の情報を管理しているので、結婚相談所にリストを提出して、Li Jiaxin、Lin Xilei、Jay Chouのように歌う、スピードのようなどのようなガールフレンドを見つけたいかを伝えることができますカルロス、チーデーンなどのテクノロジー、そして結婚相談所が私たちの要件に応じてmmを提供します。私たちは彼女に恋をして結婚する必要があります。シンプルでわかりやすい、マッチメーカーが要件を満たさない候補者を私たちに与えた場合、私たちは例外をスローします。プロセス全体はもはや私自身によって制御されるのではなく、マッチメイキングのようなコンテナのような組織です。これがSpringが提唱する開発方法です。すべてのクラスはSpringコンテナに登録され、Springに自分が何であるか、何が必要かを伝えます。その後、Springは、システムの実行中に必要なものを積極的に提供します。あなたはあなたを必要とする他のものにあなたを引き渡します。すべてのクラスの作成と破棄はスプリングによって制御されます。つまり、それを参照するのはオブジェクトではなく、オブジェクトのライフサイクルを制御するスプリングです。特定のオブジェクトについては、以前は他のオブジェクトを制御していましたが、現在はすべてのオブジェクトがスプリングによって制御されるため、これは制御の反転と呼ばれます。

4.2、DI(依存性注入)

IoCの重要なポイントは、システムの実行中に必要な他のオブジェクトをオブジェクトに動的に提供することです。これは、DI(依存性注入)によって実現されます。たとえば、オブジェクトAはデータベースを操作する必要があります。以前は、Connectionオブジェクトを取得するために常にAでコードを記述する必要がありました。Springでは、Aで接続が必要であることをSpringに通知するだけで済みます。この接続が構築されるとき、Aは知る必要はありません。システムが稼働しているとき、スプリングは適切なタイミングで接続を作成し、それを注入のようにAに注入して、各オブジェクト間の関係の制御を完了します。Aは正常に実行するために接続に依存する必要があり、この接続は春までにAに注入されます。これが依存性注入の名前の由来です。では、DIはどのように実装されますか?Java 1.3以降の重要な機能はリフレクションです。これにより、プログラムはオブジェクトを動的に生成し、オブジェクトのメソッドを実行し、プログラムの実行中にオブジェクトのプロパティを変更できます。Springはリフレクションを介してインジェクションを実装します。

IoCとDIの概念を理解すると、すべてがシンプルで明確になり、残りの作業はSpringフレームワークに積み上げられます。

5、IoC(制御の反転)とDI(依存性注入)についての私の理解

通常のJavaアプリケーション開発では、特定の関数を実装したり、特定のビジネスロジックを完了したりする場合、それを完了するには少なくとも2つ以上のオブジェクトが必要です。Springを使用しない場合、各オブジェクトは協力するときに彼を使用する必要があります。オブジェクトの場合、new object()のような構文を使用して、協調オブジェクトを作成する必要があります。この協調オブジェクトは自分で作成します。協調オブジェクトを作成するイニシアチブはあなたの手にあります。必要なパートナーは、作成するイニシアチブを取ります。協調オブジェクトを作成するイニシアチブとタイミングは自分で制御します。これにより、オブジェクト間の結合が高くなります。Aオブジェクトは協調オブジェクトBを使用して1つのことを一緒に完了する必要があります。ABを使用するには、AはBに依存します。つまり、AとBの間には結合関係があり、緊密に結合されていますが、Springを使用した後は異なります。協調オブジェクトBを作成する作業はSpringによって行われます。SpringはBオブジェクトを作成し、 AオブジェクトがBオブジェクトを使用する必要がある場合、Springは、オブジェクトが格納されているコンテナからAが使用するBオブジェクトを取得し、Springがオブジェクトを作成する方法と同様に、それをAオブジェクトの使用法に渡します。そして、オブジェクトを作成するとき、オブジェクトAはこれらの詳細を気にする必要はありません(あなたが生まれたときとあなたがどのように生まれたか、私は気にしません、ただ私が働くのを助けることができます)、Aが私たちに与えられたオブジェクトを取得した後春には、2人で協力して、完了する作業を完了することができます。

つまり、IoC(制御の反転)とは、オブジェクトを作成するための制御権の移転を指します。以前は、オブジェクトを作成するイニシアチブとタイミングは自分で制御していましたが、現在、この権限は、With the IoCへの移転など、サードパーティに移転されています。コンテナは、オブジェクトの作成に特別に使用されるファクトリです。必要なオブジェクトが何であれ、どのオブジェクトが提供されます。IoCコンテナを使用すると、依存関係が変更され、元の依存関係がなくなります。これらはすべてIoCに依存します。コンテナ、 IoCコンテナを介して、それらの間の関係を確立します。

これは、SpringのIoC(制御の反転)についての私の理解です。DI(依存性注入)は、実際にはIOCの別の用語です。DIは、2004年の初めにMartinFowlerによって論文で最初に提案されました。彼は結論しました:コントロールが逆転したのは何ですか?つまり、依存オブジェクトを取得する方法が逆になります。

6、コンテナ起動フェーズの説明

6.1IOCの技術的実装

「男、ビール!」バーに来てビールを飲みたいときは、通常、ウェイターに直接挨拶し、喉の渇きを癒すために冷たいビールを持ってくるように頼みます。同様に、注入されたオブジェクトとして、IoCコンテナにサービスを提供させ、必要な依存オブジェクトを送信させたい場合は、何らかの方法で相手に通知する必要もあります。

あなたがバーを頻繁に訪れる場合は、座ったばかりでウェイターが最も頻繁にビールを目の前に置いている可能性があります。
初めてまたは時々訪れる場合は、座った後にウェイターに挨拶する必要があります。「ウェイター、青島、お願いします。」
どのブランドがどのブランドなのかわからない可能性もあります。現時点で
は、ウェイターに何が欲しいかを伝えるために、ジェスチャーをするか、単にロゴ描くしかありません。
いずれにせよ、あなたは最終的にウェイターにあなたのニーズを表現する方法を見つけ、ウェイターがあなたに適切なサービスを提供できるようにします。したがって、IoCモードでは、注入されたオブジェクトはどのようにIoCコンテナに通知して適切なサービスを提供しますか?一般的に使用される2つのメソッドがあります。コンストラクター注入とセッターメソッド注入、および履歴インターフェイス注入の段階を終了した方法です。メソッドでは、次の3つの注入メソッドが比較されます。

インターフェイスインジェクション。注入方法の使用の観点から、インターフェース注入は現在推奨されていない方法であり、基本的に「リタイア状態」にあります。注入されたオブジェクトに不要なインターフェイスを実装させるため、煩わしいものになります。これは、コンストラクターインジェクションとセッターメソッドインジェクションには必要ありません。
コンストラクター注入。この注入方法の利点は、オブジェクトが作成された後、準備完了状態になり、すぐに使用できることです。不利な点は、依存オブジェクトが多数ある場合、コンストラクターのパラメーターリストが長くなることです。リフレクションを使用してオブジェクトを作成する場合、同じタイプのパラメーターを処理することはより困難であり、保守と使用がより面倒です。また、Javaでは、コンストラクターを継承したり、デフォルト値を設定したりすることはできません。本質的でない依存関係処理の場合、複数の構築方法を導入する必要があり、パラメーターの数を変更すると、保守に不便が生じる可能性があります。
セッターメソッド注入。メソッドには名前を付けることができるため、コンストラクターインジェクションよりもセッターメソッドインジェクションの方がわかりやすくなります。さらに、setterメソッドを継承できるため、デフォルト値を設定でき、優れたIDEサポートがあります。もちろん、デメリットは、構築が完了した直後にオブジェクトが準備完了状態に入ることができないことです。
実際、これらの操作はIoCコンテナによって実行されます。必要なのは、IoCコンテナを呼び出してオブジェクトを取得することだけです。

6.2。IoCコンテナとIoCコンテナはどのようにしてオブジェクト間の依存関係を取得しますか?

Springには2つのIoCコンテナが提供されています。

関係たBeanFactory
ApplicationContextの
は以下のように、これらの2つのコンテナは、次のとおりです。

ここに写真の説明を挿入

ApplicationContextはBeanFactoryのサブクラスであることがわかります。したがって、ApplicationContextはより強力なBeanFactoryと見なすことができます。2つの違いは次のとおりです。

  • BeanFactory。基本タイプのIoCコンテナは、完全なIoCサービスサポートを提供します。特別な指定がない場合、デフォルトで遅延初期化戦略(lazy-load)が採用されます。クライアントオブジェクトがコンテナ内の管理対象オブジェクトにアクセスする必要がある場合にのみ、管理対象オブジェクトが初期化され、依存性注入操作が実行されます。したがって、比較的言えば、コンテナの初期起動速度は比較的速く、必要なリソースは限られています。リソースが制限され、機能要件がそれほど厳密ではないシナリオでは、BeanFactoryがより適切なIoCコンテナーの選択です。
  • ApplicationContext。ApplicationContextは、BeanFactoryに基づいて構築されており、比較的高度なコンテナ実装です。BeanFactoryのすべてのサポートに加えて、ApplicationContextは、イベントの公開、国際化情報のサポートなど、その他の高度な機能も提供します。ApplicationContextによって管理されるオブジェクトは次のとおりです。このタイプコンテナが開始されると、デフォルトで初期化され、バインドされます。したがって、BeanFactoryと比較して、ApplicationContextはより多くのシステムリソースを必要とします。同時に、すべての初期化は起動時に完了するため、コンテナの
    起動時間はBeanFactoryよりも長くなります。システムリソースが十分で、より多くの機能が必要なシナリオでは、ApplicationContextタイプのコンテナーがより適切な選択です。

ただし、どのコンテナを使用する場合でも、何らかの方法でオブジェクトの依存関係に関する情報をコンテナに通知する必要があります。この方法でのみ、コンテナはオブジェクトを合理的に作成できます。そうでない場合、コンテナ自体は、どのオブジェクトがどのオブジェクトに依存しているかを認識しません。ランダムに注入されます、それは4次元を作成することではありません。理論的には、コンテナオブジェクトに依存する情報を任意の方法で伝えることができます。たとえば、音声で伝えることはできますが、そのようなコードを実装している人はいないため、Springが提供するメソッドを正直に使用しましょう。

  • 最も基本的なテキストファイルを使用して、注入されたオブジェクトとその依存オブジェクト間の対応を記録します
  • 記述的なXMLファイル形式で対応する情報を記録します
  • コードを記述して、これらの対応する情報を登録します
  • 注釈を介してこれらの対応する情報を登録します

4つのメソッドが提供されていますが、通常はxmlファイルメソッドとアノテーションメソッドのみを使用するため、これら2つのメソッドに焦点を当てます。

記事はここで終わります

元のリンク:https://juejin.cn/post/690185 ...

おすすめ

転載: blog.csdn.net/weixin_46699878/article/details/110531595