分析laravel的设计思维 之 引导程序的依赖注入行为有点迷惑

查看源码发现laravel启动时会根据顺序启动一系列的引导程序。

会启动 Illuminate -> Foundation -> Bootstrap 目录的下文件这一些列文件。

也就是在Kernel.php 里定义的 写死 $bootstrappers=[]文件列表(顺序很重要)会去逐个执行;

问题1: 每个启动项都必须要实现

public function bootstrap(Application $app{

}

那么larave为什么没有为它们设计接口呢?是因为 上面说的 写死 $bootstrappers=[] 的原因吗? 因为写死,自己知道肯定是这几个文件而且是自己写的,所以就不定义接口了?

问题2: 为什么每个引导程序要在参数定义依赖注入,而不是定义一个抽象类写一个构造函数。

抽象类
public function __construct(Application $app) {

}
abstract public function bootstrap();

这样就自动解决了依赖注入了,再定义一个抽象方法 bootstrap()?
难道还是因为这几个类只有框架自己用,而且是他写死了调用所以不需要去考虑设计了?

就想知道他为什么这么设计,知道他的思维比知道他的代码逻辑更重要

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 4

这个不是依赖注入,是到php8后laravel强制用的类型限制,这个只是laravel自己内部使用,依据自己的规则来就行。想要设计的看laravel提供给开发者的接口这些就行

2年前 评论

@deatil public function bootstrap(Application $app){} 这个不是依赖注入吗? public function bootstrap(array $list){} 这样才是类型限制吧

2年前 评论
deatil 2年前

这里的 Application 不是依赖注入进去的 是直接传递进去的。

github.com/laravel/framework/blob/...

至于为啥不弄成接口,或许可能是因为考虑到后续又 bootstrap 不需要 app 实例。

虽然目前的 bootstrap 都用到 app

2年前 评论

为啥说它不是依赖注入?我觉得是啊,哪里不对了?

2年前 评论
deatil 2年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!