快速理解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]