社区首页 >专栏 >IoC与DI的不同和它们分别的作用

IoC与DI的不同和它们分别的作用

原创

可大可小

修改于 2021-03-11 09:54:37

73200

代码可运行

文章被收录于专栏：用户1092337的专栏用户1092337的专栏

运行总次数：0

代码可运行

大多数人可能搞混这两个术语。可能是由于在Spring中大量使用了这些概念而导致的混乱，其中使用了Inversion of Control来启用依赖注入。

这篇文章旨在以一种简单的方式来解释这两种说法。

控制反转

基本概念

IoC的非正式定义：“ IoC是当你让其他人为你创建对象时。” 因此，该对象不是由你的代码编写“ new MyObject”，而是由其他人创建的。此 “其他人” 通常称为IoC容器。

这个简单的解释说明了一些非常重要的想法：

之所以称为IoC，是因为对对象的控制被反转了，不是程序员，而是其他人控制对象。
IoC是相对的，因为它只适用于应用程序的某些对象。所以有些对象可能有IoC，而有些对象则由程序员直接控制。

除了Spring之外，还有其他IoC示例，例如 Java Servlet 和 Akka Actors。

细节

让我们进一步研究IoC的定义。IoC不仅仅是对象创建：Spring Context或Servlet容器不仅可以创建对象，而且可以管理对象的整个 生命周期。这包括创建对象，销毁它们以及在对象生命周期的不同阶段调用对象的某些方法。这些方法通常称为回调。再次注意术语：容器调用的方法是回调，而不是程序员对自己的代码进行的 直接调用。

前面提到的所有IoC容器都实现某种生命周期： Spring Bean生命周期， Servlet生命周期和 Akka Actor生命周期。

要考虑的另一件事是，尽管程序员放弃了对对象的控制，但是他们仍然需要定义 IoC容器用于创建所述对象的模板。

例如，在Spring中，类使用@Service 或 @Component进行注释（还有许多其他注解），以表示Spring容器将管理这些类的实例（也可以使用XML配置代替注释）。Spring管理的对象称为Bean。

在Servlet应用程序中，任何实现Servlet 接口的类都将由Servlet容器管理。

在Akka应用程序中，IoC容器称为 ActorSystem ，托管对象是扩展特征Actor的类的实例，并通过称为Props的配置对象创建。

这是到目前为止讨论的想法的简要摘要：

IoC容器控制和管理某些对象的生命周期：创建，销毁和回调调用。
程序员必须确定要由IoC容器管理其实例的类。有几种方法可以执行此操作：使用批注，通过扩展某些特定的类，使用外部配置。
程序员可以在一定程度上影响IoC容器管理对象的方式。通常，这是通过覆盖对象回调的默认行为来实现的。

Ioc容器	管理对象名称	管理对象定义
Spring Container	Bean	Classes defined with annotations/XML configuration
Servlet Container	Servlet	Classes implementing interface Servlet
Actor System	Actor	Classes extending trait Actor

到目前为止，我们已经解释了IoC，还没解释依赖注入(DI)。

依赖注入

依赖注入已成为现代软件工程的基石之一，因为它是允许进行适当测试的基础。简而言之，拥有DI与拥有硬编码的依赖关系相反。

//硬编码
public class MyClass { 
    private MyDependency myDependency = new MyDependency(); 
}

//依赖注入
public class MyClass { 
    private MyDependency myDependency;

    public MyClass(MyDependency myDependency){
        this.myDependency = myDependency;
    }
}

依赖项可以通过几种方式注入，例如构造函数中的参数或通过“ set”方法。

与DI一样重要的是，它的使用也有一个缺点，即：依赖项的管理很不方便。举个个例子：MyClass1依赖于MyClass2，而MyClass3则取决于：

public class MyClass3 {
    public void doSomething(){}
}

//MyClass2 依赖 MyClass3
public class MyClass2 {
    private MyClass3 myClass3;

    public MyClass2(MyClass3 myClass3){
        this.myClass3 = myClass3;
    }

    public void doSomething(){
        myClass3.doSomething();
    }
}

//MyClass1 依赖on MyClass2
public class MyClass1 {
    private MyClass2 myClass2;

    public MyClass1(MyClass2 myClass2){
        this.myClass2 = myClass2;
    }

    public void doSomething(){
        myClass2.doSomething();
    }
}

public class Main {

    public static void main(String[] args) {

        //All dependencies need to be managed by the develope
        MyClass3 myClass3 = new MyClass3();
        MyClass2 myClass2 = new MyClass2(myClass3);
        MyClass1 myClass1 = new MyClass1(myClass2);

        myClass1.doSomething();
    }
}

现在，让我们假设更进一步，MyClass2需要一个新的依赖项：MyClass4。我们需要进行修改来解决这个新的依赖关系：

public class MyClass2 {
    private MyClass3 myClass3;
    private MyClass4 myClass4;

    public MyClass2(MyClass3 myClass3, MyClass4 myClass4){
        this.myClass3 = myClass3;
        this.myClass4 = myClass4;
    }

    public void doSomething(){
        myClass3.doSomething();
        myClass4.doSomething();
    }
}

public class Main {

    public static void main(String[] args) {

        MyClass4 myClass4 = new MyClass4();
        MyClass3 myClass3 = new MyClass3();
        MyClass2 myClass2 = new MyClass2(myClass3, myClass4);
        MyClass1 myClass1 = new MyClass1(myClass2);

        myClass1.doSomething();
    }
}

尽管这个例子中描述的情况还不错，但是现实应用程序可能在整个代码库中分散了几百个依赖项，就像上面的示例一样，它们的创建和管理将需要集中化。

控制反转和依赖注入一起发挥作用

我们刚刚讨论了在应用程序中管理数百个依赖关系的问题，其中可能包含非常复杂的依赖关系图。

因此，这就是IoC的主要作用。使用IoC，依赖项由容器管理，从而减轻了程序员的负担。

使用@Autowired之类的注释，要求容器在需要的地方注入依赖项，并且程序员不需要自己创建/管理这些依赖项。

public class MyClass1 {

    @Autowired
    private MyClass2 myClass2;

    public void doSomething(){
        myClass2.doSomething();
    }
}

public class MyClass2 {

    @Autowired
    private MyClass3 myClass3;
    @Autowired
    private MyClass4 myClass4;

    public void doSomething(){
        myClass3.doSomething();
        myClass4.doSomething();
    }
}