依赖注入的简单理解

要符合高内聚低耦合的设计原理，那么 IOC 就避免不了：

控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题.控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。依赖注入应用比较广泛。

是不是感觉一脸的懵逼？哈哈，其实字面上我也没理解。

我觉得依赖注入：

       就是你要什么，我就给你注入什么，让你用起来方便，不用考虑我给你的东西的长相或好坏。就好比公司（依赖的对象）现在需要一个程序猿（被依赖的对象），那么，只需给这个公司分配一个现成的程序猿就好了。公司不会去考虑这个程序猿是怎么来的，只考虑他会工作就行。

这是我简单的理解（嘎嘎，不知道有没有理解错，请告知），不知道此时的你有没有感觉脑袋里正在万马奔腾。。。

那来看代码：

有一个公司：Company

public class Company{    //此时需要依赖一个程序员    private Coder mCoder;    public Company() {        //一般情况下，都会实例化一个对象（程序猿）给他（公司）使用        this.mCoder = new Coder();    }}

一个现成的程序猿：Coder

public class Coder {    //此时的构造里面没有参数    public Coder() {    }}

Ok，好像没毛病啊？是的，这种方式没毛病，而且是对的，但是如果现在这个Coder和以前不一样了，工资不高不来，嘎嘎（屌丝要逆袭了）.....

public class Coder {    //此时的构造里多了一个int型的参数    public Coder(int money) {        if (15000 != money) {            System.out.print("不给我15K,老子就不干...");        }    }}

到这里你是不是会发现，项目报错了...因为公司找你的时候没谈过这个要求。。。（无参构造的），所以现在公司就得重新找上你，并且给你想要的工资，你猜干活，哈哈。对应的变化

public class Company{    //此时需要依赖一个程序员,现在的程序猿涨价了...    private Coder mCoder;    public Company() {        //一般情况下，都会实例化一个对象（程序猿）给他（公司）使用        this.mCoder = new Coder(15000);    }}

或许这里只是有一个小小的变动，你修改起来也是很方便的，感觉并无大碍，但是你有没有发现，只要这个被依赖的对象稍微有点点改变，相应的依赖这个coder的对象就要做出相应的改变，现在是只是一个公司要他，但是如果这家伙做了很多兼职，有很多公司都同时要他，那他以变化，岂不是要得一个一个的去修改这个变化。。。。10个？100个？。。。想想就好可怕。

ok，到这里，我们就使用依赖注入：（直接给他一份生死合同，哈哈，管你怎么跳，你都跳不出公司的范围，你也影响不到公司）

public class Company{    //此时需要依赖一个程序员    private Coder mCoder;    public Company(Coder coder) {        //现在公司只知道有这么个人会无私的奉献了，哈哈        this.mCoder = coder;    }}

我们将之前实例化的工作交由调用者来实现，相当一猎头（是他向公司推荐的程序猿），公司不管你猎头怎样招人，我只需要到时候你给我一个程序猿就行。

依赖注入的方式以接口的形式传递：

猎头：ICompany

public interface ICompany {    //推荐程序猿    void recommendCoder(Coder coder);}

公司：Company

public class Company implements ICompany{    //此时需要依赖一个程序员,现在的程序猿涨价了...    private Coder mCoder;    public Company() {    }    @Override    public void recommendCoder(Coder coder) {        //在这里接收由接口传递过来的coder        this.mCoder = coder;    }}

或者不适接口的方式：（由外部调用者直接设置实例对象）

public class Company implements ICompany{    //此时需要依赖一个程序员,现在的程序猿涨价了...    private Coder mCoder;    public Company() {    }    @Override    public void recommendCoder(Coder coder) {        //在这里接收由接口传递过来的coder        this.mCoder = coder;    }    //也可以由外部调用来设置coder    public void setCoder(Coder coder){        mCoder = coder;    }}

ok，到这里，不管codder怎样的调皮，都不会影响到公司的结构。

不知道这样理解依赖注入是否正确，如果跑偏了 ，还恳请指正，不想漂的太远，嘎嘎。

推荐：

Dagger2便是一个很好的依赖注入框架。本篇博客也是对Dagger2学习的一个铺垫。

依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在 传统的程序设计过程中，通常由调用者来创建被调用者的实例。创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者 实例的工作通常由框架（Dagger2 等）来完成，然后注入调用者，因此也称为依赖注入。