谈谈php里的ioc控制反转,di依赖注入.doc

谈谈php里的IOC控制反转，DI依赖注入理论发现问题在深入细节之前，需要确保我们理解IOC控制反转和DI依赖注入是什么，能够解决什么问题，这些在维基百科中有非常清晰的说明。控制反转（InversionofControl，缩写为IoC）是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。依赖注入（DependencyInjection，简称DI）DI是IOC的一种实现，表现为在类A的实例创建过程中即创建了依赖的B对象，通过类型或名称来判断将不同的对象注入到不同的属性中。依赖查找（DependencyLookup，简称DL）DL是IOC的另外一种实现，在需要的时候通过调用框架提供的方法来获取对象，获取时需要提供相关的配置文件路径、key等信息来确定获取对象依赖注入与依赖查找是控制反转的2种实现方式，后者很少见，我们主要研究依赖注入。如果此前没有接触过这些概念，可能还是过于抽象不容易理解，但是下面这个场景你应该是见过的因为大多数应用程序都是由两个或是更多的类通过彼此的合作来实现业务逻辑，这使得每个对象都需要获取与其合作的对象（也就是它所依赖的对象）的引用。如果这个获取过程要靠自身实现，那么这将导致代码高度耦合并且难以维护和调试。也就是说ClassA中用到了ClassB的对象b，一般情况下，需要在A的代码中显式的new一个B的对象，这就导致如果A想将B替换为一个更优的实现版本B时，需要修改代码显式的new一个B对象。解决这个问题的传统做法一般是为B和B提取一个InterfaceOfB接口，然后让classA只依赖InterfaceOfB，最终由A类的调用方决定传入B还是B对象，修改调用方代码和修改类A代码对我们来说并没有本质的改变，那是否有更好的方式呢解决思路终于，懒惰的程序员对这种代码开发方式感到厌烦因为我们在代码里控制了B类对象的生成，从而导致代码耦合，即便A类依赖InterfaceOfB，还是要在程序某处写死newB或者newB这样的代码，怎么破解答案是将B类对象的生成交给一个独立的对象生成器来负责，那么A类只需要依赖这个对象生成器，而至于到底是生成B还是B对象，则是对象生成器内部的行为，这样就将A和B解耦开了，这就是所谓的控制反转，即将控制权交给了对象生成器。这么简单的将问题抛给对象生成器可不行，因为对象生成器还要面临newB还是newB的硬编码问题，因此必须赋予对象生成器一个超能力在对象生成器的配置文件中进行这样的描述{InterfaceOfBClassB}，表示InterfaceOfB接口应该实例化B对象。A类构造函数有一个InterfaceOfB的入参，例如function__constructInterfaceOfBobj。调用对象生成器（DI）获取A类对象，DI-getclassA。对象生成器会利用反射分析classA的构造函数，发现InterfaceOfB参数后根据此前配置文件描述，newB对象传入到A的构造函数，从而生成A对象。总结上述流程就是对象生成器通过反射机制分析A类的构造函数依赖，并根据配置中的关系生成依赖的对象实例传入给构造函数，最终完成A类对象的创建。上面的过程就是依赖注入主要实现方式了，对象生成器我们通常成为DIContainer，也就是依赖注入容器。需要注意的是B或者B的构造函数可以会依赖InterfaceOfC，因此整个依赖关系的分析是递归的。实践上面在谈DI依赖注入的时候，我们非常清楚的了解到DI会根据构造函数进行依赖分析，但是很容易忽视{InterfaceOfBClassB}这个信息的来源。如果DI不知道这个信息，那么在分析构造函数时是不可能知道接口InterfaceOfB应该对应什么对象的，这个信息在DI实现中一般是通过set方法主动设置到DI容器的依赖关系中的，当然这个信息的存储介质可以是配置文件或者硬编码传入。下面拿PHP的Yii2.0框架为例，看看它实现DI时的核心思路是什么，不会讲的太细，但上面提到的思路和概念都会有所体现。set设置类定义publicfunctionsetclass,definition[],arrayparams[]{this-_definitions[class]this-normalizeDefinitionclass,definition;this-_params[class]params;unsetthis-_singletons[class];returnthis;}这就是上面提到{InterfaceOfBClassB}的设置接口，比如这样用1container-setyii\mail\MailInterface,yii\swiftmailer\Mailer;意思就是如果遇到依赖MailInterface的，那么构造一个Mailer对象给它，params是用于传给Mailer__construct的构造参数，之前提过依赖分析是递归的，Mailter对象的构造也是DI负责的（不是简单的new出来），一旦你传了构造参数给Mailer，那么DI就不用反射分析Mailter的依赖了，直接传入params既可new一个Mailer出来。get生成类对象publicfunctiongetclass,params[],config[]{ifissetthis-_singletons[class]{//singleton//此前已经get过并且设置为单例，那么返回单例对象既可returnthis-_singletons[class];}elseifissetthis-_definitions[class]{//非单例需要生成新对象，但是此前没有set过类定义，//因此只能直接反射分析构造函数的依赖returnthis-buildclass,params,config;}//此前设置过的类定义，对类进行了更具体的定义，帮助我们更快的构造出对象definitionthis-_definitions[class];//类定义可以是一个函数，用于直接为DI生成对象ifis_callabledefinition,true{//将set设置的构造参数和本次传入的构造参数merge到一起//然后分析这些传入的构造参数是否为实参（比如int,string），这是因为yii允许//params是Instance对象，它代表了另外一个类定义（它内部指向了DI容器中某个definition//为了这种构造参数能够传入到当前的构造函数，需要递归调用di-get将其创建为实参。paramsthis-resolveDependenciesthis-mergeParamsclass,params;//这个就是函数式的分配对象，前提是构造参数需要确保都是实参objectcall_user_