首先，我是入门级程序员；实际上，我正在整个夏季完成AS学位，并完成了最终的顶峰项目。在我的新工作中，当我没有什么项目要做（他们正在等待团队中有更多新员工的到来）时，我在等待的过程中会得到一些可供阅读和学习的书籍-一些教科书，其他与其说是“代码完成”，不如说是。看完这些书之后，我转向互联网学习尽可能多的知识，并开始学习SOLID和DI（我们谈论了Liskov的替代原理，但没有其他SOLID想法）。因此，据我所知，我坐下来做得更好，并且开始编写一些代码以手工使用DI（开发计算机上没有DI框架）。
正如我所做的那样，我发现它感觉很熟悉……而且似乎很像我过去使用多态抽象类的组合所做的工作。我在这里想念大图吗？关于DI（至少是手工），还有其他一些东西吗？我了解在某些DI框架的代码中不包含配置的可能性，这些优点在无需重新编译的情况下就具有很大的好处，但是在手工操作时，我不确定它是否与上述内容有所不同...对此有一些了解将非常有帮助！
Answers:
DI的基本思想只是将依赖项推入对象中，而不是让它们从外部拉出依赖项。先前也称为“控制反转”。这使人们可以更好地控制依赖关系，并且-最后但并非最不重要-编写易于进行单元测试的代码。
DI框架仅基于此思想，并且（部分）自动将连接对象依赖项的繁琐部分自动化。否则，这可能需要较大的项目中的大量代码。
为了定义依赖关系，除了外部配置文件之外，现在还可以使用代码注释，例如以Java和C＃之类的语言。这可能会带来两全其美的效果：以声明式的方式连接依赖关系，但是恰好在逻辑上所属的代码本身内。对我来说，无需重新编译即可更改依赖项的可能性并不那么有价值，因为在现实生活中很少这样做（除了一些特殊情况），但引入了依赖项与代码中定义的类和对象之间的人为分离。
回到您的标题问题，DI不能替代构图或多态性。毕竟，这两个使它成为可能。
我读过的关于该主题的最佳文章是James Shore的。作为抽象和多态性的一部分，我从事“ DI手工制作 ” 已有很长时间了。所以，当我坐进专业的世界，我一直听到被抛出这个词我周围有什么之间我想到了一个词断开大应该意味着什么，它实际上是指：
“依赖注入”是5美分概念的25美元术语。
那是从肖尔（Shor）的帖子，它为我清除了所有内容。例如：
给定
class Engine {public abstract void start()}
class V8 extends Engine {...}
class V6 extends Engine {...}
而不是写：
class Car
{
private Engine engine;
public Car()
{
this.engine = new V6();
}
public void start()
{
this.engine.start();
}
}
您可以这样写：
class Car
{
private Engine engine;
public Car(Engine a)
{
this.engine = a;
}
public void start()
{
this.engine.start();
}
}
...
Car F = new Car(new V8());
并且这避免了Car实例必须处理特定的Engine细节。汽车只需要一个引擎，只要实现基本的引擎功能，它就不在乎哪个。也就是说，您的Car类不依赖于特定的实现依赖项；它可能会在运行时“注入”到其他地方。
这个特定的Car示例使用DI的子类型，称为“构造函数注入”，这仅表示依赖项已作为构造函数参数移交。您也可以使用setEngine(Engine a)“ Setter注入”方法，依此类推，但是这些子类型对我来说似乎很古怪。
不过，还有一点，许多DI框架提供了样板，可以将一堆这些更抽象地引用的东西相互连接起来。
而已。