我在松耦合方面发现了一个有趣的例子：

来源：了解依赖注入

任何应用程序都由许多对象组成，这些对象相互协作以执行一些有用的任务。传统上，每个对象都负责获取自己对与其协作的依赖对象（依赖关系）的引用。这导致了高度耦合的类和难以测试的代码。

例如，考虑Car对象。

汽车依靠轮子、发动机、燃料、电池等运转。传统上，我们定义此类依赖对象的品牌以及Car对象的定义。

无依赖注入（DI）：

class Car{
  private Wheel wh = new NepaliRubberWheel();
  private Battery bt = new ExcideBattery();

  //The rest
}

在这里，Car对象负责创建从属对象。

如果我们希望在初始NepaliRubberWheel（）穿孔后更改其从属对象的类型（例如Wheel），该怎么办？我们需要重新创建Car对象及其新的依赖项，例如ChineseRubberWheel（），但只有Car制造商才能做到这一点。

那么依赖注入为我们做了什么。。。？

当使用依赖注入时，对象在运行时而不是编译时（汽车制造时）被赋予依赖性。因此，我们现在可以随时更改轮子。在这里，相关性（轮子）可以在运行时注入Car。

使用依赖注入后：

这里，我们在运行时注入依赖项（Wheel和Battery）。因此有了这个词：依赖注入。我们通常依赖于Spring、Guice、Weld等DI框架来创建依赖关系并在需要时注入。

class Car{
  private Wheel wh; // Inject an Instance of Wheel (dependency of car) at runtime
  private Battery bt; // Inject an Instance of Battery (dependency of car) at runtime
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}

其优点是：

分离对象的创建（换句话说，将使用与对象的创建分开）能够替换依赖项（例如：车轮、电池），而不改变使用它的类（汽车）促进“代码到接口而不是实现”原则在测试期间创建和使用模拟依赖关系的能力（如果我们想在测试期间使用模拟轮而不是真实实例，我们可以创建模拟轮对象并让DI框架注入Car）

针对5岁儿童的依赖注入。

当你自己去把冰箱里的东西拿出来时，你可能会引起问题。你可能会让门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。你甚至可能在寻找我们甚至没有或已经过期的东西。

你应该做的是陈述一个需要，“我需要午餐时喝点东西”，然后我们会确保你坐下吃饭时有东西。

依赖注入（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。此时注射已自动完成。

让我们用Car和Engine类来尝试一个简单的例子，任何汽车都需要一个引擎，至少目前是这样。下面是没有依赖注入的代码的外观。

public class Car
{
    public Car()
    {
        GasEngine engine = new GasEngine();
        engine.Start();
    }
}

public class GasEngine
{
    public void Start()
    {
        Console.WriteLine("I use gas as my fuel!");
    }
}

为了实例化Car类，我们将使用以下代码：

Car car = new Car();

这个代码的问题是我们与GasEngine紧密耦合，如果我们决定将其更改为ElectricityEngine，那么我们需要重写Car类。应用程序越大，我们必须添加和使用新型引擎的问题和麻烦就越多。

换句话说，这种方法是我们的高级Car类依赖于低级GasEngine类，这违反了SOLID的依赖反转原理（DIP）。DIP建议我们应该依赖抽象，而不是具体的类。因此，为了满足这一点，我们引入了IEngine接口并重写如下代码：

    public interface IEngine
    {
        void Start();
    }

    public class GasEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I use gas as my fuel!");
        }
    }

    public class ElectricityEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I am electrocar");
        }
    }

    public class Car
    {
        private readonly IEngine _engine;
        public Car(IEngine engine)
        {
            _engine = engine;
        }

        public void Run()
        {
            _engine.Start();
        }
    }

现在我们的Car类只依赖于IEngine接口，而不是引擎的特定实现。现在，唯一的诀窍是我们如何创建Car的实例，并给它一个实际的具体Engine类，比如GasEngine或ElectricityEngine。这就是依赖注入的作用。

   Car gasCar = new Car(new GasEngine());
   gasCar.Run();
   Car electroCar = new Car(new ElectricityEngine());
   electroCar.Run();

在这里，我们基本上将依赖项（Engine实例）注入（传递）到Car构造函数。因此，现在我们的类在对象及其依赖关系之间具有松散的耦合，我们可以在不更改Car类的情况下轻松添加新类型的引擎。

依赖注入的主要好处是类之间的耦合更加松散，因为它们没有硬编码的依赖关系。这遵循了上面提到的依赖反转原则。类不是引用特定的实现，而是请求抽象（通常是接口），这些抽象是在构造类时提供给它们的。

所以最终依赖注入只是一种技术实现对象及其依赖关系之间的松散耦合。而不是直接实例化类需要的依赖项为了执行其操作，向类提供依赖项（通常）通过构造函数注入。

此外，当我们有很多依赖项时，使用控制反转（IoC）容器是非常好的做法，我们可以告诉哪些接口应该映射到我们所有依赖项的具体实现，我们可以让它在构建对象时为我们解决这些依赖项。例如，我们可以在IoC容器的映射中指定IEngine依赖项应映射到GasEngine类，当我们向IoC容器请求Car类的实例时，它将自动构建Car类，并传入GasEngine依赖项。

更新：最近观看了Julie Lerman关于EF Core的课程，也喜欢她对DI的简短定义。

依赖注入是一种允许应用程序注入的模式对象，而无需强制类来负责这些对象。它允许您的代码更松散的耦合，并且实体框架核心插入到该框架中服务体系。

公认的答案是一个好答案——但我想补充一点，DI非常像代码中避免硬编码常量的经典做法。

当您使用诸如数据库名称之类的常量时，您可以将其从代码内部快速移动到某个配置文件，并将包含该值的变量传递到需要它的位置。这样做的原因是，这些常量通常比代码的其他部分更频繁地更改。例如，如果您想在测试数据库中测试代码。

在面向对象编程的世界中，DI与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变，那就是测试。

摘自《扎实的Java开发人员：Java 7和多语言编程的关键技术》一书

DI是IoC的一种特殊形式，因此查找依赖项的过程是不受当前执行代码的直接控制。