使用Hilt完成依赖注入，让你的安卓代码层次有几层楼那么高（一）上

2023-08-03 78

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 使用Hilt完成依赖注入，让你的安卓代码层次有几层楼那么高（一）

依赖注入为何物

既然你已经点进来了，想必已经知道什么是依赖注入了吧，什么？！你还不知道什么是依赖注入吗，那你更要继续往下读了。

首先，来看看依赖注入的定义：

依赖注入就是参数传递

噢噢，我的老伙计，希望你并没有因为这个简单的定义而直接离开本文，我当然知道参数传递是每一位入门级程序员都掌握的基本能力，但为什么要用其他工具来完成这个参数传递呢，因为随着项目的膨胀，项目组件的不断扩大，组件之间的耦合关系也会愈发复杂，我们用一个实际例子来看看

项目膨胀导致的参数传递问题

假设我有一个这样的场景，我需要构造一个车子，车子又有其他零件，零件又有子零件。

/**
 * 车子
 */
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()
}

情况看起来好了很多，调用端已经没有具体的构造代码了，一切的构造都交给了工厂类，但是一旦这些类的属性膨胀起来后，会出现许许多多的工厂类，甚至工厂类本身都会出现属性配置，调用端的代码依然需要手动去修改，也许你进一步学习了抽象工厂，但是这些手段总给你一种感觉：面多了加水，水多了加面。此时的你迫切希望有一种更加解耦，更加无侵入性的手段帮你去实现对象的构建。