IoC, DI, SL, DIP 依赖注入,控制反转

IoC, DI, SL, DIP 依赖注入,控制反转

化简为繁把人绕晕版:

首先得先说清几个名词 IoC, DI, SL, DIP。

IoC(控制反转)目前比较流行的两种方式 DI(依赖注入模式) 和 SL(服务器定位模式),DI 是遵循 DIP(依赖反转原则)的,SL 是 anti-pattern(反模式)的,不遵循 DIP。

因为注入的形式五花八门,为了代码复用性和扩展性出现了 IoC container 这么个东西,它是遵循各自 DI/SL 模式实现的容器,DI 容器会大量的运用反射机制来实现。

提到的 Laravel 中 Service Container 核心是 illuminate/container 是 DI/SL 的混合体。

其他就不多说了,关于这个概念,可以多读几遍下面这篇文章:

一看就懂版:

紧耦合有依赖的写法:

class Employee 
{  
    Address address;  

    Employee() 
    {  
        address = new Address();  
    }  
}  

松耦合没依赖的写法:

class Employee 
{  
    Address address;  

    Employee(Address address) 
    {  
        this.address=address;  
    }  
} 

依赖注入最大的两个好处是:

  • 代码松耦合, 易维护
  • 易测试

a依赖b,b为被依赖项。这时被依赖项b就是动态传进来的而不是在依赖项a中创建的。也就是说这里a和b虽然作为整体存在(即当外界调用a时需要b的参与),但是b的值却是从外界传进来的。这里可不可以理解为一个字“回”当我从外界传进来的是一个“木”字,这时“回”就变成了“困”,传进“人”就变成了“囚”,不知道可不可以这么理解。依赖注入这四个字,依赖:当需调用a对象时,需要b的参与,这时就是a依赖b。注入:是什么意思呢。是不是就是说当调用a对象时就把b对象最为参数传进去呢?

本来在函数中写死了,现在不介,代码挪出去,传个参数进来

这就是面向过程中,传参数。什么依赖注入,控制反转,唉 !

基本思想:

依赖倒置(Dependence Inversion Principle)

解耦和最重要的原则就是依赖倒置原则:

高层模块不应该依赖底层模块,他们都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

《资本论》中都曾阐释依赖倒转原则——在商品经济的萌芽时期,出现了物物交换。假设你要买一个IPhone,卖IPhone的老板让你拿一头猪跟他换,可是你并没有养猪,你只会编程。所以你找到一位养猪户,说给他做一个养猪的APP来换他一头猪,他说换猪可以,但是得用一条金项链来换——所以这里就出现了一连串的对象依赖,从而造成了严重的耦合灾难。解决这个问题的最好的办法就是,买卖双发都依赖于抽象——也就是货币——来进行交换,这样一来耦合度就大为降低了。

依赖倒置原则

指的是高级模块不应该依赖低级模块,而是依赖抽象。抽象不能依赖细节,细节要依赖抽象。比如类A内有类B对象,称为类A依赖类B,但是不应该这样做,而是选择类A去依赖抽象。例如垃圾收集器不管垃圾是什么类型,要是垃圾就行。