35｜DI Container（23）：项目回顾与总结
徐昊
你好，我是徐昊。今天我们来回顾一下第二个实战项目的整个过程。
最终的完成形态
首先，让我们来看一下最终的完成形态：
00:00 / 00:00
1.0x
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.75x
- 0.5x
项目回顾与总结
首先是任务分解。在项目刚开始的时候，我们没有构想任何的架构愿景，而是直接采用经典模式，从功能点出发进行 TDD 开发。一开始进展是很顺利的，从任务列表上看，除了偶有遗落的功能点，基本上是按照任务列表顺畅进行的。
第一个转折点出现在我们第一次重构之后，我们将 InjectionProvider 从 ContextConfig 中分离了出来。并将依赖的检查从运行期检查，变成了在 ContextConfig.getContext 时预先检查。
也就是说，我们的架构愿景在此时发生了改变：只要 Context 能够被构建出来，其中就不存在无效组件和无效的组件关系（循环依赖、依赖缺失）。
这个架构愿景改变的直接影响，就是让我们分解任务的方式发生了变化。体现在任务列表上为：
方法注入（改变前）
通过 Inject 标注的方法，其参数为依赖组件
通过 Inject 标注的无参数方法，会被调用
按照子类中的规则，覆盖父类中的 Inject 方法
如果组件需要的依赖不存在，则抛出异常
如果方法定义类型参数，则抛出异常
如果组件间存在循环依赖，则抛出异常
方法注入（改变后）
通过 Inject 标注的方法，其参数为依赖组件
通过 Inject 标注的无参数方法，会被调用
按照子类中的规则，覆盖父类中的 Inject 方法
如果方法定义类型参数，则抛出异常
依赖中应包含 Inject Method 声明的依赖
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
徐八叉的文章回顾了他的第二个实战项目的整个过程，展示了最终的完成形态，并通过视频展示了项目的实际运行情况。文章详细介绍了DI Container的应用，并分享了项目的总结与经验。在项目开始时，采用经典模式进行TDD开发，但在第一次重构后，架构愿景发生了改变，影响了任务分解方式。项目还经历了两次重大的模型调整，引入了Provider接口和Qualifier，导致任务列表发生剧烈改变。这些调整对核心模型的改变是痛苦的，但通过重构完成了改写。文章展示了如何应对这种改变，对于读者来说，可以快速了解DI Container在实际项目中的应用，以及作者在项目中所获得的经验和总结。文章内容丰富，对于想深入了解DI Container的读者具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
立即购买
登录 后留言
全部留言(4)
- 最新
- 精选
张铁林主要还是开阔了眼界，用TDD来做一个相对复杂的功能，不像很多kata那样，短短几十行代码量，体会不到不断的重构和深进。编辑回复: 开阔了眼界，很不错👍
2022-06-042
aoe这次要求中最容易做到的就是为自己点个赞，我已经点了！ 最开始学习 TDD 相比：学会使用 @Nested 标签；学会了泛型中 ?、T 之类的含义；有测试做保障想重构就重构编辑回复: 我再给你点个赞！坚持到这里不容易！继续嘎油～
2022-06-021
枫中的刀剑第一次静距离观察一个完整项目的TDD过程，感受还是挺深的。特别是第一次接触到测试重组、测试文档化的时候有种眼前一亮的感觉。而其中ComponentRef 模型和 Qualifier 模型调整的重构过程更加让人赏心悦目。新的模型引入拓展了知识，带来个更加明确的功能上下文划分。而原有整体的结构却没有发生太多的变化。这种一点点进步是能够很清楚的感受到的。 最后在附上项目链接：https://github.com/maplestoryJin/DiContainer 包括 static 注入实现。2022-06-102
临风
有个关于bind的实现问题，一般情况都是bind(Component.class, Instance.class)或者bind(Component.class, Provider<Instance.class>)。如果直接bind(Instance.class, Instance.class)，那么get(Component.class)还能找到吗？ 另外，无论bind的是Intance还是Provider，当需要注入Provider类型的时候，是都需要支持吗？ 这些规范的东西我可以去哪里找到，希望老师能解答一下。2022-06-06
收起评论
