blocks|key|428398|text|Spring:+Spring是Java平台的“控制反转”容器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|428399|控制反转(IoC)：控制反转(IoC)是一种面向对象的编程实践，其中对象耦合在运行时由“汇编器”对象绑定，并且通常在编译时使用静态分析不可见。|428400|依赖注入(DI)：“依赖注入是一种软件设计模式，它允许移除硬编码的依赖，并使得在运行时或编译时更改它们成为可能。”-wiki。|428401|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Spring: Spring is “Inversion of Control” container for the Java Platform.

Inversion of Control (IoC): Inversion of Control (IoC) is an object-oriented programing practice whereby the object coupling is bounded at runtime by an "assembler" object and are typically not knowable at compile time using static analysis.

Dependency Injection (DI): "Dependency injection is a software design pattern that allows the removal of hard-coded dependencies and makes it possible to change them, whether at run-time or compile-time." -wiki.

blocks|key|642939|text|在Employee中获取address实例的传统方法是创建一个新的Address实例，class.Spring会创建所有依赖于我们的对象，因此我们不需要担心object。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|642940|所以在Spring中，我们仅仅依赖于spring容器，它为我们提供了依赖对象。|642941|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The traditional way of getting address instance in Employee would be by creating a new instance of Address class.Spring creates all dependent object ton us hence we need not to worry about object. 

So in Spring we just depend on the spring container which provide us with the dependency object.

blocks|key|428491|text|在Spring中，对象是松散耦合的，也就是说，每个类都是相互独立的，所以所有的东西都可以单独测试。但是当使用这些类时，一个类可能依赖于需要首先实例化的其他类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|428492|因此，我们告诉spring类A依赖于类B。因此，当为类A创建bean(类似类)时，它先实例化类B，然后使用setter或构造器DI方法将其注入到类A中。也就是说，我们在运行时告诉spring依赖关系。这是DI。|428493|由于我们将创建对象(Bean)、维护它们及其聚合的责任分配给Spring，而不是硬编码它，我们称之为控制反转(IOC)。|428494|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

In Spring Objects are loosely coupled i.e., each class is independent of each other so that everything can be tested individually. But when using those classes, a class may be dependent on other classes which need to be instantiated first. 

So, we tell spring that class A is dependent on class B. So, when creating bean(like class) for class A, it instantiates class B prior to that of class A and injects that in class A using setter or constructor DI methods. I.e., we are telling spring the dependency at run-time. This is DI.

As, we are assigning the responsibility of creating objects(beans), maintaining them and their aggregations to Spring instead of hard-coding it, we call it Inversion Of Control(IOC).

blocks|key|643064|text|控制反转是软件体系结构的通用设计原则，有助于创建易于维护的可重用、模块化软件框架。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|643065|它是一种设计原则，其中的控制流是从泛型编写的库或可重用代码中“接收”的。|643066|为了更好地理解它，让我们看看我们在早期的编码中是如何编码的。在过程化/传统语言中，业务逻辑通常控制应用程序的流程，并“调用”通用或可重用的代码/函数。例如，在一个简单的控制台应用程序中，我的控制流由我的程序指令控制，这些指令可能包括对一些通用的可重用函数的调用。|643067|print+("Please+enter+your+name:");
scan+(&name);
print+("Please+enter+your+DOB:");
scan+(&dob);

//More+print+and+scan+statements
<Do+Something+Interesting>

//Call+a+Library+function+to+find+the+age+(common+code)
print+Age|code-block|syntax|javascript|643068|相比之下，使用IoC时，框架是“调用”业务逻辑的可重用代码。|643069|例如，在基于windows的系统中，已经有一个框架可用于创建按钮、菜单、窗口和对话框等UI元素。当我编写应用程序的业务逻辑时，框架的事件将调用我的业务逻辑代码(当事件被激发时)，而不是相反。|643070|尽管框架的代码不知道我的业务逻辑，但它仍然知道如何调用我的代码。这是使用事件/委托，回调等来实现的。在这里，流的控制是“反向的”。|643071|因此，不是依赖于静态绑定的对象来控制流，而是依赖于整个对象图和不同对象之间的关系。|643072|依赖注入是一种实现IoC原则的设计模式，用于解决对象之间的依赖关系。|643073|简而言之，当您尝试编写代码时，您将创建和使用不同的类。一个类(A类)可以使用其他类(B类和/或D类)。因此，B类和D类是A类的依赖项。|643074|一个简单的类比就是一辆普通汽车。汽车可能依赖于其他类别，如发动机，轮胎和更多。|643075|依赖注入建议，而不是依赖类(这里是class+Car+)创建它的依赖(Class+Engine和class+Tyre)，class应该注入依赖的具体实例。|643076|让我们用一个更实际的例子来理解。假设您正在编写自己的TextEditor。除了其他功能之外，您还可以使用拼写检查器为用户提供检查其文本中的拼写错误的工具。这类代码的简单实现可以是：|643077|Class+TextEditor
{

++++//Lot+of+rocket+science+to+create+the+Editor+goes+here

++++EnglishSpellChecker+objSpellCheck;
++++String+text;

++++public+void+TextEditor()

++++{+++

++++++++objSpellCheck+=+new+EnglishSpellChecker();

++++}

++++public+ArrayList+<typos>+CheckSpellings()
++++{

++++++++//return+Typos;

++++}

}|643078|乍一看，一切看起来都很美好。用户将写一些文本。开发人员将捕获文本并调用CheckSpellings函数，并将找到他将显示给用户的输入列表。|643079|一切似乎都很顺利，直到有一天，一个用户开始在编辑器中写法语。|643080|为了提供对更多语言的支持，我们需要更多的SpellCheckers。可能是法语、德语、西班牙语等等。|643081|在这里，我们创建了一个紧密耦合的代码，其中"English"SpellChecker与我们的TextEditor类紧密耦合，这意味着我们的TextEditor类依赖于EnglishSpellChecker，换句话说，EnglishSpellCheker是TextEditor的依赖。我们需要移除这种依赖。此外，我们的文本编辑器需要一种方法来保存任何拼写检查器的具体引用，这是基于开发人员在运行时的判断。|643082|因此，正如我们在DI的介绍中看到的，它建议类应该被注入它的依赖项。因此，向被调用的类/代码注入所有依赖项应该是调用代码的责任。因此我们可以将我们的代码重构为|643083|interface+ISpellChecker
{

++++Arraylist<typos>+CheckSpelling(string+Text);

}

Class+EnglishSpellChecker+:+ISpellChecker

{

++++public+override+Arraylist<typos>+CheckSpelling(string+Text)

++++{

++++++++//All+Magic+goes+here.

++++}

}



Class+FrenchSpellChecker+:+ISpellChecker

{

++++public+override+Arraylist<typos>+CheckSpelling(string+Text)

++++{

++++++++//All+Magic+goes+here.

++++}

}|643084|在我们的示例中，TextEditor类应该接收ISpellChecker类型的具体实例。|643085|现在，可以在构造函数、公共属性或方法中注入依赖项。|643086|让我们尝试使用构造器DI来更改我们的类。更改后的TextEditor类将如下所示：|643087|Class+TextEditor

{

++++ISpellChecker+objSpellChecker;

++++string+Text;



++++public+void+TextEditor(ISpellChecker+objSC)

++++{

++++++++objSpellChecker+=+objSC;

++++}



++++public+ArrayList+<typos>+CheckSpellings()

++++{

++++++++return+objSpellChecker.CheckSpelling();

++++}

}|643088|这样，在创建文本编辑器时，调用代码就可以向TextEditor的实例注入适当的SpellChecker类型。|643089|您可以阅读完整的文章here|offset|length|643090|entityMap|0|LINK|mutability|MUTABLE|url|https://www.linkedin.com/pulse/inversion-control-ioc-dependency-injection-di-amritpal-singh/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|A|4|0|0^^$0|@$1|2|3|4|5|6|7|22|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|23|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|24|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|25|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|26|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|27|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|28|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|29|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|2A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2B|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2C|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|2D|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2E|8|@]|9|@]|A|$]]|$1|12|3|13|5|H|7|2F|8|@]|9|@]|A|$I|J]]|$1|14|3|15|5|6|7|2G|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2H|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|H|7|2L|8|@]|9|@]|A|$I|J]]|$1|1G|3|1H|5|6|7|2M|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|2O|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|H|7|2P|8|@]|9|@]|A|$I|J]]|$1|1O|3|1P|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|6|7|2R|8|@]|9|@$1S|2S|1T|2T|1|2U]]|A|$]]|$1|1U|3|-4|5|6|7|2V|8|@]|9|@]|A|$]]]|1V|$1W|$5|1X|1Y|1Z|A|$20|21]]]]

Inversion of Control is a generic design principle of software architecture that assists in creating reusable, modular software frameworks that are easy to maintain.

It is a design principle in which the Flow of Control is "received" from the generic-written library or reusable code.

To understand it better, lets see how we used to code in our earlier days of coding. In procedural/traditional languages, the business logic generally controls the flow of the application and "Calls" the generic or reusable code/functions. For example, in a simple Console application, my flow of control is controlled by my program's instructions, that may include the calls to some general reusable functions.

<pre><code>print ("Please enter your name:");
scan (&amp;name);
print ("Please enter your DOB:");
scan (&amp;dob);

//More print and scan statements
&lt;Do Something Interesting&gt;

//Call a Library function to find the age (common code)
print Age
</code></pre>

In Contrast, with IoC, the Frameworks are the reusable code that "Calls" the business logic.

For example, in a windows based system, a framework will already be available to create UI elements like buttons, menus, windows and dialog boxes. When I write the business logic of my application, it would be framework's events that will call my business logic code (when an event is fired) and NOT the opposite.

Although, the framework's code is not aware of my business logic, it will still know how to call my code. This is achieved using events/delegates, callbacks etc. Here the Control of flow is "Inverted".

So, instead of depending the flow of control on statically bound objects, the flow depends upon the overall object graph and the relations between different objects.

Dependency Injection is a design pattern that implements IoC principle for resolving dependencies of objects.

In simpler words, when you are trying to write code, you will be creating and using different classes. One class (Class A) may use other classes (Class B and/or D). So, Class B and D are dependencies of class A.

A simple analogy will be a class Car. A car might depend on other classes like Engine, Tyres and more.

Dependency Injection suggests that instead of the Dependent classes (Class Car here) creating its dependencies (Class Engine and class Tyre), class should be injected with the concrete instance of the dependency.

Lets understand with a more practical example. Consider that you are writing your own TextEditor. Among other things, you can have a spellchecker that provides the user with a facility to check the typos in his text. A simple implementation of such a code can be:

<pre><code>Class TextEditor
{

 //Lot of rocket science to create the Editor goes here

 EnglishSpellChecker objSpellCheck;
 String text;

 public void TextEditor()

 { 

 objSpellCheck = new EnglishSpellChecker();

 }

 public ArrayList &lt;typos&gt; CheckSpellings()
 {

 //return Typos;

 }

}
</code></pre>

At first sight, all looks rosy. The user will write some text. The developer will capture the text and call the CheckSpellings function and will find a list of Typos that he will show to the User.

Everything seems to work great until one fine day when one user starts writing French in the Editor.

To provide the support for more languages, we need to have more SpellCheckers. Probably French, German, Spanish etc.

Here, we have created a tightly-coupled code with "English"SpellChecker being tightly coupled with our TextEditor class, which means our TextEditor class is dependent on the EnglishSpellChecker or in other words EnglishSpellCheker is the dependency for TextEditor. We need to remove this dependency. Further, Our Text Editor needs a way to hold the concrete reference of any Spell Checker based on developer's discretion at run time.

So, as we saw in the introduction of DI, it suggests that the class should be injected with its dependencies. So, it should be the calling code's responsibility to inject all the dependencies to the called class/code. So we can restructure our code as

<pre><code>interface ISpellChecker
{

 Arraylist&lt;typos&gt; CheckSpelling(string Text);

}

Class EnglishSpellChecker : ISpellChecker

{

 public override Arraylist&lt;typos&gt; CheckSpelling(string Text)

 {

 //All Magic goes here.

 }

}



Class FrenchSpellChecker : ISpellChecker

{

 public override Arraylist&lt;typos&gt; CheckSpelling(string Text)

 {

 //All Magic goes here.

 }

}
</code></pre>

In our example, the TextEditor class should receive the concrete instance of ISpellChecker type.

Now, the dependency can be injected in Constructor, a Public Property or a method.

Lets try to change our class using Constructor DI. The changed TextEditor class will look something like:

<pre><code>Class TextEditor

{

 ISpellChecker objSpellChecker;

 string Text;



 public void TextEditor(ISpellChecker objSC)

 {

 objSpellChecker = objSC;

 }



 public ArrayList &lt;typos&gt; CheckSpellings()

 {

 return objSpellChecker.CheckSpelling();

 }

}
</code></pre>

So that the calling code, while creating the text editor can inject the appropriate SpellChecker Type to the instance of the TextEditor.

You can read the complete article <a href="https://www.linkedin.com/pulse/inversion-control-ioc-dependency-injection-di-amritpal-singh/" rel="noreferrer">here</a>

blocks|key|428644|text|IOC是一种让其他人为您创建对象的技术。在spring的情况下，另一个人是IOC容器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|428645|依赖注入是一种技术，其中一个对象提供另一个对象的依赖关系。|428646|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

IOC is technique where you let someone else to create the object for you.
And the someone else in case of spring is IOC container.

Dependency Injection is a technique where one object supplies the dependency of another object.

blocks|key|428726|text|IOC代表控制反转，是一个更高级别的概念，它规定我们将对象创建的控制从调用者反转到被调用者。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|428727|在没有反向控制的情况下，您负责对象的创建。在控制反转场景中，框架负责创建类的实例。|428728|依赖注入是我们可以实现控制反转的方法。为了让我们将控制权留给框架或作业，我们声明依赖项，IOC容器在我们的类中注入这些依赖项(即框架为我们创建一个实例并将其提供给我们的类)。|428729|那么这样做的好处是什么呢？|428730|首先，类及其生命周期将由Spring管理。Spring完全控制着从创建到销毁的整个过程。|428731|其次，您将减少类之间的耦合。一个类与另一个类的实现不是紧密耦合的。如果实现发生了变化，或者如果您想要更改注入接口的实现，您可以轻松地完成此操作，而无需手动更改代码库中的所有实例。|428732|第三，类之间的内聚力增强了。高内聚意味着将相互关联的类保持在一起。因为我们在其他类中注入接口，所以很清楚调用类需要哪些类才能运行。|428733|第四，增加了可测试性。因为我们在构造函数中使用接口，所以我们可以很容易地将实现替换为模拟实现|428734|第五，使用JDK动态代理来代理对象。JDK动态代理需要使用接口，这是真的，因为我们正在注入这些接口。然后，这个代理可以用于Spring+AOP、事务处理、Spring数据、Spring安全等等|428735|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

IOC stands for inversion of control and is a higher level concept that states that we invert the control of the creation of objects from the caller to the callee.
Without inversion of control, you are in charge of the creation of objects. In an inversion of control scenario a framework is in charge to create instances of a class.
Dependency injection is the method through which we can achieve inversion of control. In order for us to leave the control up to the framework or job we declare dependencies and the IOC container injects those dependencies in our class (i.e. the framework creates an instance for us and provides that to our class).
Now what are the advantages of this?
First of all the classes and their lifecycle will be managed by Spring. Spring completely manages the process from creation to destruction.
Secondly, you will get reduced coupling between classes. A class is not tightly coupled with an implementation of another class. If an implementation changes, or if you want to change the implementation of the injected interface you can do so easily without needing to change all the instances in your code base by hand.
Third, there is an increased cohesion between classes. High cohesion means keeping classes that are associated with one another together. Because we are injecting interfaces in other classes it is clear which classes are necessary for the calling class to operate.
Fourth, there is increased testability. Because we are using interfaces in the constructor we can easily swap out the implementation with a mock implementation
fifth, the use of JDK dynamic proxy to proxy objects. the JDK dynamic proxy requires interfaces to be used which is true, because we are injecting these interfaces. This proxy can then be used for Spring AOP, transaction handling, Spring data, Spring security and more

"Dependency Injection" and "Inversion of Control" are often mentioned as the primary advantages of using the Spring framework for developing Web frameworks

Could anyone explain what it is in very simple terms with an example if possible?

What is Dependency Injection and Inversion of Control in Spring Framework?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

“依赖注入”和“控制反转”经常被认为是使用Spring框架开发Web框架的主要优点如果可能的话，有没有人能用一个简单的例子来解释一下它是什么？

问什么是Spring框架中的依赖注入和控制反转？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是Spring框架中的依赖注入和控制反转？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是Spring框架中的依赖注入和控制反转？
EN