Laravel 서비스 컨테이너 인스턴스 튜토리얼: 제어 반전(IoC) 및 종속성 주입(DI)에 대한 심층적인 이해

이 글은 Laravel Service Container Instance Tutorial에 대한 IoC(Inversion of Control) 및 DI(의존성 주입)에 대한 심층적인 이해를 소개합니다. 이제 필요한 친구들이 참고할 수 있도록 공유합니다.

친절한 알림: 이 기사는 약간 길지만 확실히 유용한 정보로 가득 차 있습니다. 인내심을 갖고 끝까지 읽으면 분명히 뭔가를 얻을 것입니다!

컨테이너는 말 그대로 물건을 담는다는 뜻입니다. 공통 변수, 객체 속성 등은 컨테이너로 간주될 수 있습니다. 컨테이너에 담을 수 있는 내용은 전적으로 컨테이너를 정의하는 방법에 따라 달라집니다. 물론 텍스트나 값을 저장하지 않고 객체, 객체 설명(클래스, 인터페이스)을 저장하거나 객체에 대한 콜백을 제공하는 컨테이너가 있습니다. 이 컨테이너를 통해 우리는 많은 고급 기능을 구현할 수 있으며 그 중 가장 중요한 기능은 다음과 같습니다. 자주 언급되는 것은 "디커플링(decoupling)"과 "의존성 주입(DI)"이다. 이 글은 여기서 시작됩니다.

IoC 컨테이너 - Laravel의 핵심

Laravel의 핵심은 문서에 따르면 "서비스 컨테이너"라고 불리는 IoC 컨테이너입니다. 이 컨테이너는 전체 프레임워크에 필요한 일련의 서비스를 제공합니다. . 초보자로서 많은 사람들이 이 개념에 어려움을 겪을 것입니다. 따라서 저는 몇 가지 기본적인 내용부터 시작하여 객체 지향 개발의 종속성 생성 및 해결 방법을 점차적으로 이해함으로써 "종속성 주입"의 베일을 벗겨나갈 계획입니다. 디자인 컨셉.

이 기사의 대부분은 독자가 IoC(제어 반전) 및 DI(종속성 주입)가 무엇인지 이해할 수 있도록 예제를 사용합니다. laravel 서비스 컨테이너 사용에 대한 자세한 내용은 설명서를 참조하세요.

IoC 컨테이너 탄생 이야기

IoC 컨테이너를 설명하는 글은 많고, 제가 쓴 적이 있습니다. 하지만 이제 나는 그 순간의 영감을 사용하여 다시 시작하려고 합니다.

슈퍼맨과 초능력, 의존성의 출현

객체 지향 프로그래밍에는 인터페이스, 클래스, 객체 등 항상 접촉하는 것들이 있습니다. 그중 인터페이스는 클래스의 프로토타입이고 클래스는 구현하는 인터페이스를 준수해야 합니다. 객체는 인스턴스라고 부르는 클래스 인스턴스화의 산물입니다. 물론, 이것이 이해에 도움이 되지 않는다고 말하는 것은 실제로 학습에 도움이 되지 않는다고 생각되는 코드를 작성해 보겠습니다.

괴물이 만연한 세상에서는 일을 원활하게 하기 위해 항상 슈퍼 캐릭터가 필요합니다.

우리는 "슈퍼맨"을 클래스로 간주합니다.

class Superman {}

슈퍼맨은 태어날 때 적어도 하나의 초능력을 가져야 한다고 상상할 수 있습니다. 이 초능력은 객체로도 추상화될 수 있으며, 이를 설명하는 클래스가 정의됩니다. 이 개체에 대한. 초능력에는 여러 속성과 (작동) 방법이 있어야 합니다. 이것을 자유롭게 상상할 수 있지만 지금은 속성만 있는 "초능력"을 대략적으로 정의하겠습니다. 이번에는 이전 "Superman" 클래스로 돌아가서 "Superman"이 생성될 때 초능력을 부여하도록 수정합니다.

class Power {
   /**
    * 能力值
    */
   protected $ability;

   /**
    * 能力范围或距离
    */
   protected $range;

   public function __construct($ability, $range)
   {
       $this->ability = $ability;
       $this->range = $range;
   }
}

이 경우 "Superman" 인스턴스를 생성할 때 다음과 같은 클래스도 생성합니다. "슈퍼맨" 그러나 우리는 "슈퍼맨"과 "초능력" 사이에 필연적인 의존성이 있음을 살펴보았습니다.

소위 '의존'이란 '내가 당신에게 의지하면 당신을 떠날 수 없다'는 뜻입니다.

객체 지향 프로그래밍을 구현하는 프로젝트에서는 이러한 종속성을 어디에서나 볼 수 있습니다. 소량의 의존은 그다지 직관적인 영향을 미치지 않습니다. 이 예를 점차 전개해 나가면서 우리는 의존이 특정 수준에 도달했을 때 그것이 얼마나 악몽 같은 경험인지 점차 깨닫게 될 것입니다. 물론 문제 해결 방법도 자연스럽게 설명해드립니다.

Abunch of mess - 끔찍한 의존성

이전 예에서 초능력 클래스는 인스턴스화 후 특정 초능력이지만, 우리는 슈퍼맨의 초능력이 다양하고, 각 초능력의 방법이 상당히 다르다는 것을 알고 있습니다. 하나의 클래스로 완전히 설명됩니다. 이제 수정해 보겠습니다. 슈퍼맨이 다음과 같은 초능력을 가질 수 있다고 가정해 보겠습니다.

비행, 속성: 비행 속도, 비행 시간

무차별적인 힘, 속성: 힘 값

에너지 폭탄, 속성: 손상 값, 사격 거리, 동시 촬영 횟수

저희는 다음 클래스를 만들었습니다.

class Superman
{
   protected $power;

   public function __construct()
   {
       $this->power = new Power(999, 100);
   }
}

문제를 해결하기 위해 전체 __construct() 생성자를 자세히 작성하지 않고 전달해야 하는 매개변수만 작성했습니다.

그래요, 우리 슈퍼맨은 지금 좀 "바빠"요. 슈퍼맨이 초기화되면 필요에 따라 그의 초능력을 인스턴스화할까요? 대략 다음과 같습니다:

class Flight
{
   protected $speed;
   protected $holdtime;
   public function __construct($speed, $holdtime) {}
}

class Force
{
   protected $force;
   public function __construct($force) {}
}

class Shot
{
   protected $atk;
   protected $range;
   protected $limit;
   public function __construct($atk, $range, $limit) {}
}

생성자(또는 다른 메서드)에서 일련의 필수 클래스를 수동으로 인스턴스화해야 하므로 좋지 않습니다. 요구 사항이 바뀌거나(지구에 다양한 괴물이 만연해 있는 경우) 더 많은 목표를 가진 새로운 초능력이 필요하거나 초능력의 방법을 변경해야 한다면 우리는 슈퍼맨을 재창조해야 한다고 생각할 수 있습니다. 즉, 나의 ​​초능력을 바꾸는 동시에 새로운 슈퍼맨도 창조해야 한다는 것이다. 효율성이 너무 낮습니다! 새로운 슈퍼맨이 탄생하기 전에 세상은 이미 파괴되었습니다.

这时，灵机一动的人想到：为什么不可以这样呢？超人的能力可以被随时更换，只需要添加或者更新一个芯片或者其他装置啥的（想到钢铁侠没）。这样的话就不要整个重新来过了。

对，就是这样的。

我们不应该手动在 “超人” 类中固化了他的 “超能力” 初始化的行为，而转由外部负责，由外部创造超能力模组、装置或者芯片等（我们后面统一称为 “模组”），植入超人体内的某一个接口，这个接口是一个既定的，只要这个 “模组” 满足这个接口的装置都可以被超人所利用，可以提升、增加超人的某一种能力。这种由外部负责其依赖需求的行为，我们可以称其为 “控制反转（IoC）”。

工厂模式，依赖转移！

当然，实现控制反转的方法有几种。在这之前，不如我们先了解一些好玩的东西。

我们可以想到，组件、工具（或者超人的模组），是一种可被生产的玩意儿，生产的地方当然是 “工厂（Factory）”，于是有人就提出了这样一种模式： 工厂模式。

工厂模式，顾名思义，就是一个类所依赖的外部事物的实例，都可以被一个或多个 “工厂” 创建的这样一种开发模式，就是 “工厂模式”。

我们为了给超人制造超能力模组，我们创建了一个工厂，它可以制造各种各样的模组，且仅需要通过一个方法：

class SuperModuleFactory
{
   public function makeModule($moduleName, $options)
   {
       switch ($moduleName) {
           case 'Fight': 
               return new Fight($options[0], $options[1]);
           case 'Force': 
               return new Force($options[0]);
           case 'Shot': 
               return new Shot($options[0], $options[1], $options[2]);
       }
   }
}

这时候，超人 创建之初就可以使用这个工厂！

class Superman
{
   protected $power;

   public function __construct()
   {
       // 初始化工厂
       $factory = new SuperModuleFactory;

       // 通过工厂提供的方法制造需要的模块
       $this->power = $factory->makeModule('Fight', [9, 100]);
       // $this->power = $factory->makeModule('Force', [45]);
       // $this->power = $factory->makeModule('Shot', [99, 50, 2]);
       /*
       $this->power = array(
           $factory->makeModule('Force', [45]),
           $factory->makeModule('Shot', [99, 50, 2])
       );
       */
   }
}

可以看得出，我们不再需要在超人初始化之初，去初始化许多第三方类，只需初始化一个工厂类，即可满足需求。但这样似乎和以前区别不大，只是没有那么多 new 关键字。其实我们稍微改造一下这个类，你就明白，工厂类的真正意义和价值了。

class Superman
{
   protected $power;

   public function __construct(array $modules)
   {
       // 初始化工厂
       $factory = new SuperModuleFactory;

       // 通过工厂提供的方法制造需要的模块
       foreach ($modules as $moduleName => $moduleOptions) {
           $this->power[] = $factory->makeModule($moduleName, $moduleOptions);
       }
   }
}

// 创建超人
$superman = new Superman([
   'Fight' => [9, 100],
   'Shot' => [99, 50, 2]
]);

现在修改的结果令人满意。现在，“超人” 的创建不再依赖任何一个 “超能力” 的类，我们如若修改了或者增加了新的超能力，只需要针对修改 SuperModuleFactory 即可。扩充超能力的同时不再需要重新编辑超人的类文件，使得我们变得很轻松。但是，这才刚刚开始。

IoC 容器的重要组成 —— 依赖注入

由 “超人” 对 “超能力” 的依赖变成 “超人” 对 “超能力模组工厂” 的依赖后，对付小怪兽们变得更加得心应手。但这也正如你所看到的，依赖并未解除，只是由原来对多个外部的依赖变成了对一个 “工厂” 的依赖。假如工厂出了点麻烦，问题变得就很棘手。

其实大多数情况下，工厂模式已经足够了。工厂模式的缺点就是：接口未知（即没有一个很好的契约模型，关于这个我马上会有解释）、产生对象类型单一。总之就是，还是不够灵活。虽然如此，工厂模式依旧十分优秀，并且适用于绝大多数情况。不过我们为了讲解后面的依赖注入 ，这里就先夸大一下工厂模式的缺陷咯。

我们知道，超人依赖的模组，我们要求有统一的接口，这样才能和超人身上的注入接口对接，最终起到提升超能力的效果。

事实上，我之前说谎了，不仅仅只有一堆小怪兽，还有更多的大怪兽。嘿嘿。额，这时候似乎工厂的生产能力显得有些不足 —— 由于工厂模式下，所有的模组都已经在工厂类中安排好了，如果有新的、高级的模组加入，我们必须修改工厂类（好比增加新的生产线）：

class SuperModuleFactory
{
   public function makeModule($moduleName, $options)
   {
       switch ($moduleName) {
           case 'Fight': 
               return new Fight($options[0], $options[1]);
           case 'Force': 
               return new Force($options[0]);
           case 'Shot': 
               return new Shot($options[0], $options[1], $options[2]);
           // case 'more': .......
           // case 'and more': .......
           // case 'and more': .......
           // case 'oh no! its too many!': .......
       }
   }
}

看到没。。。噩梦般的感受！

其实灵感就差一步！你可能会想到更为灵活的办法！对，下一步就是我们今天的主要配角 —— DI （依赖注入）

由于对超能力模组的需求不断增大，我们需要集合整个世界的高智商人才，一起解决问题，不应该仅仅只有几个工厂垄断负责。不过高智商人才们都非常自负，认为自己的想法是对的，创造出的超能力模组没有统一的接口，自然而然无法被正常使用。这时我们需要提出一种契约，这样无论是谁创造出的模组，都符合这样的接口，自然就可被正常使用。

interface SuperModuleInterface
{
   /**
    * 超能力激活方法
    *
    * 任何一个超能力都得有该方法，并拥有一个参数
    *@param array $target 针对目标，可以是一个或多个，自己或他人
    */
   public function activate(array $target);
}

上文中，我们定下了一个接口 （超能力模组的规范、契约），所有被创造的模组必须遵守该规范，才能被生产。

其实，这就是 php 中接口（ interface ）的用处和意义！很多人觉得，为什么 php 需要接口这种东西？难道不是 java 、 C# 之类的语言才有的吗？这么说，只要是一个正常的面向对象编程语言（虽然 php 可以面向过程），都应该具备这一特性。因为一个 对象（object） 本身是由他的模板或者原型 —— 类 （class） ，经过实例化后产生的一个具体事物，而有时候，实现统一种方法且不同功能（或特性）的时候，会存在很多的类（class），这时候就需要有一个契约，让大家编写出可以被随时替换却不会产生影响的接口。这种由编程语言本身提出的硬性规范，会增加更多优秀的特性。

虽然有些绕，但通过我们接下来的实例，大家会慢慢领会接口带来的好处。

这时候，那些提出更好的超能力模组的高智商人才，遵循这个接口，创建了下述（模组）类：

/**
* X-超能量
*/
class XPower implements SuperModuleInterface
{
   public function activate(array $target)
   {
       // 这只是个例子。。具体自行脑补
   }
}

/**
* 终极* （就这么俗）
*/
class UltraBomb implements SuperModuleInterface
{
   public function activate(array $target)
   {
       // 这只是个例子。。具体自行脑补
   }
}

同时，为了防止有些 “砖家” 自作聪明，或者一些叛徒恶意捣蛋，不遵守契约胡乱制造模组，影响超人，我们对超人初始化的方法进行改造：

class Superman
{
   protected $module;

   public function __construct(SuperModuleInterface $module)
   {
       $this->module = $module;
   }
}

改造完毕！现在，当我们初始化 “超人” 类的时候，提供的模组实例必须是一个 SuperModuleInterface 接口的实现。否则就会提示错误。

正是由于超人的创造变得容易，一个超人也就不需要太多的超能力，我们可以创造多个超人，并分别注入需要的超能力模组即可。这样的话，虽然一个超人只有一个超能力，但超人更容易变多，我们也不怕怪兽啦！

现在有人疑惑了，你要讲的依赖注入呢？

其实，上面讲的内容，正是依赖注入。

什么叫做依赖注入？

本文从开头到现在提到的一系列依赖，只要不是由内部生产（比如初始化、构造函数 __construct 中通过工厂方法、自行手动 new 的），而是由外部以参数或其他形式注入的，都属于依赖注入（DI） 。是不是豁然开朗？事实上，就是这么简单。下面就是一个典型的依赖注入：

// 超能力模组
$superModule = new XPower;
// 初始化一个超人，并注入一个超能力模组依赖
$superMan = new Superman($superModule);

关于依赖注入这个本文的主要配角，也就这么多需要讲的。理解了依赖注入，我们就可以继续深入问题。慢慢走近今天的主角……

更为先进的工厂 —— IoC 容器

刚刚列了一段代码：

$superModule = new XPower;
$superMan = new Superman($superModule);

读者应该看出来了，手动的创建了一个超能力模组、手动的创建超人并注入了刚刚创建超能力模组。呵呵，手动。

现代社会，应该是高效率的生产，干净的车间，完美的自动化装配。

一群怪兽来了，如此低效率产出超人是不现实，我们需要自动化 —— 最多一条指令，千军万马来相见。我们需要一种高级的生产车间，我们只需要向生产车间提交一个脚本，工厂便能够通过指令自动化生产。这种更为高级的工厂，就是工厂模式的升华 —— IoC 容器。

class Container
{
   protected $binds;

   protected $instances;

   public function bind($abstract, $concrete)
   {
       if ($concrete instanceof Closure) {
           $this->binds[$abstract] = $concrete;
       } else {
           $this->instances[$abstract] = $concrete;
       }
   }

   public function make($abstract, $parameters = [])
   {
       if (isset($this->instances[$abstract])) {
           return $this->instances[$abstract];
       }

       array_unshift($parameters, $this);

       return call_user_func_array($this->binds[$abstract], $parameters);
   }
}

这时候，一个十分粗糙的容器就诞生了。现在的确很简陋，但不妨碍我们进一步提升他。先着眼现在，看看这个容器如何使用吧！

// 创建一个容器（后面称作超级工厂）
$container = new Container;

// 向该 超级工厂添加超人的生产脚本
$container->bind('superman', function($container, $moduleName) {
   return new Superman($container->make($moduleName));
});

// 向该 超级工厂添加超能力模组的生产脚本
$container->bind('xpower', function($container) {
   return new XPower;
});

// 同上
$container->bind('ultrabomb', function($container) {
   return new UltraBomb;
});

// ****************** 华丽丽的分割线 **********************
// 开始启动生产
$superman_1 = $container->make('superman', 'xpower');
$superman_2 = $container->make('superman', 'ultrabomb');
$superman_3 = $container->make('superman', 'xpower');
// ...随意添加

看到没？通过最初的 绑定（bind） 操作，我们向 超级工厂 注册了一些生产脚本，这些生产脚本在生产指令下达之时便会执行。发现没有？我们彻底的解除了 超人 与 超能力模组 的依赖关系，更重要的是，容器类也丝毫没有和他们产生任何依赖！我们通过注册、绑定的方式向容器中添加一段可以被执行的回调（可以是匿名函数、非匿名函数、类的方法）作为生产一个类的实例的 脚本 ，只有在真正的 生产（make） 操作被调用执行时，才会触发。

这样一种方式，使得我们更容易在创建一个实例的同时解决其依赖关系，并且更加灵活。当有新的需求，只需另外绑定一个“生产脚本”即可。

实际上，真正的 IoC 容器更为高级。我们现在的例子中，还是需要手动提供超人所需要的模组参数，但真正的 IoC 容器会根据类的依赖需求，自动在注册、绑定的一堆实例中搜寻符合的依赖需求，并自动注入到构造函数参数中去。Laravel 框架的服务容器正是这么做的。实现这种功能其实理论上并不麻烦，但我并不会在本文中写出，因为……我懒得写。

不过我告诉大家，这种自动搜寻依赖需求的功能，是通过反射（Reflection）实现的，恰好的，php 完美的支持反射机制！关于反射，php 官方文档有详细的资料，并且中文翻译基本覆盖，足够学习和研究：

http://php.net/manual/zh/book.reflection.php

现在，到目前为止，我们已经不再惧怕怪兽们了。高智商人才集思广益，井井有条，根据接口契约创造规范的超能力模组。超人开始批量产出。最终，人人都是超人，你也可以是哦！

重新审视 Laravel 的核心

现在，我们开始慢慢解读 Laravel 的核心。其实，Laravel 的核心就是一个 IoC 容器，也恰好是我之前所说的高级的 IoC 容器。

可以说，Laravel 的核心本身十分轻量，并没有什么很神奇很实质性的应用功能。很多人用到的各种功能模块比如 Route（路由）、Eloquent ORM（数据库 ORM 组件）、Request（请求）以及 Response（响应）等等等等，实际上都是与核心无关的类模块提供的，这些类从注册到实例化，最终被你所使用，其实都是 Laravel 的服务容器负责的。

我们以大家最常见的 Route 类作为例子。大家可能经常见到路由定义是这样的：

Route::get('/', function() {
   // bla bla bla...
});

实际上， Route 类被定义在这个命名空间：Illuminate\Routing\Router，文件 vendor/laravel/framework/src/Illuminate/Routing/Router.php。

我们通过打开发现，这个类的这一系列方法，如 get，post，any 等都不是静态（static）方法，这是怎么一回事儿？不要急，我们继续。

服务提供者

我们在前文介绍 IoC 容器的部分中，提到了，一个类需要绑定、注册至容器中，才能被“制造”。

对，一个类要被容器所能够提取，必须要先注册至这个容器。既然 Laravel 称这个容器叫做服务容器，那么我们需要某个服务，就得先注册、绑定这个服务到容器，那么提供服务并绑定服务至容器的东西，就是服务提供者（Service Provider）。

虽然，绑定一个类到容器不一定非要通过服务提供者。

但是，我们知道，有时候我们的类、模块会有需要其他类和组件的情况，为了保证初始化阶段不会出现所需要的模块和组件没有注册的情况，Laravel 将注册和初始化行为进行拆分，注册的时候就只能注册，初始化的时候就是初始化。拆分后的产物就是现在的服务提供者。

服务提供者主要分为两个部分，register（注册） 和 boot（引导、初始化），具体参考文档。register 负责进行向容器注册“脚本”，但要注意注册部分不要有对未知事物的依赖，如果有，就要移步至 boot 部分。

门面（Facade）

我们现在解答之前关于 Route 的方法为何能以静态方法访问的问题。实际上这个问题文档上有写，简单说来就是模拟一个类，提供一个静态魔术方法__callStatic，并将该静态方法映射到真正的方法上。

我们使用的 Route 类实际上是 Illuminate\Support\Facades\Route 通过 class_alias() 函数创造的别名而已，这个类被定义在文件 vendor/laravel/framework/src/Illuminate/Support/Facades/Route.php 。

我们打开文件一看……诶？怎么只有这么简单的一段代码呢？

<?php 
   namespace Illuminate\Support\Facades;

   /**
    * @see \Illuminate\Routing\Router
    */
   class Route extends Facade {

       /**
        * Get the registered name of the component.
        *
        * @return string
        */
       protected static function getFacadeAccessor()
       {
           return &#39;router&#39;;
       }

}

其实仔细看，会发现这个类继承了一个叫做 Facade 的类，到这里谜底差不多要解开了。

上述简单的定义中，我们看到了 getFacadeAccessor 方法返回了一个 route，这是什么意思呢？事实上，这个值被一个 ServiceProvider 注册过，大家应该知道注册了个什么，当然是那个真正的路由类！

有人会问，Facade 是怎么实现的。我并不想说得太细，一个是我懒，另一个原因就是，自己发现一些东西更容易理解，并不容易忘记。很多细节我已经说了，建议大家自行去研究。

本文整理自：https://www.insp.top/article/learn-laravel-container

相关推荐：

laravel框架中常用目录路径详解

Laravel 的队列系统介绍

위 내용은 Laravel 서비스 컨테이너 인스턴스 튜토리얼: 제어 반전(IoC) 및 종속성 주입(DI)에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!