【SSHシリーズ】spring IOCにおける3つの依存注入方式の深入浅出

Springの核心思想はIOCとAOP,IOC-制御反転であり,コンピュータプログラムの結合問題を減らすために重要なオブジェクト向けプログラミングの法則であり,制御反転は一般的に2つのタイプに分けられ,注入と依存ルックアップに依存し,何に依存するか.どうして頼る必要があるの?何を注入しますか?何をコントロールしますか?依存注入と制御反転は同じ概念ですか?新しい知識に触れると、編集者の頭の中は大きな疑問符ばかりですが、大丈夫です.今日のブログでは、spring IOCで注入に依存する方法を簡単に紹介します.依存注入と制御反転は,クラスとクラスを解結合し,システムの拡張性とメンテナンス性を向上させることを目的とする.a、参加者は誰ですか.b、依存:誰が誰に依存しますか?どうして頼る必要があるの?c、注入:誰が誰に注入しますか?また何を注入しましたか?d、制御反転:誰が誰を制御しますか?何をコントロールしますか?なぜ反転と呼ぶのですか?正転は存在しますか?
e、制御反転と依存注入は同じ概念ですか?反転と依存注入の理解を制御するのに大きな助けになるように,上記の問題を理解する必要がある.
まず、最初の質問ですが、参加者は誰ですか.1)オブジェクト2)IOC/DIコンテナ3)あるオブジェクトの外部リソースの第2の問題:依存,誰が誰に依存するか?どうして頼る必要があるの?依存するのか、よく理解できますが、対象はIOC/DI容器に依存していますが、なぜ依存するのでしょうか.オブジェクトは、オブジェクトに必要な外部リソースを提供するためにIOC/DIコンテナを必要とします.3つ目の問題:注入、誰が誰に注入しますか?また何を注入しましたか?明らかにIOC/DI容器注入対象で、whatを注入したのでしょうか?必ず注入するのはある必要なものです.それは対象に注入するために必要な資源で、重要ではない内容を注入しないに違いありません.あなたはどう思いますか.4つ目の問題:制御の反転、誰が誰を制御しますか?何をコントロールしますか?なぜ反転と呼ぶのですか?正転は存在しますか?制御反転、制御何?IOC/DIコンテナ制御オブジェクトに違いありません.主に制御オブジェクトインスタンスの作成です.反転は順方向に対して、何が順方向ですか.通常のアプリケーションを考えて、AでCを使うならどうしますか?もちろん、直接Cを作成するオブジェクト、すなわち、Aクラスで必要な外部リソースCをアクティブに取得することを順方向と呼ぶ.では、逆とは何でしょうか.すなわち,AクラスはCを自発的に取得するのではなく,受動的に待機し,IoC/DIのコンテナがCのインスタンスを取得するのを待ってから,Aクラスに逆注入する.5つ目の問題:制御反転と依存注入式の同じ概念ですか?依存注入と制御反転は、同じ事柄に対する異なる記述であり、ある態様から言えば、それらの記述の角度が異なる.依存注入はアプリケーションの観点から記述され、依存注入を完全に記述することができる:アプリケーションはコンテナに依存して必要な外部リソースを作成し、注入する.一方、制御反転は、コンテナの観点から説明され、完全な点を説明します.コンテナ制御アプリケーションは、コンテナからアプリケーションに必要な外部リソースを逆方向に注入します.
これらの基本的な概念を理解して、彼女たちの間のつながりと違いを理解して、私たちのもっと良い理解を助けることができて、それから小編は重点的に依存注入を紹介して、spring iocの中で3種類の依存注入があって、それぞれ:a、インタフェース注入;b、setter方法注入;c、構造方法注入;続いて、この3つの注入方法について一つ一つ説明し、demoの説明を通じて、仲間たちのより良い理解を助けることができることを望んでいます.インタフェースインジェクション

public class ClassA {
  private InterfaceB clzB;
  public void doSomething() {
    Ojbect obj = Class.forName(Config.BImplementation).newInstance();
    clzB = (InterfaceB)obj;
    clzB.doIt(); 
  }
……
}

上記のコード部分を説明すると、ClassAはInterfaceBの実装に依存していますが、InterfaceBの実装例をどのように取得しますか?従来の方法は、コードにInterfaceB実装クラスのインスタンスを作成し、clzBを与える.これによりClassAはコンパイル期間中にInterfaceBの実装に依存する.呼び出し者と実装者をコンパイル期間中に分離するために,上記のコードがある.コンフィギュレーションファイルで設定した実装クラスのクラス名(Config.BImplementation)に基づいて実装クラスを動的にロードし、InterfaceBによって強制的にクラスAに変換して使用します.これがインタフェース注入の最も原始的な雛形です.
setterメソッド注入
setter注入モードは実際の開発において非常に広範な応用があり、setter方法はより直感的であり、springのプロファイルを見てみましょう.

次に、setterが依存関係を表す書き方を見てみましょう.

import com.tgb.spring.dao.UserDao;  
  
public class UserManagerImpl implements UserManager{  
  
    private UserDao userDao;  
  
    //          
    public void setUserDao(UserDao userDao) {  
        this.userDao = userDao;  
    }  
      
    @Override  
    public void addUser(String userName, String password) {  
  
        userDao.addUser(userName, password);  
    }  
}  

コンストラクタ注入
コンストラクタ注入,すなわちコンストラクタにより依存関係の設定を完了する.スプリングのプロファイルを見てみましょう.

次に、コンストラクタは依存関係を表す書き方を示します.コードは次のようになります.

	import com.tgb.spring.dao.UserDao;  
	  
	public class UserManagerImpl implements UserManager{  
	  
	    private UserDao userDao;  
	  
	    //          
	    public UserManagerImpl(UserDao userDao) {  
	        this.userDao = userDao;  
	    }  
	  
	    @Override  
	    public void addUser(String userName, String password) {  
	  
	        userDao.addUser(userName, password);  
	    }  
	}  

インタフェース注入&&setter注入&&コンストラクタ注入インタフェース注入:インタフェース注入モードは侵入性を備えているため、コンポーネントが特定のインタフェースに関連しなければならないことが要求されるため、よく見られず、実際の使用は限られている.Setter注入:従来のjavabean開発に慣れたプログラマーにとって,setter法による依存関係の設定はより直感的である.依存関係が複雑であれば,サブ注入モードを構築する構造関数もかなり膨大であるが,このとき値注入モードを設定するとより簡潔である.サードパーティ製クラスライブラリを使用すると、コンポーネントにデフォルトのコンストラクション関数を提供する必要がある場合があります.この場合、コンストラクションサブ注入モードも適用されません.コンストラクタ注入:コンストラクタ中に完全で合法的なオブジェクトを完了します.すべての依存関係は、コンストラクション関数に集中して表示されます.依存関係は、コンストラクション時にコンテナによって一度に設定され、コンポーネントが作成された後も相対的に「不変」の安定した状態になります.コンポーネントの作成者のみが内部依存関係に関心を持ち、呼び出し者にとってこの依存関係はブラックボックスにあります.
このブログでは、主に制御反転、依存注入、springでのIOCの3つの注入方式を紹介し、demoを添えて説明しています.不足点は、皆さんにご指導をお願いします.実は、制御反転でも依存注入でもプログラミングに最大の影響を与えるのはコードではなく、思想的な転換だと思います.「主従シフト」の変化が起こった.アプリケーションはもともとボスで、どんなリソースを取得するにも積極的に出撃しますが、IoC/DIの思想の中で、アプリケーションは受動的になり、IoC/DIコンテナが必要なリソースを作成して注入するのを受動的に待っています.この挙動は,オブジェクトと彼女が必要とする外部資源を効果的に分離し,それらを緩やかに結合させ,機能多重化に有利にし,さらに重要なのはプログラム全体のアーキテクチャを非常に柔軟にすることである.