依赖注入为何物
既然你已经点进来了，想必已经知道什么是依赖注入了吧，什么？！你还不知道什么是依赖注入吗，那你更要继续往下读了。
首先，来看看依赖注入的定义：
依赖注入就是参数传递
噢噢，我的老伙计，希望你并没有因为这个简单的定义而直接离开本文，我当然知道参数传递是每一位入门级程序员都掌握的基本能力，但为什么要用其他工具来完成这个参数传递呢，因为随着项目的膨胀，项目组件的不断扩大，组件之间的耦合关系也会愈发复杂，我们用一个实际例子来看看
项目膨胀导致的参数传递问题
假设我有一个这样的场景，我需要构造一个车子，车子又有其他零件，零件又有子零件。
/** * 车子 */ class Car( private val steeringWheel: SteeringWheel, private val wheel: Wheel ) /** * 方向盘 */ class SteeringWheel(private val color:String) /** * 轮子 */ class Wheel(private val steel: Steel) /** * 钢圈 */ class Steel(private val circle:Int) 那么我要如何构造这个车子呢，代码如下（多个场景表示在项目中存在多处需要构造Car的地方）： kotlin 复制代码 //模拟场景1 fun test1(){ Car(SteeringWheel("红色"), Wheel(Steel(30))) } //模拟场景2 fun test2(){ Car(SteeringWheel("蓝色"), Wheel(Steel(40))) } //模拟场景3 fun test3(){ Car(SteeringWheel("黑色"), Wheel(Steel(50))) }
All right！所有的一切都没问题，项目正常上线，然后某天项目经理跟你说：嘿，这位码农，麻烦给钢圈加个花边吧。你按捺住内心想打人的冲动，然后打开AS，给钢圈加一个属性，不出意外的是，项目出现了一大堆报错，原来是因为汽车包含了轮子，轮子包含了花边，于是所有构造汽车的代码都报错了，于是你修改了代码，变成了如下：
/** * 钢圈 */ class Steel(private val circle:Int,private val lace:String) //模拟场景1 fun test1(){ Car(SteeringWheel("红色"), Wheel(Steel(30,"花边1"))) } //模拟场景2 fun test2(){ Car(SteeringWheel("蓝色"), Wheel(Steel(40,"花边2"))) } //模拟场景3 fun test3(){ Car(SteeringWheel("黑色"), Wheel(Steel(50,"花边3"))) }
加班到12点的你终于确认了所有的代码都被修改，提交测试上线，但是回到床位后的你依然战战兢兢的思考着今天的问题，万一下一次项目经理又要你添加其他属性呢，一想到又要加班熬夜你迅速起身疯狂百度，于是你了解到了工厂模式。
于是你又起床新增了一个Car的工厂接口
interface CarFactory { fun build():Car } object CarAFactory:CarFactory{ override fun build(): Car { return Car(SteeringWheel("红色"), Wheel(Steel(30,"花边1"))) } } object CarBFactory:CarFactory{ override fun build(): Car { return Car(SteeringWheel("蓝色"), Wheel(Steel(40,"花边2"))) } } object CarCFactory:CarFactory{ override fun build(): Car { return Car(SteeringWheel("黑色"), Wheel(Steel(50,"花边3"))) } } //模拟场景1 fun test1(){ CarAFactory.build() } //模拟场景2 fun test2(){ CarBFactory.build() } //模拟场景3 fun test3(){ CarCFactory.build() }
情况看起来好了很多，调用端已经没有具体的构造代码了，一切的构造都交给了工厂类，但是一旦这些类的属性膨胀起来后，会出现许许多多的工厂类，甚至工厂类本身都会出现属性配置，调用端的代码依然需要手动去修改，也许你进一步学习了抽象工厂，但是这些手段总给你一种感觉：面多了加水，水多了加面。此时的你迫切希望有一种更加解耦，更加无侵入性的手段帮你去实现对象的构建。
因此，假设有一个容器，他内部定义了如何构建各个零部件的构建方法，我们只需要告诉容器我需要什么，容器就会自动返回成品，因此我们也不需要手动去实现工厂类，那该多好？
因此，我隆重推荐谷歌Jetpack里面的组件------Hilt
