依赖注入的最佳定义是什么？

Question

每次有人找到我，要求我以概念的方式定义依赖注入，并解释在软件设计中使用DI的真正利弊。我承认我很难解释DI的概念。每次我都需要告诉他们关于单一责任原则、继承的构成等的历史。

任何人都可以帮助我解释开发人员描述DI的最佳方法？

Answer 1

抽象的概念常常用现实世界的类比来更好地解释。这是我要做的类比：

你经营一家三明治店。你做的三明治棒极了，但你对面包本身知之甚少。你只有平淡的白面包。你的工作完全集中在你用来把面包变成三明治的配料上。然而，你的一些顾客确实会更喜欢棕色面包。有些人更喜欢全麦。不管是哪种方式，你都不在乎，只要是同样大小的面包，你就可以做任何美味的三明治。你也不想承担额外的责任，购买几种类型的面包，并保持库存。即使你储备了几种类型的面包，总有一些顾客对面包有着某种异国情调，这是你无法合理预见到的。所以你制定了一个新的规则:顾客自己带面包。你不再自己提供面包了。这是一个双赢的局面:顾客可以买到他们想要的面包，你不必再费心去买你不关心的面包了。毕竟，你是三明治制造者，不是面包师。哦，为了容纳那些不想买自己的面包的顾客，你在隔壁开了第二家商店，卖你原来的白面包。没有自己带面包的顾客只需得到默认的面包，然后到你这里来做一个三明治。

这并不完美，但它突出了一个关键特征:将控制权交给消费者。与生俱来的双赢是，你不再需要获得你自己的依赖，而你的消费者在他们的依赖选择上是不受阻碍的。

Answer 2

对此的简单回答是：

首先，一个类应该有一个明确的责任，并且这个范围之外的所有东西都应该保持在该类之外。尽管如此，依赖注入是指使用来自“第三方”的帮助将其他B类的功能注入到A类中，从而实现关注点的分离，从而帮助A类完成超出其范围的一些操作。

.Net核心是一个很好的例子，您可以给出，因为这个框架使用了大量的依赖注入。通常，要注入的服务位于startup.cs文件中。

当然，学生应该了解一些概念，如多态性、接口和OOP设计原则。

Answer 3

在本质上，这是一个简单的概念。

如果您可以在代码中非常简单地使用“我应该使用什么框架”，也很容易陷入困境。

这是我个人使用的定义：

给定行为X与Y的依赖关系，依赖注入涉及到提供满足Y实例标准的任何Y的工具，即使您没有Y实例。

有些例子可能是Y是文件系统或数据库连接的地方。

像莫克这样的框架允许使用接口定义双重(假装版本的Y)，因此可以在Y的实例中注入，例如Y是数据库连接。

很容易陷入这样的陷阱:认为这纯粹是一个单元测试问题，但对于任何期望更改的代码来说，它都是非常有用的模式，可以说，这是一个很好的实践。