设计模式

服务容器

容器 通俗的理解就是装东西的物体，常见的一个变量、一个对象等都可以看成一个容器，而服务容器就是提供服务的载体。在这里，我们可以将服务理解为系统运行中需要的东西，如对象、文件路径、系统配置等，服务容器就是这些东西的载体，在程序运行过程中动态地为系统提供这些服务，也可以看做是提供这些资源。

$abstract 服务名称
$concrete 服务名称的实体

bind($abstract, $concrete=null, $shared=false)
 - getClosure($abstract, $concrete)

make($abstract)
 - getConcrete($abstract)
 - isBuildable($abstract, $concrete)

build($concrete)
/**
 * ↓
 * ReflectionClass($concrete)
 * $reflector->isInstantiable()
 * getConstructor()
 * getParameters()
 * ↓
 */
 -  $instances = getDependencies($dependencies)
 /**
 *  *$reflector->newInstanceArgs($instances)
 */

 - resolveClass(ReflectionParameter $parameter)

IOC模式

IoC（Inversion of Control）模式又称依赖注入（Dependency Injection）模式
注入实例针对接口编程

Laravel框架的官方文档中，将其称为服务容器，核心功能是IoC容器用以解决依赖注入，而对服务容器的填充部分称为服务提供者，所以对于Laravel框架来说这种叫法更贴切，因为框架中的Container类并不仅仅完成了IoC容器的功能，还在程序运行过程中提供各种相应的服务，包括对象、生成对象的回调函数、配置等。

源码解析

服务容器工作示意图

服务绑定有时也称为服务注册，在全文中两者意义相同，只是对于不同上下文环境某种说法更加贴切而已。

• $bindings用于存储提供服务的回调函数，
• $instances用于存储程序中共享的实例，也可以称为单例。

singleton（）函数实现的是单例绑定，即程序中如果没有服务名称对应的实例对象，则通过服务容器实例化一个后并进行记录，如果在后续程序中还需要同名的服务时则返回先前创建的服务实例对象。该函数相当于bind（）函数的一个特例，即参数$shared值为true的情况。对于bind（）函数实现的服务绑定功能，在忽略$shared参数的情况下，即不讨论单例还是普通的服务，可以分为两种情况，

如果参数$concrete为一个回调函数，则直接将回调函数与服务名称$abstract进行绑定；

如果参数$concrete为一个名称，则首先需要通过getClosure（）函数创建服务回调函数，然后将该回调函数与服务名称绑定，总之需要实现一个可以生成相应服务实例对象的回调函数与服务名称进行绑定。

服务解析过程略微复杂一点，可以将其分为两个步骤来完成，

一个是完成对应服务的查找，由make（）函数完成
另一个是完成服务的实现，一般是指完成实例化对象的创建，由build（）函数完成。

** make() **

$abstract 服务名称
getAlias() 是否有别名
$instances 共享实例数组（单例）
getConcrete() 获取服务名称的实体
isBuildable()函数判断服务实体是否能创建实例化对象 (可以就build创建，否则继续make查找)

首先介绍服务查找过程，即由make（）函数实现的功能。该函数需要提供两个参数，分别是$abstract和$parameters，$abstract可以看做是服务名称，而$parameters是创建实例化对象需要的参数，即一个类实例化时的依赖。对于服务的查找是根据服务名称$abstract来进行的，首先通过getAlias（）函数来查找服务名称是否有别名，对于服务别名的管理是通过服务容器类中的$aliases数组属性实现的，而内容基本是通过Illuminate\Foundation\Application类中的registerCoreContainerAliases（）函数注册的，如一个简单的实例，Illuminate\Contracts\Container\Container抽象类的别名为“app”，如果查找到了别名，将查找该别名对应的服务，如果该抽象类没有别名，则继续进行查找。然后在服务容器的共享实例数组（$instances属性）中查找服务名称的实例，如果查找到则说明该服务名称对应为单例，直接返回先前实例化的对象，否则继续查询。接下来，会通过getConcrete（）获取服务名称的实体，在服务绑定时，一个服务名称一般绑定一个回调函数用于生成实例对象，而这个回调函数就相当于服务名称的实体。这个实体的查找就是通过容器中的$bindings数组属性实现的，如果查找到则返回实体，否则修改服务名称的形式继续下一次的查找。然后，会通过isBuildable（）函数判断服务实体能否创建实例化对象，如果可以则转到下一个步骤，否则继续通过make（）函数来查找。在完成实例对象的创建后，通过isShared（）判断该服务是否为单例，如果是需要在共享实例对象数组（$instances）中记录。

** build() **

服务实体是闭包函数直接调用该闭包
服务实体只是一个具体类的类名，通过反射机制完成实例化对象的创建
- ReflectionClass 获取反射类实例
- getConstructor() 是否有构造函数即依赖
- getDependencies() 实现依赖的生成

在通过make（）函数查找到服务实体后，会将其传递给build（）函数用于对象的创建，如果服务实体就是一个闭包函数，则直接调用该闭包函数完成服务实例化对象的创建，如果服务实体只是一个具体类的类名，则需要通过反射机制来完成实例化对象的创建。通过反射机制完成对象实例化的过程，首先是根据将要实例化的类名称获取反射类（ReflectionClass）实例，然后获取该类在实例化过程中的依赖，即构造函数需要的参数，在build（）函数中，通过getDependencies（）函数来实现依赖的生成，如果在服务解析时提供了相应的参数，即通过$parameters参数提供，则直接使用提供的参数，如果没有提供，则通过服务容器中的resolveNonClass（）函数来获取默认参数，或者通过resolveClass（）函数来创建，而创建的方式也是通过服务容器，所以服务容器解决依赖注入的问题就是通过这部分代码实现的。在解决了依赖的问题后，可以直接通过反射机制完成服务实例对象的创建。

请求处理管道

对于服务器来说，真正要实现的功能是处理输入的请求，并将生成的响应输出给客户端，而在处理请求的过程中需要经历很多处理步骤，这些步骤需要做到松耦合，可以 随时在这些步骤中间添加新的处理功能而使改动尽可能小 ，通过源码的注解，设计者将其比喻成“洋葱”，像它一样分很多层，每一层具有一定的功能，可以随时添加或修改这些层，而官方文档中将这些层称为中间件，通过这些中间件使得程序的可扩展性大大增强。这里，其实使用的是一种装饰者模式，只是PHP特有的编程方式使得其形式发生变化，下面我们就逐步揭开它的面纱。

装饰者模式