今天带来一篇Dagger2的知识，其实本片并没有介绍到它，本篇主要目的是理解什么是依赖注入，算是学习Dagger2的准备工作。
在开始之前先理解一个概念：依赖注入和控制反转。
搜索控制反转得到如下结论：
控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题.控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。依赖注入应用比较广泛。
看不懂。
一个比较形象的比喻和解释：
(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。
(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。
(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。
第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的耦合。
第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。
第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。
总结：在程序中，一个对象中的方法需要依赖另一个对象，该对象中保存其所依赖对象的实例，生成依赖对象的方式不再该对象中通过new创建，而是调用者外部创建依赖对象，通过一定的方式进行传入。
举个例子：我们在写面向对象程序时，往往会用到组合，即在一个类中引用另一个类，从而可以调用引用的类的方法完成某些功能,就像下面这样.
public class ClassA {
...
ClassB b;
...
public ClassA() {
b = new ClassB();
}
public void do() {
...
b.doSomething();
...
}
}
这个时候就产生了依赖问题，ClassA依赖于ClassB，必须借助ClassB的方法，才能完成一些功能。这样看好像并没有什么问题，但是我们在ClassA的构造方法里面直接创建了ClassB的实例，问题就出现在这，在ClassA里直接创建ClassB实例，违背了单一职责原则，ClassB实例的创建不应由ClassA来完成；其次耦合度增加，扩展性差，如果我们想在实例化ClassB的时候传入参数，那么不得不改动ClassA的构造方法，不符合开闭原则。
然后举一个完整的例子：
先看一个图说明要完成什么的例子：
如图：假设做一个用户注册案例：UserManager中会引用到UserStore（保存用户信息到本地）和ApiService（存储用户信息到服务端）的实例
第一个版本，我们可能会写出如下代码：
在自己的Activity中
public class MainActivity extends AppCompatActivity {
private UserManager mUserManager;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mUserManager = new UserManager();
mUserManager.register();
}
}
拿到UserManager实例，调用它的register方法就搞定了用户存储功能。
看一下UserManager类：
public class UserManager {
private ApiServer mApiServer;
private UserStor mUserStor;
public UserManager(){
mApiServer = new ApiServer();
mUserStor = new UserStor();
}
/**
* 管理用户注册
*/
public void register() {
mApiServer.register();
mUserStor.register();
}
}
这个类跟上面的图示一致的，即持有两个引用UserStore和ApiService。在构造方法中实例化，且在register方法中直接调用两个引用的register方法完成了注册。
看一下这两个类：
public class ApiServer {
public ApiServer(){
}
/**
* 往服务端保存用户信息
*/
public void register() {
}
}
以及：
public class UserStor {
public UserStor(){
}
/**
* 往本地注册用户信息
*/
public void register() {
}
}
这代码完全没有问题。
可是过了几天，PM说了，本地存储我要存储到SP中。那么程序员就需要修改代码了：
public class UserStor {
private Context mContext;
public UserStor(Context context){
this.mContext = context;
}
/**
* 往本地注册用户信息
* PM要求保存到SP中
*/
public void register() {
SharedPreferences sp = mContext.getSharedPreferences("user_sp",Context.MODE_PRIVATE);
sp.edit().putString("KEY","VALUE").commit();
}
}
修改了这个类，但是需要引入一个Context对象，一般可能会选则通过构造方法传入这个上下文，那么所有创建UserStor实例的地方都要修正代码（传入需要的上下文）：
UserMagager中要修改代码：
public UserManager(Context context){
mApiServer = new ApiServer();
mUserStor = new UserStor(context);
}
修改了UserMagager构造方法，通过UserMagager构造引入Context对象，但是所有创建UserMagager实例的地方也需要修正代码苟泽编辑不通过：
修改MainActivity中代码：
通过上面发现，只是一点点的修改代码就要修改很多地方动一发而牵动全身。耦合度太高，尤其头疼的是，我Activity与本地存储类UserStor本不应该有半毛钱关系，你修改我Activity却也要跟着修改！
然后为了减少一点点耦合可能会做如下代码修改：
public UserManager(ApiServer mApiServer,UserStor mUserStor){
this.mApiServer = mApiServer;
this.mUserStor = mUserStor;
}
然后在MainActivity中：
mUserManager = new UserManager(new ApiServer(),new UserStor(getApplicationContext()));
这样就减少了一点点修改，但是一点点修改也是修改。能不能做到不需要修改代码呢？那么此时依赖注入（Dragger2）就派上了用场。
为了解决上面的问题，因此我们需要引入一种注入方式，将依赖注入到宿主类（或者叫目标类）中，从而解决上面所述的问题。依赖注入有一下几种方式：
通过接口注入：
interface ClassBInterface {
void setB(ClassB b);
}
public class ClassA implements ClassBInterface {
ClassB classB;
@override
void setB(ClassB b) {
classB = b;
}
}
通过set方法注入:
public class ClassA {
ClassB classB;
public void setClassB(ClassB b) {
classB = b;
}
}
通过构造方法注入:
public class ClassA {
ClassB classB;
public void ClassA(ClassB b) {
classB = b;
}
通过Java注解:
public class ClassA {
//此时并不会完成注入，还需要依赖注入框架的支持，如RoboGuice,Dagger2
@inject ClassB classB;
...
public ClassA() {}
在Dagger2中用的就是最后一种注入方式，通过注解的方式，将依赖注入到宿主类中，从而解决本片所遇到的问题。
本篇主要是对学习Dagger2的一个引入，下一篇开始就是真正的使用Dagger2了。
