谈谈php里的IOC控制反转，DI依赖注入

时间 2019-11-29

标签谈谈 php ioc 控制反转依赖注入栏目 PHP 繁體版

原文原文链接

理论

发现问题

在深刻细节以前，须要确保咱们理解"IOC控制反转"和"DI依赖注入"是什么，可以解决什么问题，这些在维基百科中有很是清晰的说明。php

控制反转（Inversion of Control，缩写为IoC）：是面向对象编程中的一种设计原则，能够用来减低计算机代码之间的耦合度。
依赖注入（Dependency Injection，简称DI）：DI是IOC的一种实现，表现为：在类A的实例建立过程当中即建立了依赖的B对象，经过类型或名称来判断将不一样的对象注入到不一样的属性中。
依赖查找（Dependency Lookup，简称DL）：DL是IOC的另一种实现，在须要的时候经过调用框架提供的方法来获取对象，获取时须要提供相关的配置文件路径、key等信息来肯定获取对象

依赖注入与依赖查找是控制反转的2种实现方式，后者不多见，咱们主要研究依赖注入。程序员

若是此前没有接触过这些概念，可能仍是过于抽象不容易理解，可是下面这个场景你应该是见过的：编程

由于大多数应用程序都是由两个或是更多的类经过彼此的合做来实现业务逻辑，这使得每一个对象都须要获取与其合做的对象（也就是它所依赖的对象）的引用。若是这个获取过程要靠自身实现，那么这将致使代码高度耦合而且难以维护和调试。swift

也就是说："Class A中用到了Class B的对象b，通常状况下，须要在A的代码中显式的new一个B的对象"，这就致使若是A想将B替换为一个更优的实现版本B+时，须要修改代码显式的new一个B+对象。缓存

解决这个问题的传统作法通常是为B和B+提取一个InterfaceOfB接口，而后让class A只依赖InterfaceOfB，最终由A类的调用方决定传入B仍是B+对象，修改调用方代码和修改类A代码对咱们来讲并无本质的改变，那是否有更好的方式呢？yii2

解决思路

终于，懒惰的程序员对这种代码开发方式感到厌烦：由于咱们在代码里控制了B类对象的生成，从而致使代码耦合，即使A类依赖InterfaceOfB，仍是要在程序某处写死new B()或者new B+()这样的代码，怎么破解？框架

答案是：将B类对象的生成交给一个独立的对象生成器来负责，那么A类只须要依赖这个对象生成器，而至于究竟是生成B仍是B+对象，则是对象生成器内部的行为，这样就将A和B解耦开了，这就是所谓的"控制反转"，即将控制权交给了对象生成器。yii

这么简单的将问题抛给对象生成器可不行，由于对象生成器还要面临new B仍是new B+的硬编码问题，所以必须赋予对象生成器一个超能力：函数

在对象生成器的配置文件中进行这样的描述：{"InterfaceOfB" : "Class B+"}，表示InterfaceOfB接口应该实例化B+对象。
A类构造函数有一个InterfaceOfB的入参，例如：function __construct(InterfaceOfB obj)。
调用对象生成器（DI）获取A类对象，DI->get("class A")。对象生成器会利用反射分析class A的构造函数，发现InterfaceOfB参数后根据此前配置文件描述，new B+()对象传入到A的构造函数，从而生成A对象。

总结上述流程就是：对象生成器经过反射机制分析A类的构造函数依赖，并根据配置中的关系生成依赖的对象实例传入给构造函数，最终完成A类对象的建立。性能

上面的过程就是"依赖注入"主要实现方式了，对象生成器咱们一般成为"DI Container"，也就是"依赖注入容器"。

须要注意的是：B或者B+的构造函数能够会依赖InterfaceOfC，所以整个依赖关系的分析是递归的。

实践

上面在谈'DI依赖注入"的时候，咱们很是清楚的了解到 DI会根据构造函数进行依赖分析，可是很容易忽视{"InterfaceOfB" : "Class B+"}这个信息的来源。若是DI不知道这个信息，那么在分析构造函数时是不可能知道接口InterfaceOfB应该对应什么对象的，这个信息在DI实现中通常是经过set方法主动设置到DI容器的依赖关系中的，固然这个信息的存储介质能够是配置文件或者硬编码传入。

下面拿PHP的Yii2.0框架为例，看看它实现DI时的核心思路是什么，不会讲的太细，但上面提到的思路和概念都会有所体现。

set设置类定义

public function set($class, $definition = [], array $params = [])
{
    $this->_definitions[$class] = $this->normalizeDefinition($class, $definition);
    $this->_params[$class] = $params;
    unset($this->_singletons[$class]);
    return $this;
}

这就是上面提到{"InterfaceOfB" : "Class B+"}的设置接口，好比这样用：

$container->set('yii\mail\MailInterface', 'yii\swiftmailer\Mailer');

意思就是若是遇到依赖MailInterface的，那么构造一个Mailer对象给它，params是用于传给Mailer::__construct的构造参数，以前提过依赖分析是递归的，Mailter对象的构造也是DI负责的（不是简单的new出来），一旦你传了构造参数给Mailer，那么DI就不用反射分析Mailter的依赖了，直接传入params既可new一个Mailer出来。

get生成类对象

public function get($class, $params = [], $config = [])
    {
        if (isset($this->_singletons[$class])) {
            // singleton
            // 此前已经get过而且设置为单例，那么返回单例对象既可
            return $this->_singletons[$class];
        } elseif (!isset($this->_definitions[$class])) {
            // 非单例须要生成新对象，可是此前没有set过类定义，
            // 所以只能直接反射分析构造函数的依赖
            return $this->build($class, $params, $config);
        }

        // 此前设置过的类定义，对类进行了更具体的定义，帮助咱们更快的构造出对象
        $definition = $this->_definitions[$class];

        // 类定义能够是一个函数，用于直接为DI生成对象
        if (is_callable($definition, true)) {
            // 将set设置的构造参数和本次传入的构造参数merge到一块儿
            // 而后分析这些传入的构造参数是否为实参（好比:int,string），这是由于yii容许
            // params是Instance对象，它表明了另一个类定义（它内部指向了DI容器中某个definition)
            // 为了这种构造参数可以传入到当前的构造函数，须要递归调用di->get将其建立为实参。
            $params = $this->resolveDependencies($this->mergeParams($class, $params));
            // 这个就是函数式的分配对象，前提是构造参数须要确保都是实参
            $object = call_user_func($definition, $this, $params, $config);
        } elseif (is_array($definition)) { // 普通的类定义
            $concrete = $definition['class'];
            unset($definition['class']);

            // 把set设置的config和此次传入的config合并一下
            $config = array_merge($definition, $config);
            // 把set设置的params构造参数和此次传入的构造参数合并一下
            $params = $this->mergeParams($class, $params);

            // 这里: $class表明的就是MailInterface，而$concrete表明的是Mailer
            if ($concrete === $class) {
                // 这里是递归出口，生成目标class对象既可，没有什么可研究的
                $object = $this->build($class, $params, $config);
            } else {
                // 显然，这里要构造MailInterface是等同于去构造Mailer对象
                $object = $this->get($concrete, $params, $config);
            }
        } elseif (is_object($definition)) {
            return $this->_singletons[$class] = $definition;
        } else {
            throw new InvalidConfigException("Unexpected object definition type: " . gettype($definition));
        }

        if (array_key_exists($class, $this->_singletons)) {
            // singleton
            $this->_singletons[$class] = $object;
        }

        return $object;
    }

实现思路在此前的分析里都说的很明白了，并非很难理解。这个函数经过class指定要分配的类，params指定了构造参数，和以前的set原理同样：若是构造参数齐全是不须要分析依赖的。（最后的config是要注入到对象的额外属性，属于yii2特性，不是重点）。

至于build构造对象时，又须要作什么呢？就是基于反射机制获取构造函数依赖了哪些类，而后若是params传入了构造参数那么直接使用params参数，若是没有指定则须要递归的DI->get()去生成实参，最终经过构造函数生成对象。

 protected function build($class, $params, $config)
    {
        /* @var $reflection ReflectionClass */
        // 利用反射，分析类构造函数的参数，
        // 其中，返回值reflection是class的反射对象，
        // dependencies就是构造函数的全部参数了，有几种状况：
        // 1，参数有默认值，直接用
        // 2, 没有默认值，而且不是int这种非class，那么返回Instance指向对应的class，等待下面的递归get
        list ($reflection, $dependencies) = $this->getDependencies($class);

        // 传入的构造函数参数优先级最高，直接覆盖前面反射分析的构造参数
        foreach ($params as $index => $param) {
            $dependencies[$index] = $param;
        }

        // 完整的检查一次参数，若是依赖是指向class的Instance，那么递归DI->get获取实例
        // 若是是指定int,string这种的Instance，那么说明调用者并无params传入值，构造函数默认参数也没有值，
        // 必须抛异常
        // 若是不是Instance，说明是params用户传入的实参能够直接用
        $dependencies = $this->resolveDependencies($dependencies, $reflection);
        if (empty($config)) {
            return $reflection->newInstanceArgs($dependencies);
        }
        // 最后经过反射对象，传入全部构造实参，完成对象建立
        if (!empty($dependencies) && $reflection->implementsInterface('yii\base\Configurable')) {
            // set $config as the last parameter (existing one will be overwritten)
            $dependencies[count($dependencies) - 1] = $config;
            return $reflection->newInstanceArgs($dependencies);
        } else {
            $object = $reflection->newInstanceArgs($dependencies);
            foreach ($config as $name => $value) {
                $object->$name = $value;
            }
            return $object;
        }
    }

若是你感兴趣能够看看getDependencies和resolveDependencies实现，前者缓存了每一个类的反射信息（反射很耗费性能），后者体现了Instance的用法：表明还没有实例化的class类对象，须要DI->get获取。

  protected function getDependencies($class)
    {
        if (isset($this->_reflections[$class])) {
            return [$this->_reflections[$class], $this->_dependencies[$class]];
        }

        $dependencies = [];
        $reflection = new ReflectionClass($class);

        $constructor = $reflection->getConstructor();
        if ($constructor !== null) {
            foreach ($constructor->getParameters() as $param) {
                if ($param->isDefaultValueAvailable()) {
                    $dependencies[] = $param->getDefaultValue();
                } else {
                    $c = $param->getClass();
                    $dependencies[] = Instance::of($c === null ? null : $c->getName());
                }
            }
        }

        $this->_reflections[$class] = $reflection;
        $this->_dependencies[$class] = $dependencies;

        return [$reflection, $dependencies];
    }
   protected function resolveDependencies($dependencies, $reflection = null)
    {
        foreach ($dependencies as $index => $dependency) {
            if ($dependency instanceof Instance) {
                if ($dependency->id !== null) {
                    $dependencies[$index] = $this->get($dependency->id);
                } elseif ($reflection !== null) {
                    $name = $reflection->getConstructor()->getParameters()[$index]->getName();
                    $class = $reflection->getName();
                    throw new InvalidConfigException("Missing required parameter \"$name\" when instantiating \"$class\".");
                }
            }
        }
        return $dependencies;
    }

最后

最后还想简单说一下yii2的ServiceLoader，它基于DI Container封装了一层，将组件component单例维护在ServiceLoader内，而component的生成则经过DI Container实现。

不过有意思的是，ServiceLoader这样的实现并没能充分的使用DI Container的构造依赖注入能力，仅仅是传入component的class完成对象建立，最后注入了几个config指定的属性而已，并无控制params的能力，这个能够看ServiceLoader中的set和get方法，然而这个设计基本要求了component的构造函数参数都应该能独立构造而不须要外部干预（干预是指DI->set进行类定义）。

除去ServiceLoader不谈，整个yii2.0框架也没找到能够经过配置文件自动化调用DI->set进行类定义的能力，硬编码属于走倒退的路，这基本上致使yii2.0对DI的应用能力停留在ServiceLoader层面，在递归解析依赖时也基本只能走无构造参数或者默认参数构造的路子。

正是在这种背景下，yii2.0的"依赖注入"也基本蜕化为ServiceLoader的get嵌套get，也就是相似"依赖查找"概念：在配置中分别写好A和B的component配置，而且配置A compoenent依赖B component，而后经过ServiceLoader获得A component，A类内部从配置中取出依赖的component（也就是B），最后经过ServiceLoader获得B component。