13 ｜DI Container（1）：如何实现基本的DI容器结构？
徐昊
你好，我是徐昊。从今天开始，我们就来使用 TDD 的方式实现注入依赖容器。
现在我们需要将需求分解为功能点，并构想架构愿景。
将需求分解为功能点
对于组件构造部分，我分解的任务如下：
无需构造的组件——组件实例
如果注册的组件不可实例化，则抛出异常
抽象类
接口
构造函数注入
无依赖的组件应该通过默认构造函数生成组件实例
有依赖的组件，通过 Inject 标注的构造函数生成组件实例
如果所依赖的组件也存在依赖，那么需要对所依赖的组件也完成依赖注入
如果组件有多于一个 Inject 标注的构造函数，则抛出异常
如果组件需要的依赖不存在，则抛出异常
如果组件间存在循环依赖，则抛出异常
字段注入
通过 Inject 标注将字段声明为依赖组件
如果组件需要的依赖不存在，则抛出异常
如果字段为 final 则抛出异常
如果组件间存在循环依赖，则抛出异常
方法注入
通过 Inject 标注的方法，其参数为依赖组件
通过 Inject 标注的无参数方法，会被调用
按照子类中的规则，覆盖父类中的 Inject 方法
如果组件需要的依赖不存在，则抛出异常
如果方法定义类型参数，则抛出异常
如果组件间存在循环依赖，则抛出异常
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了徐八叉关于DI容器的实现过程。作者使用TDD的方式实现注入依赖容器，将需求分解为功能点，并构想了架构愿景。在组件构造部分，作者分解了无需构造的组件、抽象类、接口、构造函数注入等任务。对于依赖选择部分，作者列出了对Provider类型的依赖和自定义Qualifier的依赖等任务。在生命周期管理部分，作者提到了Singleton生命周期和自定义Scope标注等任务。作者倾向于使用类似Guice、PicoContainer等框架来配置容器，而不是依赖配置文件。文章最后提到了进入红/绿/重构循环，并引入了Provider这样一个类似于Factory工厂方法的结构，得到了整个依赖注入容器的基本结构。作者还提出了一个思考题，即在重构的时候采用增加一个平行实现的做法。整体来看，本文深入浅出地介绍了DI容器的实现过程，适合对该领域感兴趣的读者阅读学习。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
立即购买
登录 后留言
全部留言(5)
- 最新
- 精选
🐑置顶TDD专栏福利大合集： 1、打卡赢好礼（4月23日-5月10日）：正在进行中，学习专栏第1-10讲并在留言区打卡，结束后奖励； 2、代码亲手评（5月底）：预计打卡结束后启动，完成前10讲的打卡，即可提交代码练习作业，徐昊老师会亲自点评； 3、线上带你练：根据专栏更新节奏和老师时间安排确定，徐昊老师会线上带四个同学手把手地改代码，敬请期待！ 具体活动介绍见 👉 http://gk.link/a/11jPi2022-04-28
keep_curiosity
Java8不是就提供了Supplier函数式接口么？为什么又搞一个Provider呢？有什么区别吗？作者回复: jsr330里有一个 provider 就用了
2022-04-26
努力努力再努力问题： 在重构的时候，我采用的是增加一个平行实现（Parallel Implementation）。用平行实现替换原有功能，然后再删除原有实现的做法。你有没有不一样的做法？ 1. 可以先新增一个新的方法 private static <ComponentType> void bind(Class<ComponentType> clazz, Provider<ComponentType> provider) 2. 调整原有的旧 bind 方法，改成调用 bind 方法 -----> 此时需要重新执行测试，验证重构是否影响测试结果 3. 通过 inline method，消除上方的private方法2022-09-22归属地：广东3- lj老师，请问为啥在no args这个任务，测的是componentImplement会构造出component这个接口类型？我原本理解这个任务是对某个类能支持以默认构造函数构建就可以了，不理解的点是为啥要搞个interface，感觉应该是另外的一个任务。2022-04-26
Geek_7c0961这节课确实和java语言关系不算太大了.还是希望老师能够再讲解的过程中淡化语言本身的特性.2022-04-15
收起评论
