首页 文章

什么是控制倒置？

提问于
浏览 次
1505

控制反转（或IoC）在第一次遇到时会非常混乱 .

  • 这是什么？

  • 它解决了什么问题？

  • 什么时候合适，什么时候不合适？

oop design-patterns inversion-of-control

30 回答

  • 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 签名 .

    这只是一个简单的例子，Simone Busoli的a good series of articles更详细地解释了它 .

    回复于
  • 3

    控制反转是您在程序回调时获得的，例如像一个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

    因此，现在控制被反转...用户不是以固定顺序接受用户输入，而是控制输入数据的顺序，以及何时将数据保存在数据库中 .

    基本上，任何具有事件循环，回调或执行触发器的东西都属于这一类 .

    回复于
  • 19

    仅回答第一部分 . 它是什么？

    控制反转（IoC）意味着创建依赖关系的第一个和后一个实例的实例（可选择通过构造函数注入它们），而不是先创建类的实例，然后创建依赖关系实例的类实例 . 因此，反转控制 inverts 的程序 . Instead of callee controlling flow of control （在创建依赖项时）， caller controls the flow of control of the program .

    回复于
  • 25

    什么是控制倒置？

    如果你按照这两个简单的步骤，你就完成了控制反转：

    • 将 what -to-do部分与 when -to-do部分分开 .

    • 确保 when 部分尽可能少地了解 what part;反之亦然 .

    根据您实施的技术/语言，每种步骤都有几种可能的技术 .

    控制反转（IoC）的反转部分是令人困惑的事情;因为反演是相对的术语 . 理解IoC的最好方法就是忘记这个词！

    例子

    • 事件处理 . 事件处理程序（要做什么的部分） - 提升事件（什么时候做部分）

    • 接口 . 组件客户端（部分时间） - 组件接口实现（可执行部分）

    • xUnit fixure . Setup和TearDown（有待完成的部分） - xUnit框架在开始时调用Setup，在结束时调用TearDown（when-to-do部分）

    • 模板方法设计模式 . 模板方法什么时候做的部分 - 原始子类实现什么做的部分
      COM中的

    • DLL容器方法 . DllMain，DllCanUnload等（要做什么的部分） - COM / OS（什么时候做部分）

    回复于
  • 8

    控制反转是关于分离问题 .

    Without IoC ：您有一台 laptop 计算机而且您不小心打破了屏幕 . 而且，你会发现同样型号的笔记本电脑屏幕在市场上无处可去 . 所以你被卡住了 .

    With IoC ：你有一台 desktop 电脑而且你不小心弄坏了屏幕 . 您发现几乎可以从市场上购买任何桌面显示器，它可以很好地与您的桌面配合使用 .

    在这种情况下，您的桌面成功实现了IoC . 它接受各种类型的显示器，而笔记本电脑没有，它需要一个特定的屏幕来修复 .

    回复于
  • 3

    控制反转（或IoC）约为 getting freedom （你结婚了，你失去了自由，你被控制了 . 你离婚了，你刚刚实施了控制反转 . 这就是我们所说的，"decoupled" . 良好的计算机系统阻止一些非常亲密的关系 . ） more flexibility （你办公室的厨房只提供干净的自来水，这是你想喝的唯一选择 . 你的老板通过设置一台新的咖啡机实现了控制倒置 . 现在你可以灵活选择自来水或咖啡 . ）和 less dependency （你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制 . 你找到了工作，你实施了倒置控制良好的计算机系统鼓励依赖 . ）

    当您使用台式计算机时，您已经从事（或说，控制） . 你必须坐在屏幕前看看它 . 使用键盘键入并使用鼠标进行导航 . 一个编写得很糟糕的软件可以让你更加依赖 . 如果用笔记本电脑替换桌面，那么你有点颠倒控制 . 你可以轻松地拿走它并四处走动 . 因此，现在您可以控制计算机的位置，而不是控制计算机的计算机 .

    通过实现控制反转，软件/对象消费者可以获得对软件/对象的更多控制/选项，而不是受控制或具有更少的选项 .

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

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

    虽然 Worker 将管理项目的控制权交给管理者（框架） . 但是让一些专业人士帮忙是件好事 . 这就是IoC真正来自的概念 .

    具有MVC体系结构的现代Web应用程序依赖于进行URL路由的框架，并将控制器放置到适合框架调用的位置 .

    依赖注入和控制反转是相关的 . 依赖注入处于 micro 级别，控制反转处于 macro 级别 . 你必须吃每一口（实施DI）才能吃完饭（实施IoC） .

    回复于
  • 110

    在使用Inversion of Control之前，你应该清楚它有它的优点和缺点，你应该知道为什么要使用它 .

    优点：

    • 您的代码被解耦，因此您可以轻松地与其他实现交换接口的实现

    • 它是针对接口而不是实现进行编码的强大动力

    • 为代码编写单元测试非常容易，因为它只取决于它在构造函数/设置器中接受的对象，您可以轻松地使用正确的对象初始化它们 .

    缺点：

    • IoC不仅可以反转程序中的控制流程，还可以显着地覆盖它 . 这意味着您不能再只读取代码并从一个地方跳转到另一个地方，因为代码中通常存在的连接不再存在于代码中 . 相反，它在XML配置文件或注释中以及IoC容器的代码中解释这些元数据 .

    • 出现了一类新的错误，你的XML配置或注释错误，你可以花很多时间找出你的IoC容器在某些条件下为你的一个对象注入空引用的原因 .

    就个人而言，我看到了IoC的优点，我真的很喜欢它们，但我倾向于尽可能地避免使用IoC，因为它会将您的软件变成一个不再构成“真正”程序的类集合，而只需将它们放在一起XML配置或注释元数据会在没有它的情况下掉落（和掉落） .

    回复于
  • 14

    • Wikipedia Article . 对我而言，控制反转正在转变您按顺序编写的代码并将其转换为委托结构 . 您的程序不是使用程序显式控制所有内容，而是设置一个具有某些功能的类或库，以便在发生某些事情时调用它们 .

    • 它解决了代码重复问题 . 例如，在过去，您将手动编写自己的事件循环，轮询系统库以获取新的事件 . 如今，大多数现代API您只需告诉系统库您感兴趣的事件，它会在发生时告知您 .

    • 控制反转是一种减少代码重复的实用方法，如果您发现自己复制整个方法并且只更改了一小段代码，则可以考虑使用控制反转来解决它 . 通过委托，接口甚至原始函数指针的概念，在许多语言中使控制反转变得容易 .

    在所有情况下都不适合使用，因为当以这种方式编写时，程序的流程可能更难以遵循 . 在编写将被重用的库时，这是一种设计方法的有用方法，但它应该在您自己的程序的核心中谨慎使用，除非它真正解决了代码重复问题 .

    回复于
  • 373

    但我认为你必须非常小心 . 如果您过度使用此模式，您将进行非常复杂的设计和更复杂的代码 .

    就像在TextEditor的这个例子中一样：如果你只有一个SpellChecker可能没有必要使用IoC？除非您需要编写单元测试或其他东西......

    无论如何：要合理 . 设计模式是 good practices 但不是圣经可以传播 . 不要把它粘在任何地方 .

    回复于
  • 37

    对我来说，IoC / DI正在推出对调用对象的依赖 . 超级简单 .

    非技术性的答案是能够在开启之前更换汽车中的引擎 . 如果一切正常（界面），你很好 .

    回复于
  • 37

    假设你是一个对象 . 你去餐馆吃饭：

    Without IoC ：你要求"apple"，当你提出更多问题时，你总会得到苹果 .

    With IoC ：你可以要求"fruit" . 每次送达时，您都可以获得不同的水果 . 例如，苹果，橙子或西瓜 .

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

    回复于
  • 9

    • 控制反转是用于解耦系统中的组件和层的模式 . 该模式是通过在构造组件时将依赖项注入组件来实现的 . 这些依赖关系通常作为进一步解耦和支持可测试性的接口提供 . 像Castle Windsor，Unity这样的IoC / DI容器是可用于提供IoC的工具（库） . 这些工具提供了超越简单依赖关系管理的扩展功能，包括生命周期，AOP /拦截，策略等 .

    • a . 减轻组件负责管理其依赖关系 .
      湾提供在不同环境中交换依赖项实现的功能 .
      C . 允许通过模拟依赖项来测试组件 .
      d . 提供在整个应用程序中共享资源的机制 .

    • a . 在进行测试驱动开发时很关键 . 没有IoC，测试就很困难，因为被测组件与系统的其余部分高度耦合 .
      湾开发模块化系统时至关重要模块化系统是一种系统，其组件可以在不需要重新编译的情况下进行更换 .
      C . 如果在企业应用程序中有许多需要解决的跨领域问题，则至关重要 .

    回复于
  • 84

    I shall write down my simple understanding of this two terms:

    For quick understanding just read examples*

    Dependency Injection(DI):
    依赖注入通常意味着 passing an object on which method depends, as a parameter to a method, rather than having the method create the dependent object .
    在实践中它意味着该方法不直接取决于特定的实现;任何满足要求的实现都可以作为参数传递 .

    用这个对象告诉他们的依赖关系 . Spring 天使它可用 .
    这导致松散耦合的应用程序开发 .

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

    Inversion of Control(IoC) Container:
    这是框架的共同特征，IOC manages java objects

    • 从实例化到通过BeanFactory进行销毁 .
      -Iava容器实例化的Java组件称为bean， IoC container manages a bean's scope, lifecycle events, and any AOP features 已为其配置和编码 .

    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 .

    通过实现控制反转，软件/对象消费者可以获得对软件/对象的更多控制/选项，而不是受控制或具有更少的选项 .

    Inversion of control as a design guideline serves the following purposes:

    将某个任务的执行与实现分离开来 .
    每个模块都可以专注于它的设计目标 .
    模块不会假设其他系统的功能，而是依赖于 Contract .
    更换模块对其他模块没有副作用
    我将在这里保留摘要，您可以访问以下链接以了解该主题的详细信息 .
    A good read with example

    Detailed explanation

    回复于
  • 20

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

    简而言之，Control从Programmer转换为容器 . 因此，它被称为控制反转 .

    我找到了一个很好的例子here .

    回复于
  • 11

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

    如果你发现自己复制了整个方法而只改变了一小段代码，你可以考虑用控制反转来解决它

    如果你发现自己复制和粘贴代码，你几乎总是做错了 . 编纂为设计原则Once and Only Once .

    回复于
  • 8

    看起来关于“IoC”这个首字母缩写词和它所代表的名字最令人困惑的是，它的名字太过迷人 - 几乎是一个噪音名称 .

    我们真的需要一个名称来描述程序和事件驱动编程之间的区别吗？好吧，如果我们需要，但是我们是否需要选择一个全新的“比生命更重要”的名称，这个名称比它解决的更加困惑？

    回复于
  • 16

    我们说我们在一些酒店开会 .

    很多人，许多玻璃水瓶，许多塑料杯 .

    当有人想喝酒时，她会把杯子，饮料和杯子倒在地板上 .

    一小时后，我们的地板上覆盖着塑料杯和水 .

    让反转控制 .

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

    她总是向客人提供饮酒 .

    当有人想喝酒的时候，她会从服务员的杯子里拿出来喝，然后把它还给服务员 .

    撇开卫生问题，最后一种形式的饮用过程控制更加有效和经济 .

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

    把自己想象成这种 Session 的组织者 . 您需要向酒店管理部门发送消息的方式

    Session 成员需要一杯水而不是一块蛋糕 .

    Example:-

    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

}

    Useful links:-

    回复于
  • 3

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

    • 在正常的s / w开发中，编写 main() 方法并调用"library"方法 . You 在控制中:)

    • 在IoC中，"framework"控制 main() 并调用您的方法 . Framework 在控制中:(

    DI（依赖注入）是关于控件如何在应用程序中流动的 . 传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但是DI控制流被反转，框架负责启动应用程序，初始化它并在需要时调用您的方法 .

    最后你总是赢:)

    回复于
  • 8

    我发现了一个非常明确的例子here，它解释了如何'control is inverted' .

    Classic code (without Dependency injection)

    以下是不使用DI的代码将大致如何工作：

    • 应用程序需要Foo（例如控制器），因此：

    • 应用程序创建Foo

    • 应用程序调用Foo

    • Foo需要Bar（例如服务），所以：

    • Foo创建了Bar

    • Foo给Bar打电话

    • Bar需要Bim（服务，存储库......），所以：

    • Bar创建了Bim

    • Bar做了些什么

    Using dependency injection

    以下是使用DI的代码大致如何工作：

    • 应用程序需要Foo，需要Bar，需要Bim，所以：

    • 应用程序创建Bim

    • 应用程序创建Bar并将其赋予Bim

    • 应用程序创建Foo并为其提供Bar

    • 应用程序调用Foo

    • Foo给Bar打电话

    • Bar做了些什么

    The control of the dependencies is inverted from one being called to the one calling.

    What problems does it solve?

    依赖注入使得可以轻松地与注入类的不同实现进行交换 . 在进行单元测试时，您可以注入虚拟实现，这使得测试更容易 .

    例如：假设您的应用程序将用户上传的文件存储在Google Cloud 端硬盘中，使用DI您的控制器代码可能如下所示：

    class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

    当您的要求发生变化时，系统会要求您使用Dropbox而不是GoogleDrive . 您只需要为StorageServiceInterface编写一个Dropbox实现 . 只要Dropbox实现遵循StorageServiceInterface，您就不会在控制器中进行任何更改 .

    在测试时，您可以使用虚拟实现为StorageServiceInterface创建模拟，其中所有方法都返回null（或根据您的测试要求的任何预定义值） .

    相反，如果你有控制器类用 new 关键字构造存储对象，如下所示：

    class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

    如果要使用Dropbox实现进行更改，则必须替换构造 new GoogleDriveService对象的所有行，并使用DropboxService . 此外，在测试SomeController类时，构造函数总是期望GoogleDriveService类和此类的实际方法被触发 .

    When is it appropriate and when not? 在我看来，如果您认为某个类的替代实现（或可能存在），则使用DI .

    回复于
  • 515

    Inversion of control 是你去杂货店的时候，你妻子给你的产品清单 .

    在编程术语中，她将回调函数 getProductList() 传递给您正在执行的函数 doShopping() ;

    它允许函数的用户定义它的某些部分，使其更加灵活 .

    回复于
  • 10

    这里可以找到一个非常简单的书面解释

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

    它说

    “任何重要的应用程序都由两个或多个相互协作以执行某些业务逻辑的类组成 . 传统上，每个对象都负责获取它自己对与之协作的对象（其依赖项）的引用 . 在应用DI时，这些对象在创建时由一些外部实体给出它们的依赖关系，这些外部实体协调系统中的每个对象 . 换句话说，依赖关系被注入到对象中 .

    回复于
  • 8

    编程说话

    IoC简单易用：它使用Interface作为特定事物（如字段或参数）的一种方式，作为可由某些类使用的通配符 . 它允许代码的可重用性 .

    例如，假设我们有两个类： Dog 和 Cat . 两者都具有相同的品质/状态：年龄，体型，体重 . 因此，我不是创建一个名为 DogService 和 CatService 的服务类，而是创建一个名为 AnimalService 的服务，只有在使用接口 IAnimal 时才允许使用Dog和Cat .

    然而，从实用角度讲，它有一些倒退 .

    a） Most of the developers don't know how to use it . 例如，我可以创建一个名为 Customer 和 I can create automatically 的类（使用IDE的工具）一个名为 ICustomer 的接口 . 所以，'s not rare to find a folder filled with classes and interfaces, no matter if the interfaces will be reused or not. It'被称为BLOATED . 有些人可能会争辩说"may be in the future we could use it" . ： - |

    b）它有一些限制 . 例如，让我们谈谈 Dog 和 Cat 的情况，我想只为狗添加新的服务（功能） . 假设我想计算训练狗需要的天数（ trainDays() ），因为猫训练它（我在开玩笑） .

    b.1）如果我将 trainDays() 添加到服务 AnimalService 然后它也适用于猫，它根本无效 .

    b.2）我可以在 trainDays() 中添加一个条件来评估使用哪个类 . 但它会彻底打破IoC .

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

    回复于
  • 3

    控制反转是一种通用原则，而依赖注入将此原则实现为对象图构造的设计模式（即，配置控制对象如何相互引用，而不是控制如何获取对另一个对象的引用的对象本身） .

    将控制反转看作一种设计模式，我们需要看看我们正在反转的是什么 . 依赖注入反转了构造对象图的控制 . 如果以外行人的话说，控制权的反转意味着计划中控制流的变化 . 例如 . 在传统的独立应用程序中，我们有主要方法，从控件传递到其他第三方库（以防我们使用第三方库）功能），但通过控制控制的反转从第三方库代码转移到我们的代码，因为我们正在服务第三方库 . 但是还有其他方面需要在程序中反转 - 例如调用方法和线程来执行代码 .

    对于那些对控制反转更深入感兴趣的人，已经发表了一篇论文，概述了一个更完整的控制反转图片作为设计模式（OfficeFloor：使用办公室模式来改进软件设计http://doi.acm.org/10.1145/2739011.2739013，可以从http://www.officefloor.net/mission.html下载免费副本）

    确定的是以下关系：

    控制反转（方法）=依赖（状态）注射连续注射螺纹注射

    回复于
  • 57

    我喜欢这个解释：http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

    它从简单开始，并显示代码示例 .

    enter image description here

    消费者X需要消费类Y来完成某些事情 . 这一切都是好的和自然的，但X真的需要知道它使用Y吗？

    是不是X知道它使用的东西具有Y的行为，方法，属性等而不知道谁实际实现了这种行为？

    通过提取Y在Y中使用的行为的抽象定义，如下所示，并且让消费者X使用该实例而不是Y，它可以继续做它所做的事情而不必知道关于Y的细节 .

    enter image description here

    在上面的插图中，Y实现I和X使用I的实例 . 虽然X仍然很可能使用Y，但有趣的是X不知道 . 它只知道它使用的东西实现我 .

    阅读文章了解更多信息和福利描述，例如：

    • X不再依赖于Y.

    • 更灵活，可以在运行时决定实现

    • 隔离代码单元，更容易测试

    ...

    回复于
  • 1207

    我知道这里已经给出了答案 . 但我仍然认为，关于控制反转的一些基础知识必须在这里为未来的读者进行讨论 .

    控制反转（IoC） Build 在一个非常简单的原理 Hollywood Principle 上 . 它说，

    不要打电话给我们，我们会打电话给你

    这意味着不要去好莱坞实现你的梦想，而不是如果你值得，那么好莱坞会找到你并让你的梦想成真 . 几乎倒了，是吧？

    现在，当我们讨论IoC的原理时，我们会忘记好莱坞 . 对于IoC来说，必须有三个元素，一个好莱坞，你和一个完成你梦想的任务 .

    在我们的编程世界中， Hollywood 代表一个通用框架（可能由您或其他人编写）， you 代表您编写的用户代码， the task 代表您希望使用代码完成的事情 . 现在你永远不会自己触发你的任务，而不是IoC！相反，您已经设计了所有内容，以便您的框架将为您触发任务 . 因此，您构建了一个可重用的框架，可以使某人成为英雄或其他人成为恶棍 . 但是这个框架总是负责，它知道什么时候选择某人，而且某人只知道它想成为什么 .

    这里将给出一个真实的例子 . 假设您要开发Web应用程序 . 因此，您创建了一个框架，它将处理Web应用程序应处理的所有常见事项，如处理http请求，创建应用程序菜单，提供页面，管理cookie，触发事件等 .

    然后你在框架中留下一些钩子，你可以在其中放置更多的代码来生成自定义菜单，页面，cookie或记录一些用户事件等 . 在每个浏览器请求中，你的框架将运行并执行你的自定义代码，如果挂钩然后回服务到浏览器 .

    所以，这个想法非常简单 . 首先，您需要创建一个可重用的框架来控制所有内容，然后编写自定义代码并将其挂钩到框架以及时执行这些代码，而不是创建将控制所有内容的用户应用程序 .

    Laravel和EJB就是这种框架的例子 .

    参考：

    https://martinfowler.com/bliki/InversionOfControl.html

    https://en.wikipedia.org/wiki/Inversion_of_control

    回复于
  • 41

    控制的反转是关于将控制从库转移到客户端 . 当我们谈论将函数值（lambda表达式）注入（传递）到控制（改变）库函数行为的高阶函数（库函数）的客户端时，它更有意义 . 将库依赖项（带有行为）注入的客户机或框架库也可以被认为是IoC

    回复于
  • 4

    在使用Castle Windsor这样的容器时，它可以更好地解决维护问题 . 能够在没有更改代码行的情况下将转移到数据库的组件转换为使用基于文件的持久性的组件非常棒（配置更改，您已完成） .

    一旦你进入泛型，它会变得更好 . 想象一下，有一个消息发布者接收记录并发布消息 . 它并不关心它发布的内容，但它需要一个映射器来从记录到消息 .

    public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

    我写了一次，但是如果我发布不同类型的消息，现在我可以在这组代码中注入许多类型 . 我也可以编写具有相同类型记录的映射器，并将它们映射到不同的消息 . 在Generics中使用DI使我能够编写很少的代码来完成许多任务 .

    哦，是的，有可测性问题，但它们是次要的IoC / DI的好处 .

    我绝对喜欢IoC / DI .

    3 . 一旦你有一个更复杂的中型项目，它就变得更加合适 . 我会说你开始感到疼痛的那一刻就变得合适了 .

    回复于
  • 15

    在类中创建对象称为紧耦合，Spring通过遵循设计模式（DI / IOC）来消除此依赖关系 . 类的哪个对象在构造函数中传递而不是在类中创建 . 更重要的是我们在构造函数中给出超类引用变量来定义更一般的结构 .

    回复于
  • 4

    使用IoC，你不是新手 . 您的IoC容器将执行此操作并管理它们的生命周期 .

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

    当您具有将来可能更改的功能或根据所使用的环境或配置可能有所不同时，它是适当的 .

    回复于
  • 77

    为了理解这个概念，控制反转（IoC）或依赖性反转原理（DIP）涉及两个活动：抽象和反演 . 依赖注入（DI）只是少数几种反演方法之一 .

    要了解更多相关信息，请阅读我的博客Here

    • 这是什么？

    这是一种让实际行为来自边界之外的实践（面向对象编程中的类） . 边界实体只知道它的抽象（例如接口，抽象类，面向对象编程中的委托） .

    • 它解决了什么问题？

    在编程方面，IoC尝试通过使其模块化，解耦其各个部分并使其可单元测试来解决单片代码 .

    • 什么时候合适，什么时候不合适？

    在大多数情况下这是合适的，除非你有你想要单片代码的情况（例如非常简单的程序）

    回复于

相关问题