DIP vs DI vs IoC

[依赖倒置原则(DIP)]是SOLID[About]的一部分，它要求你使用抽象而不是实现

依赖注入(DI) -使用聚合而不是组合[关于]在这种情况下，外部对象负责内部的逻辑。哪一种方法使您拥有更动态和更可测试的方法

class A {
  B b

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

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

DIP +

class A {
  IB ib

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

你也可以使用:

(工厂方法) (服务定位器) [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")
    }
}

IoC -控制反转是一个通用术语，与语言无关，它实际上不是创建对象，而是描述如何创建时尚对象。

依赖注入是一个具体的术语，我们通过使用不同的注入技术，即Setter注入、构造函数注入或接口注入，在运行时提供对象的依赖关系。

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

// 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的一种特殊实现，具有特定的关注点。您不是将模型和行为注入到应用程序框架或更高阶操作中，而是将变量注入到函数或对象中。

但是spring文档说它们是一样的。

http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction

在第一行“IoC也被称为依赖注入(DI)”。

IOC(控制反转):将获取对象实例的控制权交给容器称为控制反转，这意味着不是您使用new操作符创建对象，而是让容器为您创建对象。

DI(依赖注入):向对象注入属性的方式称为依赖注入。

我们有三种类型的依赖注入:

构造函数注入 Setter和Getter注入 接口注入

Spring只支持构造函数注入和Setter/Getter注入。

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

However once the OOP emerged, people began to talk about IoC in OOP context where applications are concerned with object creation and their relationships as well, apart from the control-flow. Such applications wanted to invert the ownership of object-creation (rather than control-flow) and required a container which is responsible for object creation, object life-cycle & injecting dependencies of the application objects thereby eliminating application objects from creating other concrete object.

从这个意义上讲，DI与IoC不同，因为它不是关于控制流的，但是它是一种Io*，即对象创建的所有权倒置。

我解释DI和IoC的方式有什么问题?