oop - 控制的组成和反转

Question

我刚刚遇到了设计松散耦合软件架构的控制反转方法(使用依赖注入(inject)实现)。根据我的理解，IOC 方法旨在通过在另一个类中实例化一个类的对象来解决与类之间的紧密耦合相关的问题，这在理想情况下不应该发生(根据模式)。我的理解是否正确？

如果上述情况属实，那么组合或具有关系(OO 的非常基本的重要方面)的情况如何。例如，我使用已经定义的链表类编写堆栈类，因此我在堆栈类中实例化了一个链表类。但根据 IOC，这将导致紧密耦合，从而导致糟糕的设计。这是真的？我在组合或有关系和 IOC 之间有点混淆。

Answer 1

As per my understanding the IOC approach aims to solve problem related to tight coupling between classes by instantiating an object of a class inside another class which should ideally not happen (as per the pattern). Is my understanding correct here?

关闭，但您稍微偏离了。当您定义类之间的契约(Java 中的接口(interface))时，紧密耦合的问题就会得到解决。由于您需要契约(Contract)(接口(interface))的实现，因此在某些时候必须提供这些实现。 IoC 是提供实现的一种方式，但不是唯一的方式。如此紧密的耦合实际上与控制反转正交(意味着它没有直接关系)。

更具体地说，您可以有松散耦合但没有 IoC。 IoC 部分是实现来自组件外部。考虑定义一个使用接口(interface)实现的类的情况。当您测试该类时，您可能会提供一个模拟。当您将模拟传递给被测类时，您并没有使用 IoC。但是，当您启动应用程序时，IoC 容器决定将什么传递给您的类，这就是 IoC。

For an example I write my stack class using a linked list class already defined so I instantiate a linked list class inside my stack class. But as per IOC this will result in tight coupling and hence a bad design. Is this true? I am bit confused here between composition or has-a relationship and IOC.

是和否。在一般意义上，您不需要完全抽象应用程序中的每一个功能。你可以，纯粹主义者可能会，但这可能是乏味和过度的。

在这种情况下，您可以将您的堆栈视为一个黑匣子，而不是使用 IoC 来管理它。请记住，堆栈本身是松散耦合的，因为堆栈的行为可以被抽象掉。另外，请考虑以下两个定义

class StackImpl implements Stack {
   private List backingList

对

class StackImpl implements Stack {
   private LinkedList backingList

第一个大大优于第二个，正是因为它更容易更改 List 实现；即您已经提供了松散耦合。

这就是我所能接受的。此外，如果您使用组合，您当然可以配置大多数 IoC 容器(如果不是全部)以将内容传递给构造函数或调用 setter，因此您仍然可以拥有 has-A 关系。 p>