OO最基本的指导思想是针对接口编程,也就是说不管你的类的功能有多复杂,都应该提供一个对外的接口,其他类想访问这个类一定要通过接口访问,这样才能做到调用者只关心功能的外表,而不关心具体实现. 所以为了有能力切换接口的具体实现,类的对象应该间接创建.。
依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个类的实例,调用者)需要另一个角色(另一个类的实例,被调用者)的协助时,在传统的程序设计过程中,通常由调用者来创建被调用者的实例(即在调用者的类里面new 一个被调用者的实例)。如果创建被调用者的工作不再由调用者来完成,就称为控制反转;创建被调用者 实例的工作通常由DI容器来完成,然后注入调用者,因此也称为依赖注入。
不管是依赖注入,还是控制反转,都说明DI采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前,看如下这个问题在各种社会形态里如何解决:一个人(对象实例,调用者)需要一把斧子(对象实例,被调用者)。
(1)原始社会里,几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:C#程序里的调用者自己创建被调用者。
(2)进入工业社会,工厂出现。斧子不再由普通人完成,而在工厂里被生产出来,此时需要斧子的人(调用者)找到工厂,购买斧子,无须关心斧子的制造过程。对应C#程序的简单工厂的设计模式。
(3)进入“按需分配”社会,需要斧子的人不需要找到工厂,坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应DI的依赖注入。
第一种情况下,对象实例的调用者创建被调用的对象实例,必然要求被调用的类出现在调用者的代码里。无法实现二者之间的松耦合。
第二种情况下,调用者无须关心被调用者具体实现过程,只需要找到符合某种标准(接口)的实例,即可使用。此时调用的代码面向接口编程,可以让调用者和被调用者解耦,这也是工厂模式大量使用的原因。但调用者需要自己定位工厂,调用者与特定工厂耦合在一起。
第三种情况下,调用者无须自己定位工厂,程序运行到需要被调用者时,系统自动提供被调用者实例。事实上,调用者和被调用者都处于DI的管理下,二者之间的依赖关系由DI容器提供。
依赖注入理解
最新推荐文章于 2024-01-22 22:56:05 发布