依存関係逆転の原則とは何ですか？車体全体のデザインは良いです最後によると、身体のシャシー設計に基づいて、シャーシに応じて最初のデザインホイール、ホイールのサイズやデザイン、そして：私たちは車を設計したとします。ここでは「依存」関係がある：車依存のボディは、ボディ、シャーシ、ホイールに依存シャーシを依存しています。
このデザインは良いように見えますが、メンテナンス性は非常に低いです。設計の前提条件が完了した後、上司が突然、市場の需要の変化に応じて、我々は車のホイールのデザインは、新入生のコードを変更した配置する必要があると述べました。今回は痛みをEGG：我々は、ホイールシャーシに応じた寸法になっているので、シャーシ設計のサイズを変更するには、車輪が修正されなければならない。同様に体をそれはシャーシの設計に基づいているので、体も同様に、あまりにも変更することができます自動車デザインは変更する必要があります - ほぼ全体のデザインは変更しなければなりませんでした！
我々は今、別の考え置きます。レッツデザインは、おそらく最後のホイールに基づいて車両のシャーシの設計、筐体設計によると、その後、体が車の外観に基づいて設計された車の見えます。このとき、上下逆さまの依存：車輪がシャシー、ボディに依存してシャーシを頼って、体が車を依存しています。
この時点で、我々は唯一のシャシー、ボディ、車のデザインを移動することなく、ホイールのデザインを変更する必要があり、上司はホイールのデザインを変更すると言います。
これは、依存関係逆転の原則である - 元高層ビルが終わっ「逆さま」基盤となるアーキテクチャに依存しており、根本的な建物の高層ビルに依存するようになります。高層ビルは、高レベルのキャップ層ではない根本的な需要がこれを達成するかを決定する必要がありますが、実現する方法です。この状況は、前に表示されない「プルは全体が立ち上げました」。
制御の逆転（制御の反転）は、コード設計アイデア]反転原理に依存します。使用詳細が呼び出される依存性注入（依存性注入）。実際には、これらの概念は、最初の接触は霧に感じるでしょう。単刀直入に言えば、関係に関する概念のこれらのタイプは、次のように：
これらの概念を理解するために、我々はまだ上記の自動車の例を使用します。しかし、コードに、この時間。私たちは、最初の4つのクラス、車、ボディ、シャーシ、タイヤを定義します。その後、車を初期化し、最終的には車を実行します。次のようにコードの構造は次のようになります。
上記第一例に相当し、上部構造は、基礎となるアーキテクチャに依存して - 各クラスのコンストラクタのコンストラクタを直接コードの根底にあると呼ばれます。我々は常に30されていない、ダイナミックな次元に入れて、私のタイヤ（タイヤ）クラスを変更する必要があるとします。私たちは、このような変更が必要になります。
我々はタイヤの定義を変更したため、全体のプロセスの正常な動作を可能にするために、我々は次の変更を行う必要があります。
このことから私たちは、コンストラクタのタイヤを変更する、ことを見ることができますが、このデザインが必要で、すべてのコンストラクタ全体の上位クラスを修正します！ソフトウェア工学では、この設計は維持することはほとんど不可能である。このクラスの各変更は、我々が依存関係として、すべてそれを変更する必要があれば、何千もの基本となるクラスを実際のプロジェクトでは、いくつかのクラスがかもしれ-クラスは、そのソフトウェアの保守コストが高すぎます。
だから我々は、むしろ低く、トップの制御に比べて、下方および上方制御、制御の反転（IOC）にする必要があります。私たちは、制御の反転を達成するために、このようインジェクション（依存性注入）に依存しています。、パラメータとして底クラス上位クラス達成する下位クラスへの上部クラス、いわゆる依存性注入、「コントロール」。ここでは、使用依存性の注入配達のコンストラクタを車両クラスの定義を再書き込みします：
ここでは、動的タイヤサイズ、スムーズに実行しているシステム全体で同じになって、私たちは、以下の変更を行う必要があります。
参照してください？ここで私は、他の上位クラスを変更していない、ライン上のタイヤの種類を変更する必要があります。これは明らかにコードを維持する方が簡単です。また、実際のプロジェクトでは、このデザインパターンも有益であるコラボレーションおよび単体テスト異なるグループ：これらの4つのクラスの開発は、良好な界面の定義限り、4つの異なる4個の異なる基であるようなタイヤはすべて、ボトム、私たちは車のクラスのユニットテストを書きたい場合は、あなただけではなくフレームワークよりも、ライン上の車を着信モックFrameworkのクラスを調べる必要があり、新しい、ユニットテストのために、グループは、制限された相互の発展なしに同時に行うことができます再び建設カー。
这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。
看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。
显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。
IoC Container的第二个好处是：我们在创建实例的时候不需要了解其中的细节。在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：
这个过程中，我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入。
而IoC Container在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new（有点像深度优先遍历）：
这里IoC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：
我们就像是工厂的客户。我们只需要向工厂请求一个Car实例，然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。
实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件，所以你要初始化很久以前的Service类的时候，前人都已经写好了Config文件，你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。
转自：https://www.zhihu.com/question/23277575/answer/169698662