控制反转vs依赖注入

IoC容器执行的主要任务是: 实例化应用程序类。配置对象。

• < >强Setter注入
  • 基于setter的DI是通过在调用无参数构造函数或无参数静态工厂方法来实例化他们的bean之后调用用户bean上的setter方法来实现的。
  李< / ul > < / >
  • < >强构造函数注入
    • 基于构造函数的DI是通过调用带有许多参数的构造函数来实现的，每个参数代表一个合作者。使用它，我们可以验证注入的bean不是空的，并且快速失败(在编译时失败，而不是在运行时失败)，因此在启动应用程序本身时，我们得到NullPointerException: bean does not exist。构造函数注入是注入依赖项的最佳实践。
    李< / ul > < / >

我在Dzone.com上找到了最好的例子，这对理解IOC和DI之间的真正区别非常有帮助

" IoC是当你让别人为你创建对象时。"因此，与其在代码中写入“new”关键字(例如，MyCode c=new MyCode())，对象是由其他人创建的。这个“其他人”通常被称为IoC容器。这意味着我们将责任(控制)移交给容器以获得对象的实例，这称为控制反转。 这意味着你不用new操作符来创建对象，而是让容器来为你创建对象

   DI(Dependency Injection):  Way of injecting properties to an object is
called
Dependency injection.
We have three types of Dependency injection
1)  Constructor Injection
2)  Setter/Getter Injection
3)  Interface Injection
Spring will support only Constructor Injection and Setter/Getter Injection.

阅读全文和阅读全文

1) DI是Child->obj依赖于parent-obj。动词“视情况而定”很重要。 2) IOC是Child->obj在一个平台下执行。平台可以是学校，大学，舞蹈班。这里的perform是在任何平台提供程序下具有不同含义的活动 < p >实际的例子: ' < / p >

//DI
child.getSchool();
//IOC
child.perform()// is a stub implemented by dance-school
child.flourish()// is a stub implemented by dance-school/school/

｀

ab

控制反转是软件体系结构的一种通用设计原则，它有助于创建易于维护的可重用的模块化软件框架。

它是一种设计原则，其中控制流是从通用编写的库或可重用代码中“接收”的。

为了更好地理解它，让我们看看我们在早期是如何编写代码的。在过程式/传统语言中，业务逻辑通常控制应用程序的流程，并“调用”通用或可重用的代码/函数。例如，在一个简单的控制台应用程序中，我的控制流是由我的程序的指令控制的，这可能包括对一些一般可重用函数的调用。

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

与IoC相反，框架是“调用”业务逻辑的可重用代码。

例如，在基于windows的系统中，已经有一个框架可以创建按钮、菜单、窗口和对话框等UI元素。当我编写应用程序的业务逻辑时，将是框架的事件调用我的业务逻辑代码(当事件触发时)，而不是相反。

尽管框架的代码不知道我的业务逻辑，但它仍然知道如何调用我的代码。这是通过使用事件/委托、回调等实现的。这里的流量控制是“反向的”。

因此，控制流不是依赖于静态绑定的对象，而是依赖于整个对象图和不同对象之间的关系。

依赖注入是一种实现IoC原则来解决对象依赖关系的设计模式。

简单地说，当您尝试编写代码时，您将创建和使用不同的类。一个类(类A)可以使用其他类(类B和/或D)，因此，类B和类D是类A的依赖关系。

一个简单的类比是类Car。汽车可能依赖于其他类别，如引擎、轮胎等。

依赖注入建议不是依赖类(这里是类Car)创建它的依赖项(类Engine和类Tyre)，而是应该用依赖项的具体实例注入类。

让我们用一个更实际的例子来理解。假设您正在编写自己的TextEditor。除此之外，您还可以使用拼写检查器，为用户提供检查文本中的错别字的工具。这样一个代码的简单实现可以是:

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;


}


}

乍一看，一切都很美好。用户将编写一些文本。开发人员将捕获文本并调用CheckSpellings函数，并找到他将显示给用户的拼写错误列表。

一切似乎都很好，直到有一天，一个用户开始在编辑器中编写法语。

为了提供对更多语言的支持，我们需要更多的拼写检查器。可能是法语、德语、西班牙语等。

在这里，我们创建了一个紧密耦合的代码，其中“English”SpellChecker与我们的TextEditor类紧密耦合，这意味着我们的TextEditor类依赖于EnglishSpellChecker，换句话说，English spellcheker是TextEditor的依赖项。我们需要消除这种依赖关系。此外，我们的文本编辑器需要一种方法来保存任何拼写检查器的具体引用，基于开发人员在运行时的自由裁量权。

因此，正如我们在DI的介绍中看到的，它建议类应该注入它的依赖项。因此，将所有依赖项注入到被调用的类/代码应该是调用代码的责任。所以我们可以把代码重构为

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.


}


}

在我们的例子中，TextEditor类应该接收ISpellChecker类型的具体实例。

现在，可以在构造函数、公共属性或方法中注入依赖项。

让我们尝试使用构造函数DI来改变我们的类。修改后的TextEditor类看起来像这样:

Class TextEditor


{


ISpellChecker objSpellChecker;


string Text;






public void TextEditor(ISpellChecker objSC)


{


objSpellChecker = objSC;


}






public ArrayList <typos> CheckSpellings()


{


return objSpellChecker.CheckSpelling();


}


}

因此，在创建文本编辑器时，调用代码可以将适当的拼写检查器类型注入到TextEditor的实例中。

您可以阅读完整的文章在这里

关于这个问题，我想说维基已经提供了详细易懂的解释。我引用这里最重要的。

实现IoC

在面向对象编程中，有几种基本的技术来实现 实现控制反转。这些都是:< / p >

1. 使用服务定位器模式 构造函数注入参数注入Setter注入 接口注入;李< / >
2. 使用上下文化查找;
3. 采用模板法设计模式;
4. 使用策略设计模式

至于依赖注入

依赖注入是一种技术，其中一个对象(或静态的 方法)提供了另一个对象的依赖关系。依赖关系是 可以使用的对象(服务)。注入是传递 对使用它的依赖对象(客户端)的依赖

IoC概念最初出现在过程式编程时代。因此，从历史背景来看，IoC谈到了所有权控制的反转——流，即谁拥有以所需顺序调用函数的责任——无论是函数本身还是应该将它反转到一些外部实体。

然而，一旦OOP出现，人们开始在OOP上下文中讨论IoC，其中应用程序除了控制流之外，还关注对象的创建及其关系。这样的应用程序想要反对象创建的所有权(而不是控制流)，需要一个容器来负责对象创建，对象生命周期&注入应用程序对象的依赖关系，从而避免应用程序对象创建其他具体对象。

从这个意义上讲，DI与io# EYZ0不同，因为它不是关于控制流的，而是a kind of Io*，即对象创建的所有权倒置。

我解释DI和IoC的方式有什么错?< / >

我认为这个想法可以清楚地展示，而不需要进入面向对象的杂草，这似乎混淆了这个想法。

// dependency injection
function doSomething(dependency) {
// do something with your dependency
}


// in contrast to creating your dependencies yourself
function doSomething() {
dependency = getDependencySomehow()
}


// inversion of control
application = makeApp(authenticate, handleRequest, sendResponse)
application.run(getRequest())


// in contrast to direct control or a "library" style
application = makeApp()
request = application.getRequest()


if (application.authenticate(request.creds)) {
response = application.handleRequest(request)
application.sendResponse(response)
}

如果您倾斜头部并眯起眼睛，就会发现DI是IoC的一种特殊实现，具有特定的关注点。您不是将模型和行为注入到应用程序框架或更高阶操作中，而是将变量注入到函数或对象中。

Ioc - dip - di

1. 控制反转(IOC)
2. 依赖倒置原理(DIP)
3. 依赖注入(DI)

1- 国际奥委会:描述某些软件架构设计的一个方面的抽象原理，其中系统的控制流与过程式编程相比是反向的。

2-浸:是面向对象编程(OOP)原理(D of SOLID)。

EYZ0:是一种软件设计模式，它实现了控制反转，并允许程序设计遵循依赖反转原则。

# EYZ0 < / p >

与其直接对比DI和IoC，不如从头开始:每个重要的应用程序都依赖于其他代码段。

所以我写一个类，MyClass，我需要调用一个方法YourService…我需要以某种方式获取YourService的实例。最简单、最直接的方法是自己实例化它。

# EYZ0

直接实例化是获取依赖项的传统(过程性)方法。但是它有许多缺点，包括MyClass到YourServiceImpl的紧密耦合，这使得我的代码难以更改和测试。MyClass并不关心YourService的实现是什么样子的，所以MyClass不想负责实例化它。

我更希望反的责任从MyClass到MyClass之外。最简单的方法是将实例化调用(new YourServiceImpl();)移动到其他类中。我可以将这个类命名为Locator，或者Factory，或者其他任何名称;但重点是MyClass不再负责YourServiceImpl。我颠倒了依赖关系。太好了。

问题是，MyClass仍然负责调用定位器/工厂/等等。因为我反转依赖关系所做的全部工作就是插入一个中间人，所以现在我耦合到中间人(即使我没有耦合到中间人给我的具体对象)。

我并不真正关心依赖项来自何处，因此我宁愿不负责进行检索依赖项的调用。仅仅反转依赖本身是不够的。我想反转整个过程的控制。

我需要的是插入MyClass的一段完全独立的代码(称其为框架)。然后我剩下的唯一责任就是声明我对YourService的依赖。框架可以负责确定在何处、何时以及如何获取实例，并向MyClass提供它需要的东西。最好的部分是，MyClass不需要知道框架。框架可以控制这个依赖连接过程。现在我已经反转了控件(在反转依赖项之上)。

将MyClass连接到框架中有不同的方法。注入就是这样一种机制，通过这种机制，我只需声明一个希望框架提供的字段或参数，通常是在框架实例化MyClass时。

我认为所有这些概念之间的关系层次比这个线程中的其他图表所显示的要稍微复杂一些;但其基本思想是，这是一种等级关系。我认为这与在野外浸泡是同步的。

DIP vs DI vs IoC

[依赖倒置原则]是SOLID<一口>[对]< /一口>的一部分，它要求你使用抽象而不是实现

在这种情况下，外部对象负责内部的逻辑。哪一种方法使您拥有更动态和更可测试的方法

class A {
B b


//injecting B via constructor
init(b: B) {
self.b = b
}
}

控制反转(IoC)非常高级的定义，更多的是关于控制流。最好的例子是Inversion of Control(IoC) Container or Framework<一口>[对]< /一口>。例如，GUI是一个框架，你没有一个控制，你能做的一切只是实现框架的接口，当一些动作发生在框架中时，它会被调用。这样，控制权就从应用程序转移到了正在使用的框架中

Dip + di

class A {
IB ib


init(ib: IB) {
self.ib = ib
}
}

你也可以使用:

• [工厂方法] .
• [服务定位器] .
• < a href = " https://stackoverflow.com/a/66808163/4770877 " > [ioc容器(框架)]< / >

更复杂的例子

依赖规则多层/模块结构

伪代码:

interface InterfaceInputPort {
func input()
}


interface InterfaceOutputPort {
func output()
}


class A: InterfaceOutputPort {


let inputPort = B(outputPort: self)


func output() {
print("output")
}
}


class B: InterfaceInputPort {
let outputPort: InterfaceOutputPort


init(outputPort: InterfaceOutputPort) {
self.outputPort = outputPort
}


func input() {
print("input")
}
}