我们可以实现依赖注入来了解它：

class Injector {
  constructor() {
    this.dependencies = {};
    this.register = (key, value) => {
      this.dependencies[key] = value;
    };
  }
  resolve(...args) {
    let func = null;
    let deps = null;
    let scope = null;
    const self = this;
    if (typeof args[0] === 'string') {
      func = args[1];
      deps = args[0].replace(/ /g, '').split(',');
      scope = args[2] || {};
    } else {
      func = args[0];
      deps = func.toString().match(/^function\s*[^\(]*\(\s*([^\)]*)\)/m)[1].replace(/ /g, '').split(',');
      scope = args[1] || {};
    }
    return (...args) => {
      func.apply(scope || {}, deps.map(dep => self.dependencies[dep] && dep != '' ? self.dependencies[dep] : args.shift()));
    }
  }
}

injector = new Injector();

injector.register('module1', () => { console.log('hello') });
injector.register('module2', () => { console.log('world') });

var doSomething1 = injector.resolve(function (module1, module2, other) {
  module1();
  module2();
  console.log(other);
});
doSomething1("Other");

console.log('--------')

var doSomething2 = injector.resolve('module1,module2,', function (a, b, c) {
  a();
  b();
  console.log(c);
});
doSomething2("Other");

以上是javascript的实现

依赖注入（DI）是设计模式中的一种，它使用了OOP的基本特性——一个对象与另一个对象之间的关系。虽然继承继承一个对象以实现更复杂和更具体的另一个对象，但关系或关联只需使用属性从一个对象创建指向另一对象的指针。DI的功能与OOP的其他特性相结合，如接口和隐藏代码。假设图书馆里有一个客户（订阅者），为了简单起见，他只能借一本书。

书本界面：

package com.deepam.hidden;

public interface BookInterface {

public BookInterface setHeight(int height);
public BookInterface setPages(int pages);   
public int getHeight();
public int getPages();  

public String toString();
}

接下来我们可以有很多种书；其中一种类型是虚构：

package com.deepam.hidden;

public class FictionBook implements BookInterface {
int height = 0; // height in cm
int pages = 0; // number of pages

/** constructor */
public FictionBook() {
    // TODO Auto-generated constructor stub
}

@Override
public FictionBook setHeight(int height) {
  this.height = height;
  return this;
}

@Override
public FictionBook setPages(int pages) {
  this.pages = pages;
  return this;      
}

@Override
public int getHeight() {
    // TODO Auto-generated method stub
    return height;
}

@Override
public int getPages() {
    // TODO Auto-generated method stub
    return pages;
}

@Override
public String toString(){
    return ("height: " + height + ", " + "pages: " + pages);
}
}

现在，用户可以与图书建立关联：

package com.deepam.hidden;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class Subscriber {
BookInterface book;

/** constructor*/
public Subscriber() {
    // TODO Auto-generated constructor stub
}

// injection I
public void setBook(BookInterface book) {
    this.book = book;
}

// injection II
public BookInterface setBook(String bookName) {
    try {
        Class<?> cl = Class.forName(bookName);
        Constructor<?> constructor = cl.getConstructor(); // use it for parameters in constructor
        BookInterface book = (BookInterface) constructor.newInstance();
        //book = (BookInterface) Class.forName(bookName).newInstance();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return book;
}

public BookInterface getBook() {
  return book;
}

public static void main(String[] args) {

}

}

这三个类都可以隐藏起来，以便实现自己的功能。现在我们可以将此代码用于DI：

package com.deepam.implement;

import com.deepam.hidden.Subscriber;
import com.deepam.hidden.FictionBook;

public class CallHiddenImplBook {

public CallHiddenImplBook() {
    // TODO Auto-generated constructor stub
}

public void doIt() {
    Subscriber ab = new Subscriber();

    // injection I
    FictionBook bookI = new FictionBook();
    bookI.setHeight(30); // cm
    bookI.setPages(250);
    ab.setBook(bookI); // inject
    System.out.println("injection I " + ab.getBook().toString());

    // injection II
    FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set
    System.out.println("injection II " + ab.getBook().toString());      
}

public static void main(String[] args) {
    CallHiddenImplBook kh = new CallHiddenImplBook();
    kh.doIt();
}
}

如何使用依赖注入有许多不同的方法。可以将它与Singleton等结合起来，但基本上它只是通过在另一个对象内创建对象类型的属性来实现的关联。它的有用性是唯一的，也是唯一的特点，我们应该反复编写的代码总是为我们准备好并做好准备。这就是为什么DI如此紧密地与控制反转（IoC）绑定，这意味着我们的程序将控制传递给另一个正在运行的模块，该模块将bean注入到我们的代码中。（可以被注入的每个对象都可以被签名或被认为是一个Bean。）例如，在Spring中，它是通过创建和初始化ApplicationContext容器来完成的，这对我们来说很有用。我们只需在代码中创建Context并调用初始化Bean。此时注射已自动完成。

我想既然每个人都为DI写过文章，让我问几个问题。。

当您有一个DI配置，其中所有实际实现（而不是接口）都将被注入到一个类中（例如控制器的服务），为什么这不是某种硬编码？如果我想在运行时更改对象怎么办？例如，我的配置已经表明，当我实例化MyController时，为FileLogger注入ILogger。但我可能想注入DatabaseLogger。每次我想更改AClass需要的对象时，我都需要查看两个地方——类本身和配置文件。这是如何让生活更轻松的？如果没有注入Aproperty的AClass，是否更难模拟？回到第一个问题。如果使用new object（）不好，我们为什么要注入实现而不是接口？我想你们很多人都在说我们实际上是在注入接口，但配置要求您指定接口的实现。。不在运行时。。它在编译时是硬编码的。

这是基于@Adam N发布的答案。

为什么PersonService不再需要担心GroupMembershipService？您刚才提到了GroupMembership依赖于多个东西（对象/财产）。如果PService中需要GMService，您应该将其作为属性。不管你是否注射，你都可以模仿它。我唯一希望它被注入的时候是GMService是否有更具体的子类，这在运行时之前你不会知道。然后您需要注入子类。或者如果您想将其用作单例或原型。老实说，配置文件中的所有内容都是硬编码的，包括它将在编译时为类型（接口）注入的子类。

编辑

Jose Maria Arranz对DI的美好评论

DI通过消除确定依赖方向和编写任何粘合代码的任何需要来提高内聚性。

错误。依赖关系的方向是XML形式或注释，依赖关系是以XML代码和注释的形式编写的。XML和注释是源代码。

DI通过使您的所有组件模块化（即可更换）并具有相互定义良好的接口来减少耦合。

错误。您不需要DI框架来构建基于接口的模块化代码。

关于可替换：使用非常简单的.properties存档和Class.forName，您可以定义哪些类可以更改。如果代码的任何类都可以更改，Java不适合您，请使用脚本语言。顺便说一句：不重新编译就不能更改注释。

在我看来，DI框架只有一个原因：锅炉板减少。有了一个做得好的工厂系统，您可以像首选的DI框架一样做得更好、更可控、更可预测，DI框架可以减少代码（XML和注释也是源代码）。问题是这种锅炉板减少在非常简单的情况下是真实的（每个类一个实例以及类似的情况），有时在现实世界中，选择适当的服务对象不像将类映射到单个对象那样容易。

我能想到的最好的类比是手术室中的外科医生和他的助手，在那里，外科医生是主要的人，他的助手在他需要时提供各种手术组件，以便外科医生能够专注于他最擅长的一件事（手术）。如果没有助手，外科医生每次需要时都必须自己取下部件。

简而言之，DI是一种通过向组件提供依赖组件来消除组件获取依赖组件的常见额外责任（负担）的技术。

DI使您更接近单一责任（SR）原则，就像外科医生可以专注于外科手术一样。

何时使用DI：我建议在几乎所有的生产项目（小型/大型）中使用DI，尤其是在不断变化的业务环境中：）

原因：因为您希望代码易于测试、可模拟等，以便快速测试更改并将其推向市场。此外，当你有很多很棒的免费工具/框架来支持你的代码库之旅时，你为什么不这样做呢。

到目前为止，我找到的最好的定义是詹姆斯·肖尔的定义：

“依赖注入”是25美元5美分概念的术语。[...]依赖注入意味着对象的实例变量。[...].

马丁·福勒的一篇文章可能也很有用。

依赖注入基本上是提供对象所需的对象（其依赖项），而不是让它自己构造它们。这是一种非常有用的测试技术，因为它允许对依赖项进行嘲笑或清除。

依赖关系可以通过多种方式注入到对象中（例如构造函数注入或setter注入）。甚至可以使用专门的依赖注入框架（例如Spring）来实现这一点，但它们肯定不是必需的。您不需要这些框架进行依赖注入。显式实例化和传递对象（依赖项）与框架注入一样好。

使依赖注入概念易于理解。让我们以开关按钮为例来切换（打开/关闭）灯泡。

无依赖注入

Switch需要事先知道我连接到哪个灯泡（硬编码依赖项）。所以

开关->永久灯泡//开关直接连接到永久灯泡，测试不容易

Switch(){
PermanentBulb = new Bulb();
PermanentBulb.Toggle();
}

使用依赖注入

开关只知道我需要打开/关闭传递给我的灯泡。所以，

开关->灯泡1或灯泡2或夜灯泡（注入依赖性）

Switch(AnyBulb){ //pass it whichever bulb you like
AnyBulb.Toggle();
}

修改开关和灯泡的James示例：

public class SwitchTest { 
  TestToggleBulb() { 
    MockBulb mockbulb = new MockBulb(); 

    // MockBulb is a subclass of Bulb, so we can 
    // "inject" it here: 
    Switch switch = new Switch(mockBulb); 

    switch.ToggleBulb(); 
    mockBulb.AssertToggleWasCalled(); 
  } 
}

public class Switch { 
  private Bulb myBulb; 

  public Switch() { 
    myBulb = new Bulb(); 
  } 

  public Switch(Bulb useThisBulbInstead) { 
    myBulb = useThisBulbInstead; 
  } 

  public void ToggleBulb() { 
    ... 
    myBulb.Toggle(); 
    ... 
  } 
}`