源码理解思维的提升
分享一些个人见解。
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怎么办？，代码内部的依赖写死了。
所以类的内部要写活，将内部的依赖，反转到外边，控制权由类的外部控制，通过构造方法传参实现，这就是控制反转，方便代码解耦。
<?php
class MySQL {
public function select() {
echo '执行查询操作';
}
}
class Test {
private $driver;
public function __construct($driver) {
$this->driver = $driver;
}
public function search() {
return $this->driver->select();
}
}
$crud = new Test(new MySQL);
$crud->search();
第3步：但是随着项目的复杂，类越来越多，对象到处都是，得有一个管事的领导人，进行统一管理，于是容器出现了。
容器至少需要两个方法，bind和make，bind用于存储，相当于领导人管辖的地域，分配一块地区，让这些容器有地方生存。make顾名思义就是制造，创建出来的这些容器（就是实例化的过程）让他们做事。
bind方法一般不会直接实例化对象，因为可能用不上，但是代码流程走到哪里了，存是得存起来，防止后期用得上，这很好理解，就好比Laravel的Cache模块，不是每次请求都一定能用得上，但是它仍旧会被预先加载。
class Container {
private $container = [];
public function bind($name, $class) {
return $this->container[$name] = $class;
}
public function make($name) {
$class = $this->container[$name] ?? null;
if(! $class) {
return null;
}
return new $class();
}
}
第4步，整合到第2步的代码当中。
看起来简单东西搞复杂了，确实。但是框架中，对于大量的类和对象的管理却很有用，结合框架的反射，以及其它机制，是能够让类的管理变的更优雅的，
没有容器情况下的例子：
要狗肉账，张三问李四要债，李四说债务转移给王五了去问王五要，王五说债务转移给赵六了你去问他要，彼此踢皮球的环节耦合度太高，互相依赖。
有容器情况下的例子：
相当于直接起诉到法院，一步到位，不管你是谁。我通过法院的管事人，去解决问题。
<?php
class MySQL {
public function select() {
echo '执行查询操作';
}
}
class Test {
private $driver;
public function __construct($driver) {
$this->driver = $driver;
}
public function search() {
return $this->driver->select();
}
}
class Container {
private $container = [];
public function bind($name, $class) {
return $this->container[$name] = $class;
}
public function make($name) {
$class = $this->container[$name] ?? null;
if(! $class) {
return null;
}
return new $class();
}
}
$container = new Container();
$container->bind('MySQL', MySQL::class);
$crud = new Test($container->make('MySQL'));
$crud->search();
Laravel容器
laravel容器的源码在vendor/laravel/framework/src/Illuminate/Container/Container.php
Laravel核心概念，类比成一个存放各类对象的数组，贯穿了整个Laravel流程，用于降低耦合度，管理并存储各模块的类与对象。
一个框架提供了很多模块，就需要很多对象，这些对象需要统一管理，自动实例化，以及类类型的形参自动实例化的反射机制，于是有了容器。
IOC（控制反转）
类内部的依赖，反转到类外边，控制权由类的外部控制，通过构造方法传参实现，这就是控制反转，方便代码解耦。
上文示例有说明。
DI（依赖注入）
依赖注入是控制反转的一种实现方式
依赖注入函数内部传参，有助于提高代码的模块化、可测试性和灵活性，通俗讲就是按（开发者）需加载。
如下，UserController依赖于UserService类。在控制器的构造函数中注入了 UserService，而不是在 UserController 中实例化UserService的实例。Laravel的服务容器的反射机制会自动解析这个依赖关系。
class UserController extends Controller {
protected $userService;
public function __construct(UserService $userService) {
$this->userService = $userService;
}
}
Contract（契约）
看了容器的源码，发现有用到，顺便提一嘴。
听起来高大上，移除Laravel框架高大上的思维枷锁，也就一堆接口，用于规范化代码，实现大体布局，子类用它实现细节，没什么神奇的高科技。
Provider（服务提供者）
多个服务提供者组成一个容器，新建的provider需要再config/app.php中声明。
用于注册应用程序的服务、绑定依赖关系以及其它初始化操作，真用到的时候就去实现，没那么严谨。
先调用register方法，然后会去调用boot方法。
这个在安装某些插件的时候回去用这个，composer包里的代码，不足以支撑当前的应用场景，所以需要做一些配置，然后就用到了Provider。
app()、resolve()
我看到前公司技术老大经常这样用，以我目前的认知来看，这和直接用命名空间的逻辑去调用一个类没什么区别。
- app(); 返回服务容器实例,参数可传递类名，表示调用那个类。
- resolve();app()的别名， 函数使用服务容器解析给定名称的类或接口的实例，参数可传递类名，表示调用那个类。
