办好事不落好的人 发表于 2024-4-21 14:15:59

快速理解Laravel容器(IOC、DI、Provider、Contract)

源码理解思维的提升

分享一些个人见解。
Laravel里面的某些概念,就像魔术一样,看起来很厉害,当知道魔术怎么变的,就会认为也不过如此。所以不必感觉Laravel里有些概念难以理解。
应当抛除被框架约束思维的枷锁,用PHP设计的角度去思考,关注大概,而不是在在框架层面逐行磨叽。毕竟源码那么多,越是底层变量越多,越抽象,频繁的调用和变量指向,看到天亮也看不明白。
PHP设计的角度去思考怎么理解:
对于Laravel源码,代码很优雅,很工程化,很正规,方便扩展,这是优点,坏处就是抽象,好比垃圾桶里的垃圾都要摆放好,太过于工程化的设计,会给写松散业务逻辑的开发者带来困惑。
举个例子,Laravel里面的很多契约,好多都是一个空interface,放到了vendor下,真的是可要可不要,也确实有不少人说泰勒·奥特威尔就是炫技。
所以迟早要被绕晕,必须抛开Laravel里面的各种细节,用不需要太工程化PHP代码去尝试实现它,实现的过程中会遇到各种优化或者是问题,然后逐步优化。
被框架约束思维的枷锁怎么理解:
框架发展了这么久,源码的累加,不是让从头看的,而是遇到了一类问题,需要追加代码,是一个演进的过程,通过出现的问题或要优化的需求作为驱动来实现代码(书写顺序),而不是通过代码的作用反推解决的问题(反向反了很难看懂源码,看不懂干啥的,原因就是这里),换句话说,1+1=?是问题,2是结果。方向反了只有结果2,怎么推理出问题是1+1,还是2+0,既然不知道问题,又怎么知道2的意义是啥,那个地方要用?
易经思维:像各国人描述乌龟,得学很长时间的各国语言(源码),随手画一个乌龟(思维),全世界的人多能看懂。
要发掘的不是源码这样写我怎么看懂,而是这样写解决了什么问题。
通俗的演进示例

第1步:直接上第一版代码,Test类实现查询功能,于是调用了MySQL类的select方法。
class MySQL {
    public function select() {
      echo '执行查询操作';
    }
}


class Test {
    private $driver;
    public function __construct() {
      $this->driver = new MySQL();
    }

    public function search() {
      return $this->driver->select();
    }
}

$crud = new Test();
$crud->search();第2步:但是如果以后有了Oracle,PostgreSQL怎么办?,代码内部的依赖写死了。
所以类的内部要写活,将内部的依赖,反转到外边,控制权由类的外部控制,通过构造方法传参实现,这就是控制反转,方便代码解耦。
页: [1]
查看完整版本: 快速理解Laravel容器(IOC、DI、Provider、Contract)