两利相权取其重，两弊相衡取其轻
——古语
序言
权衡利弊，从善而为。我们在抉择一件事情之前，都需要去因地制宜。凡是不能太过武断，亦不能太拖沓。
最近一直在学习研究Dagger2,不单单因为其上手较难，更因为对他好处的模糊理解。导致最近虽然已经掌握框架的搭建，但是仍然未引入工程。并且对比rxjava,rxAndroid,mvp这些三方库和框架，你会发现它受众面好像并不大，真正的引入到自己工程的也并不多。最近的探究，总算摸清了点眉目。
注：这篇文章比较适合已经对依赖注入和dagger2有一定了解的同学借鉴。重要的事情说一遍。
问题
在开篇之前，我这里先列举一个问题，也是我之前的困惑。
- 网上开了不少dagger2的教程，其中总会举出几个例子，解耦是我们常常看到的，依赖注入的概念也应该明白一些，dagger2其实就是将我们平常需要new（实例化）的过程，提取出来，这样就能解耦了。
http://blog.sina.com.cn/s/blog_14b5545b90102w139.html
比如说这篇博客就介绍了一个很简单的例子，他开头就说了这么一句“一旦我们的UserModel的创建方式发生了改变（比如需要传入Context对象到构造函数），我们就需要修改所有创建UserModel的代码”但是我发现 用了依赖注入之后，仍旧得修改所有创建User Model的代码。为什么？因为你的参数是肯定不可能是无米之炊，必须有来源。那用了dagger2后，仍然需要修改每个注入的目标类，传递参数，并且还要搭建框架，有必要么？这不是更能加繁琐么？下面我们保留这个问题，看正文。正文
从依赖注入谈起
存在即合理，我怀疑是不是我进入某个误区了。那我就希望能走出误区，或者说是看看到底它的好处是什么？
这里我就抛开所谓的dagger2，我们从依赖注入的好处去看。什么是依赖注入，网络上有许多定义，或长或短，而我教推崇这篇文章里的讲解http://www.cnblogs.com/leoo2sk/archive/2009/06/17/1504693.html
依赖注入（Dependency Injection），是这样一个过程：由于某客户类只依赖于服务类的一个接口，而不依赖于具体服务类，所以客户类只定义一个注入点。在程序运行过程中，客户类不直接实例化具体服务类实例，而是客户类的运行上下文环境或专门组件负责实例化服务类，然后将其注入到客户类中，保证客户类的正常运行。（这里的客户类，服务类就是经常看到的A中实例化了B,A就依赖于B,A就是客户，B就是服务）
这样就解决了“客户类不准实例化具体服务类”和“客户类需要具体服务类”这样一对矛盾。
后语
抄录古诗一首，愿大家在这个春天里保持好的心情，身体健康。
钱塘湖春行
白居易
孤山寺北贾亭西，水面初平云脚低。
几处早莺争暖树，谁家新燕啄春泥。
乱花渐欲迷人眼，浅草才能没马蹄。
最爱湖东行不足，绿杨阴里白沙堤。