已经发布了几个关于依赖注入的具体问题,例如何时使用它以及它有什么框架,
什么是依赖注入,何时/为什么应该或不应该使用它?
已经发布了几个关于依赖注入的具体问题,例如何时使用它以及它有什么框架,
什么是依赖注入,何时/为什么应该或不应该使用它?
当前回答
公认的答案是一个好答案——但我想补充一点,DI非常像代码中避免硬编码常量的经典做法。
当您使用诸如数据库名称之类的常量时,您可以将其从代码内部快速移动到某个配置文件,并将包含该值的变量传递到需要它的位置。这样做的原因是,这些常量通常比代码的其他部分更频繁地更改。例如,如果您想在测试数据库中测试代码。
在面向对象编程的世界中,DI与此类似。那里的值而不是常量文字是整个对象-但是将创建它们的代码从类代码中移出的原因是相似的-对象的更改比使用它们的代码更频繁。一个重要的情况是需要进行这样的改变,那就是测试。
其他回答
依赖注入(DI)的全部目的是保持应用程序源代码干净和稳定:
清除依赖项初始化代码无论使用的依赖关系如何稳定
实际上,每个设计模式都将关注点分开,以使将来的更改影响最小的文件。
DI的特定域是依赖配置和初始化的委托。
示例:带有shell脚本的DI
如果您偶尔在Java之外工作,请回想一下源代码在许多脚本语言(Shell、Tcl等,甚至在Python中被误用)中的使用情况。
考虑简单的dependent.sh脚本:
#!/bin/sh
# Dependent
touch "one.txt" "two.txt"
archive_files "one.txt" "two.txt"
脚本是依赖的:它无法单独成功执行(未定义存档文件)。
可以在archive_files_ip.sh实现脚本中定义archive_files(在本例中使用zip):
#!/bin/sh
# Dependency
function archive_files {
zip files.zip "$@"
}
您可以使用一个injector.sh“container”来包装这两个“components”,而不是直接在依赖脚本中源代码化实现脚本:
#!/bin/sh
# Injector
source ./archive_files_zip.sh
source ./dependent.sh
archive_files依赖项刚刚注入到依赖脚本中。
您可能已经注入了使用tar或xz实现archive_files的依赖项。
示例:删除DI
如果dependent.sh脚本直接使用依赖项,则该方法将被称为依赖项查找(与依赖项注入相反):
#!/bin/sh
# Dependent
# dependency look-up
source ./archive_files_zip.sh
touch "one.txt" "two.txt"
archive_files "one.txt" "two.txt"
现在的问题是依赖的“组件”必须自己执行初始化。
“组件”的源代码既不干净也不稳定,因为依赖项初始化中的每一次更改都需要“组件”源代码文件的新版本。
最后一句话
DI并不像Java框架那样被广泛强调和普及。
但这是一种通用的方法,可以解决以下问题:
应用程序开发(单一源代码发布生命周期)应用程序部署(具有独立生命周期的多个目标环境)
仅将配置与依赖项查找一起使用没有帮助,因为每个依赖项的配置参数数量(例如,新的身份验证类型)以及支持的依赖项类型数量(例如新的数据库类型)可能会发生变化。
摘自《扎实的Java开发人员:Java 7和多语言编程的关键技术》一书
DI是IoC的一种特殊形式,因此查找依赖项的过程是不受当前执行代码的直接控制。
在进行技术描述之前,首先用一个真实的例子来形象化它,因为你会发现很多技术知识需要学习依赖注入,但大多数人都无法理解它的核心概念。
在第一张图中,假设你有一家拥有很多单位的汽车工厂。汽车实际上是在装配单元中制造的,但它需要发动机、座椅和车轮。因此,装配单元依赖于这些所有单元,它们是工厂的依赖。
你可以感觉到,现在在这个工厂维护所有的任务太复杂了,因为除了主要任务(在组装单元组装汽车)外,你还必须关注其他单元。现在维护成本很高,而且厂房很大,因此需要额外的租金。
现在,看第二张图。如果你找到一些供应商公司,他们会以比你自己生产成本更低的价格为你提供车轮、座椅和发动机,那么现在你就不需要在工厂里生产了。您现在可以为您的装配单元租用一栋较小的建筑,这将减少您的维护任务,并降低额外的租赁成本。现在你也可以只专注于你的主要任务(汽车组装)。
现在我们可以说,组装汽车的所有依赖都是由供应商注入工厂的。这是一个真实的依赖注入(DI)示例。
现在用技术术语来说,依赖注入是一种技术,一个对象(或静态方法)提供另一个对象的依赖。因此,将创建对象的任务传递给其他人并直接使用依赖关系称为依赖注入。
这将帮助您现在通过技术说明学习DI。这将显示何时使用DI,何时不使用DI。
.
使依赖注入概念易于理解。让我们以开关按钮为例来切换(打开/关闭)灯泡。
无依赖注入
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();
...
}
}`
简单来说,依赖注入(DI)是消除不同对象之间的依赖关系或紧密耦合的方法。依赖注入为每个对象提供一个内聚行为。
DI是国际奥委会春季原则的实施,该原则说“不要打电话给我们,我们会打电话给你”。使用依赖注入程序员不需要使用new关键字创建对象。
对象一旦加载到Spring容器中,我们就可以在需要时重用它们,方法是使用getBean(StringbeanName)方法从Spring容器中获取这些对象。