什么是控制反转？

最新推荐文章于 2020-05-22 18:59:32 发布

asdfgh0077

最新推荐文章于 2020-05-22 18:59:32 发布

阅读量2.3k

点赞数 1

文章标签： oop design-patterns inversion-of-control

原文链接：https://stackoom.com/question/nK/什么是控制反转

版权

第一次遇到控制反转（或IoC）时，可能会很混乱。

它是什么？
它解决什么问题？
什么时候合适，什么时候不合适？

#1楼

可以说我们在某家酒店开会。

很多人，很多水，很多塑料杯。

当有人要喝酒时，她将杯子装满，喝水然后将杯子扔在地板上。

几个小时后，我们的地板覆盖了塑料杯和水。

让控制反转。

在同一地点的同一次会议，但是我们有一个带有一个玻璃杯的服务员（而不是塑料杯）（Singleton）

她一直都在为客人喝酒

当有人要喝酒时，她从服务员玻璃杯里喝水，然后将其还给服务员。

抛开卫生的问题，最后一种饮酒过程控制更为有效和经济。

这正是Spring（另一个IoC容器，例如Guice）所做的。 Spring IoC容器始终不让应用程序使用新关键字（以塑料杯）创建所需的内容，而是始终为应用程序提供所需对象（玻璃杯）的相同实例（单个）。

想想自己是这种会议的组织者。您需要向酒店管理部门传达以下信息：

会议成员将需要杯水，而不是小菜一碟。

例：-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

有用的链接：

#2楼

在这里可以找到一个非常简单的书面说明

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

它说 -

“任何非平凡的应用程序都是由两个或多个相互协作以执行某些业务逻辑的类组成。传统上，每个对象都负责获取对其协作对象的依赖关系（依赖关系）。当应用DI时，对象在创建时由一些外部实体赋予它们的依赖关系，这些外部实体协调系统中的每个对象。换句话说，依赖关系被注入到对象中。”

#3楼

控制反转（或IoC）是关于获得自由 （您结婚，失去自由并受到控制。离婚，您刚刚实现了控制反转。这就是我们所说的“分离”。好的计算机系统不鼓励某些亲密关系。） 更大的灵活性 （办公室中的厨房仅提供干净的自来水，这是您喝酒时的唯一选择。老板通过安装新的咖啡机实施了控制反转。选择自来水或咖啡的灵活性。）并且依赖性较低 （您的伴侣有工作，您没有工作，您在经济上依赖伴侣，因此您受到控制。找到工作，就实施了Inversion of控制。良好的计算机系统鼓励相互依赖。）

使用台式计算机时，您已成为从属（或受控）。您必须坐在屏幕前看一下。使用键盘键入并使用鼠标进行导航。一个写得不好的软件甚至可以奴役您。如果用笔记本电脑代替台式机，则控制会有所倒置。您可以轻松地随身携带它。因此，现在您可以控制计算机的位置，而不是由计算机控制它。

通过实施控制反转，软件/对象使用者可以获得比软件/对象更多的控件/选项，而不是被控制或具有更少的选项。

考虑到以上想法。我们仍然错过了IoC的关键部分。在IoC场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不会被您自己调用。现在，让我们解释一下为什么这种方式对Web应用程序更好。

假设您的代码是一群工人。他们需要制造一辆汽车。这些工人需要一个地方和工具（一个软件框架）来制造汽车。 传统的软件框架就像带有许多工具的车库。因此，工人需要自己制定计划并使用工具来制造汽车。造车不是一件容易的事，对工人来说，正确地计划和合作确实非常困难。 现代化的软件框架将像拥有所有设施和经理的现代化汽车工厂一样。工人不必制定任何计划，经理（框架的一部分，他们是最聪明的人，并且制定了最复杂的计划）将帮助协调工作，以便工人知道何时完成工作（框架调用您的代码）。工作人员只需要足够灵活即可使用管理人员提供给他们的任何工具（通过使用依赖注入）。

尽管工人将管理项目的控制权交给了经理（框架）。但是有一些专业人士的帮助是一件好事。这是IoC的概念真正源于此。

具有MVC架构的现代Web应用程序依赖于框架进行URL路由，并放置控制器以供框架调用。

依赖注入和控制反转相关。依赖注入在微观级别，而控制反转在宏观级别。您必须吃饱每一口（实施DI）才能吃完饭（实施IoC）。

#4楼

假设您是一个对象。然后您去一家餐厅：

如果没有IoC ：您要求“苹果”，而当您提出更多要求时，您总是会得到苹果。

使用IoC ：您可以要求“水果”。每次上菜都可以得到不同的水果。例如苹果，橙子或西瓜。

因此，显然，当您喜欢这些品种时，IoC是首选。

#5楼

控制反转是关于分离关注点。

没有IoC的情况 ：您有一台笔记本电脑，并且不小心打破了屏幕。而且，您发现市场上没有同型号的笔记本电脑屏幕。所以你被困住了。

使用IoC ：您有一台台式计算机，并且不小心打破了屏幕。您会发现您几乎可以从市场上买到任何台式机显示器，并且它可以很好地与您的台式机配合使用。

在这种情况下，您的桌面成功实现了IoC。它可以接受多种类型的显示器，而笔记本电脑则不能，它需要特定的屏幕才能固定。

#6楼

例如，任务1是创建对象。没有IOC概念，任务＃1应该由Programmer完成，但是有IOC概念，任务＃1将由容器完成。

简而言之，控制权从程序员转换为容器。因此，这称为控制反转。

我在这里找到了一个很好的例子。

#7楼

在使用Inversion of Control之前，您应该充分了解它有其优点和缺点的事实，并且应该知道为什么要使用它。

优点：

您的代码被解耦，因此您可以轻松地将接口的实现与其他实现互换
它是针对接口而非实现进行编码的强大动力
为代码编写单元测试非常容易，因为它只依赖于其构造函数/设置器中接受的对象，并且可以轻松地使用正确的对象来单独初始化它们。

缺点：

IoC不仅会颠倒程序中的控制流，还会使它变得相当模糊。这意味着您不再只能阅读代码并从一个地方跳到另一个地方，因为通常在您的代码中存在的连接不再在代码中。而是在XML配置文件或注释中以及在解释这些元数据的IoC容器的代码中。
出现了一类新的错误，您在该错误中将XML配置或批注弄错了，您可以花费大量时间来找出为什么IoC容器在特定条件下将空引用注入到一个对象中的原因。

我个人看到了IoC的优点，并且我真的很喜欢它们，但是我倾向于尽可能避免使用IoC，因为它将您的软件变成一个类的集合，这些类不再构成“真正的”程序，而只是需要将它们组合在一起XML配置或注释元数据，如果没有它，它会崩溃。

#8楼

IoC是关于反转您的代码与第三方代码（库/框架）之间的关系的：

在正常的软件开发中，您编写main（）方法并调用“库”方法。您在控制中:)
在IoC中，“框架”控制main（）并调用您的方法。该框架处于控制之中:(

DI（依赖注入）与控件在应用程序中的流动方式有关。传统的桌面应用程序具有从您的应用程序（main（）方法）到其他库方法调用的控制流，但是随着DI控制流的反转，该框架将负责启动您的应用程序，对其进行初始化并在需要时调用您的方法。

最后你总是赢:)

#9楼

我将写下对这两个术语的简单理解：

For quick understanding just read examples*

依赖注入（DI）：
依赖注入通常意味着将方法所依赖的对象作为方法的参数传递给方法，而不是让方法创建依赖对象 。
实际上，这意味着该方法不直接取决于特定的实现。满足要求的任何实现都可以作为参数传递。

有了这个对象，就可以告诉他们依赖性。 春天使它可用。
这导致松散耦合的应用程序开发。

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

控制反转（IoC）容器：
这是框架的共同特征，IOC 管理java对象
–从实例化到通过其BeanFactory进行销毁。
-由IoC容器实例化的Java组件称为bean，而IoC容器管理bean的作用域，生命周期事件以及为其配置和编码的任何AOP功能 。

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it 。

通过实现控制反转，软件/对象使用者可以获得比软件/对象更多的控件/选项，而不是被控制或具有更少的选项。

将控制反转作为设计准则可达到以下目的：

某个任务的执行与实现之间存在脱钩。
每个模块都可以专注于其设计目的。
模块不假设其他系统在做什么，而是依赖其合同。
更换模块对其他模块没有副作用
我将在这里保持抽象，您可以访问以下链接以详细了解该主题。
一个很好的例子

详细说明

#10楼

编程口语

简单来说，IoC：这是使用接口作为通配符将某些特定事物（例如字段或参数）用作某些类可以使用的方式。它允许代码的重用性。

例如，假设我们有两个类： Dog和Cat 。两者具有相同的质量/状态：年龄，大小，体重。因此，而不是创建一个服务等级称为DogService和CatService的，我可以创建一个单一的一个叫AnimalService，只允许如果他们使用的接口IAnimal使用狗和猫。

但是，从务实的角度来说，它有些落后。

a） 大多数开发人员都不知道如何使用它 。例如，我可以创建一个名为Customer的类，并且可以自动创建 （使用IDE的工具）一个名为ICustomer的接口。因此，无论接口是否被重用，都很难找到一个充满类和接口的文件夹。它被称为BLOATED。有人可能会争辩说“也许将来我们可以使用它”。：-|

b）有一些限制。例如，让我们谈谈“ 狗和猫”的情况，我想添加仅针对狗的新服务（功能）。假设我要计算训练狗的天数（ trainDays() ），因为猫没用，猫不能训练（我在开玩笑）。

b.1）如果我将trainDays()添加到Service AnimalService，则它也适用于cats，并且完全无效。

b.2）我可以在trainDays()中添加一个条件，以评估使用哪个类。但是它将完全破坏IoC。

b.3）我可以为新功能创建一个称为DogService的新服务类。但是，这将增加代码的可维护性，因为我们将为Dog提供两类服务（具有相似的功能），这很不好。

#11楼

在类内创建对象称为紧密耦合，Spring通过遵循设计模式（DI / IOC）消除了这种依赖性。在类的哪个对象中传入构造函数，而不是在类中创建。此外，我们在构造函数中提供超类引用变量以定义更通用的结构。

#12楼

维基百科文章。对我而言，控制权的转换是将您顺序编写的代码转换为委托结构。程序没有设置明确控制所有内容的程序，而是设置了具有某些功能的类或库，以在发生某些事情时调用它们。
它解决了代码重复。例如，在过去，您将手动编写自己的事件循环，在系统库中轮询新事件。如今，大多数现代API只需告诉系统库您对哪些事件感兴趣，它就会在事件发生时通知您。
控制反转是减少代码重复的一种实用方法，如果您发现自己复制了整个方法而只更改了一小段代码，则可以考虑通过控制反转解决它。通过代理，接口甚至原始函数指针的概念，在许多语言中，控制反转都变得很容易。
不适合在所有情况下使用，因为以这种方式编写程序时，流程很难遵循。这是编写将被重用的库时设计方法的一种有用方法，但是除非您真正解决了代码重复问题，否则应在您自己程序的核心中谨慎使用它。

#13楼

我同意NilObject ，但我想补充一点：

如果您发现自己复制了整个方法而只更改了一小段代码，则可以考虑通过控制反转解决它

如果你发现自己复制和粘贴周围的代码，你总是做错事。编成设计原则一次，也只有一次。

#14楼

当程序回调（例如gui程序）时，您将获得控制反转。

例如，在旧的学校菜单中，您可能具有：

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

从而控制用户交互的流程。

在GUI程序或类似程序中，我们改为：

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

因此，现在控制权被颠倒了...而不是计算机按照固定的顺序接受用户输入，而是由用户控制输入数据的顺序以及何时将数据保存在数据库中。

基本上，任何带有事件循环，回调或执行触发器的东西都属于此类。

#15楼

控制反转（IoC）和依赖注入（DI）模式都是关于从代码中删除依赖的。

例如，假设您的应用程序具有文本编辑器组件，而您想提供拼写检查。您的标准代码如下所示：

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

我们在这里所做的创建了TextEditor和SpellChecker之间的依赖关系。在IoC场景中，我们改为执行以下操作：

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

在第一个代码示例中，我们实例SpellChecker （ this.checker = new SpellChecker(); ），这意味着该TextEditor直接类依赖于所述SpellChecker类。

在第二个代码示例中，我们通过在TextEditor构造函数签名中具有SpellChecker依赖关系类（而不是在类中初始化依赖关系）来创建抽象。这使我们可以调用依赖项，然后将其传递给TextEditor类，如下所示：

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

现在，创建TextEditor类的客户端可以控制使用哪个SpellChecker实现，因为我们正在将依赖项注入到TextEditor签名中。

#16楼

使用IoC，您并不是新手。您的IoC容器将做到这一点并管理它们的生命周期。

它解决了必须将一种对象的每个实例实例手动更改为另一种实例的问题。