前言
在容器(2)的时候,我们定义了两个方法,分别是 、,后来在容器(4)的时候,它们就不见了,这回将 找回来。
没有容器一样解析依赖
这是容器(4)中我提醒大家的一个问题。那么,容器对于依赖处理有什么优势呢?
希望看完之后,大家能有所理解。
注意
这是系列文章中的一篇,涉及的提示,均为之前的文章,大家可以回去参考。
代码变更
找回 bind() 方法
非常简单,将绑定的对象,添加到 $list 类属性(数组)
getDependencies() 添加点东西
有什么用处呢?看注释吧。
修改后的 Container 类
使用容器
代码变更
修改 类构造函数的参数提示类型,从 改为
添加 接口类,修改 为 的实现类。
在之前,通过 方法,预先绑定Cache类。
有修改的部分,已经在代码注释中额外标注。
完整代码
执行结果
和容器(4)没什么区别,依然是自动处理了依赖关系。
看出和容器(4)的区别了吗?
Test 的提示类型,是一个接口类(Cache),而真正解析依赖时,实例化的是(FileCache)类。
这就是最大的区别。
这样做有什么意义?
参考,当时我们做了一个数据库接口类,然后由容器来决定当前使用的数据库。这次,我们将其和依赖解析结合在一起,使得程序更具有可维护性。
总结
不知不觉,容器系列已经写了5篇了,受各种条件因素限制(时间、能力、表达力、难度级别等)本系列文章不容易读懂,建议有一定开发经验的程序员深入尝试,萌新就看个热闹好了。
容器,也是一种设计模式,所有的设计模式都是为了解决“更大的软件”所碰到的问题。所以,新人看代码容易,却不知其存在的意义,这个随着经验的增长自然就会好起来。
预计还有最后一篇:《Laravel源代码阅读: 容器篇》。Laravel是以容器作为核心概念的,有机会就和大家一起看看它的容器是如何实现的。
领取专属 10元无门槛券
私享最新 技术干货