IoCの深い理解

春の初めに学び、私たちは春の最初のコアコンセプトとして、IoCのに接触してきた、我々はそれの前に、ソースコードのそのの深い理解のある特定の解釈する必要があります。

IoCの理論

IoCのフルネームInversionofControlもDI（の別名有する「制御の反転」として翻訳され、DependencyInjection）、すなわち、依存性注入を。
「制御の反転」を理解するにはどのように良いのですか？それをよりよく理解するための鍵は、我々は次の4つの質問に答える必要があるということです。

誰がコントロール
どのような制御
なぜ逆転し
何が逆に
これらの4つの質問に答える前に、私たちは、IOCの定義を見て：

いわゆるIOCとの関係は、春IOCコンテナであるオブジェクトのライフサイクルとオブジェクトのために責任があります

この文の上にコアのIoC理論です。この文を理解するには？私たちは、（例えば、上記の4つの質問を読むために問題になることはありません）出て行くために例を引用します。

（このプログラム猿のためにお問い合わせの価値がある）例えば、ガールフレンドを見つける必要があります。私たちは通常の状況下では、ガールフレンドを見つける方法ですか？まず、我々は彼らのニーズ（かなり、良いボディ、良い文字）によると、すべての種類を一致させる、そして最終的に起こるためにそれを送って、その後に関係なく、彼女の趣味の周りの電話番号をマイクロ手紙を聞いて、その後、妹を見つける必要があります。次のように：

    /**

     * 年轻小伙子

     */

    public class YoungMan {

        private BeautifulGirl beautifulGirl;

        YoungMan(){

            // 可能你比较牛逼，指腹为婚

            // beautifulGirl = new BeautifulGirl();

        }

        public void setBeautifulGirl(BeautifulGirl beautifulGirl) {

            this.beautifulGirl = beautifulGirl;

        }

        public static void main(String[] args){

            YoungMan you = new YoungMan();

            BeautifulGirl beautifulGirl = new BeautifulGirl("你的各种条件");

            beautifulGirl.setxxx("各种投其所好");

            // 然后你有女票了

            you.setBeautifulGirl(beautifulGirl);

        }

    }

これは、我々は通常、この（の方法で直接作成されたオブジェクトを、必要な場合は、物事の私たちの通常の方法でnewBeautifulGirl()後）、このプロセスは、複雑で面倒ですが、我々はあらゆる局面に直面している、我々は両方の完全な使用しますそれは、この場合には、また、私たちの目標破壊する責任があり、それは一緒に結合されたオブジェクトに依存します。

実際には、我々は問題を考える必要がありますか？我々は、オブジェクトを使用するたびに本当に自分自身を作成するために、自分自身に依存する必要がありますか？私たちは、オブジェクトに依存していることを知っていることは、オブジェクト自体に本当に依存ではなく、むしろそれが提供するサービスに依存している、それは我々が作成するためのイニシアチブをとるの贈り物である限り、我々はそれを必要として、タイムリーなサービスを提供することができます私たちに、それはその重要ではありません。また、それ自体を作成するために多くのハードワークに比べても管理、リハビリ、直接誰かがいなくても、より良いですが、ここで取得しますか？

これは、直接お見合いで、私たちに「人は」のIoCで送信するために何かを与える私たちがガールフレンドを必要とするとき、上記の例では、それは、データの多くの男性と女性を管理してお見合い会社として、出会い系会社に相当します同社は、私たちの需要を提唱し、同社は当社のニーズに応じて、私たちにお見合いの妹を提供する、私達はちょうどライン上のサルを持って、愛の原因であることが必要です。あなたは、これは非常に簡単ではない、参照してください。

確かに、お見合い会社のIoCは、私たちがガールフレンドを探しているの煩雑な工程を省略支援するよう、オリジナルは現在、積極的に受動的な受け入れを検討していますよりコンパクトで軽量、（私たちの要件を満たしました）。あなたは馬を柄頭しなければならない前に、その後あなたは、ああ、考えて、様々なカレー好意で、自分の手を作るためにすべて、私たちは、誰かがここで取得指示するのに準備ができている、どのような素晴らしいことああ。だから、簡単に言えば、IoCの理念は、他の人があなたを提供できるように、以下に示すように、：

IoCの導入の非存在下では、それはのIoCと、依存オブジェクトであるオブジェクトに直接依存注入され、両方のそれらの関係は、Iocをサービスプロバイダによって管理とメンテナンスを統一することです。何が注入された対象物のサービスの目的のためにIOCサービスプロバイダを達成するために注入されたオブジェクトに対応するオブジェクトに依存することになる、挨拶するために、対象に注入されるのIoCサービスプロバイダーとの直接のヒットを必要とします。だから、IOCはその簡単です！何が今、我々は他の人（IOCサービスプロバイダ）とするために何かを必要とし、彼らが得るために必要なものであることが判明し、ここで取得
、答えは非常に明確である上記4つの質問ことを確認することになりました。

誰が誰がコントロール：開発の伝統的なパターンの後、我々は直接IoCコンテナによって、あなた自身の直接制御に傾く意味オブジェクトを作成するための新しい直接的な方法の対象ですが、IOCコンテナと制御します。だから、もちろんIoCコンテナコントロールオブジェクトのうち、「誰が誰を制御します」。
何がコントロール：コントロールオブジェクトを。
逆転されたのはなぜ：なしIOCは、我々は前進である、独自のオブジェクトにオブジェクトを作成するためのイニシアチブに依存していないとき。しかし、IoCのでは後に、対象物に注入された後、IoCコンテナによって作成された直接依存オブジェクトを注入し、元の依存オブジェクトがイニシアチブの受動的な受け入れに入る、それが逆転しています。
何が逆：買収は逆に対象物に依存しています。

妹と、しかし妹はどのようにそれを持っていますか？これは科学です。

あなただけの結婚のためにパルプに生まれNiubiを、比較することがあります。
ほとんどの場合、我々は、彼らはまだお見合い会社を迎えるために必要な、彼らが望む姉妹の種類を検討します。
別のケースでは、あなたはお見合い会社が言っ直接に、私は、このような姉妹に行くよ、彼らは妹が欲しいかわからない、です。

そのため、提供するために、IOCサービスプロバイダーが注入されたオブジェクトの依存オブジェクトは、次の方法があります。コンストラクタ・インジェクション、stter注入法、インタフェース注入。

コンストラクタ・インジェクション

定義により、コンストラクタ・インジェクションは、パラメータ依存オブジェクトのリストの中で宣言そのコンストラクタ、それが必要かを知るために、外部ので、依存オブジェクトにオブジェクトを介して注入されます。

    YoungMan(BeautifulGirl beautifulGirl){

            this.beautifulGirl = beautifulGirl;

    }

オブジェクト構築の完了を直接使用することができた後、コンストラクタ・インジェクション直感的な方法は、あなたがあなたの家族に生まれたみたいだが、あなたの妻を指定して与えます。

setterメソッドインジェクション

ゲッターとセッターメソッドを介してJavaBeanのオブジェクトのために、我々は、一般的にアクセスされ、オブジェクトのプロパティ。したがって、対応するセッターメソッドを提供する、唯一の現在のオブジェクトは、それが依存するオブジェクトは、それがこの方法によって被験体に注入され、対応する従属オブジェクトに提供することが可能です。次のように：

    public class YoungMan {

        private BeautifulGirl beautifulGirl;

        public void setBeautifulGirl(BeautifulGirl beautifulGirl) {

            this.beautifulGirl = beautifulGirl;

        }

    }

コンストラクタ・インジェクションと比較すると、セッター注入は、あなたは妹がよく考えて欲しいもの置くことができるようなものである（もちろん、依存オブジェクトを使用する前に）、より柔軟な、それはいつでも注入することができ、よりリラックスした方法で、となりますその後、お見合い会社を迎えるために話し、あなたは林チースタイル、趙麗穎モデル、さえ西峰ランダム性の強いにしたいことがあります。

インタフェース注入

それは、不要な従属オブジェクトが侵襲性とのインターフェースを実装する必要があるため、インターフェイス注入は、比較的高い代わりました。一般的に、このアプローチをお勧めしません。

さまざまなコンポーネント

该图为 ClassPathXmlApplicationContext 的类继承体系结构，虽然只有一部分，但是它基本上包含了 IOC 体系中大部分的核心类和接口。

下面我们就针对这个图进行简单的拆分和补充说明。

Resource体系

Resource，对资源的抽象，它的每一个实现类都代表了一种资源的访问策略，如ClasspathResource 、 URLResource ，FileSystemResource 等。
有了资源，就应该有资源加载，Spring 利用 ResourceLoader 来进行统一资源加载。

BeanFactory 体系

BeanFactory 是一个非常纯粹的 bean 容器，它是 IOC 必备的数据结构，其中 BeanDefinition 是她的基本结构，它内部维护着一个 BeanDefinition map ，并可根据 BeanDefinition 的描述进行 bean 的创建和管理。

BeanFacoty 有三个直接子类ListableBeanFactory、 HierarchicalBeanFactory和AutowireCapableBeanFactory， DefaultListableBeanFactory为最终默认实现，它实现了所有接口。

Beandefinition 体系

BeanDefinition 用来描述 Spring 中的 Bean 对象。

BeandefinitionReader体系

BeanDefinitionReader 的作用是读取 Spring 的配置文件的内容，并将其转换成 Ioc 容器内部的数据结构：BeanDefinition。

ApplicationContext体系

这个就是大名鼎鼎的 Spring 容器，它叫做应用上下文，与我们应用息息相关，她继承 BeanFactory，所以它是 BeanFactory 的扩展升级版，如果BeanFactory 是屌丝的话，那么 ApplicationContext 则是名副其实的高富帅。由于 ApplicationContext 的结构就决定了它与 BeanFactory 的不同，其主要区别有：

继承 MessageSource，提供国际化的标准访问策略。
继承 ApplicationEventPublisher ，提供强大的事件机制。
扩展 ResourceLoader，可以用来加载多个 Resource，可以灵活访问不同的资源。
对 Web 应用的支持。

上面五个体系可以说是 Spring IoC 中最核心的部分，后面博文也是针对这五个部分进行源码分析。其实 IoC 咋一看还是挺简单的，无非就是将配置文件（暂且认为是 xml 文件）进行解析（分析 xml 谁不会啊），然后放到一个 Map 里面就差不多了，初看有道理，其实要面临的问题还是有很多的，下面就劳烦各位看客跟着 LZ 博客来一步一步揭开 Spring IoC 的神秘面纱。

参考链接

都可以看看，发人深省。

春のIoCの深い理解