已经发布了几个关于依赖注入的具体问题，例如何时使用它以及它有什么框架，
什么是依赖注入，何时/为什么应该或不应该使用它？
当前回答
例如，我们有两类客户机和服务。客户端将使用服务
public class Service {
public void doSomeThingInService() {
// ...
}
}
无依赖注入
方式1）
public class Client {
public void doSomeThingInClient() {
Service service = new Service();
service.doSomeThingInService();
}
}
方式2）
public class Client {
Service service = new Service();
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
方式3）
public class Client {
Service service;
public Client() {
service = new Service();
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
1） 2）3）使用
Client client = new Client();
client.doSomeThingInService();
优势
易于理解的
缺点
难以测试客户端类当我们更改Service构造函数时，我们需要在所有位置更改代码createService对象
使用依赖注入
方式1）构造函数注入
public class Client {
Service service;
Client(Service service) {
this.service = service;
}
// Example Client has 2 dependency
// Client(Service service, IDatabas database) {
// this.service = service;
// this.database = database;
// }
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();
方式2）沉淀剂注入
public class Client {
Service service;
public void setService(Service service) {
this.service = service;
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();
方式3）接口注入
检查https://en.wikipedia.org/wiki/Dependency_injection
===
现在，这段代码已经遵循了依赖注入，测试客户端类更容易。然而，我们仍然多次使用新的Service（），并且在更改Service构造函数时效果不佳。为了防止这种情况，我们可以使用DI注射器1） 简单手动喷油器
public class Injector {
public static Service provideService(){
return new Service();
}
public static IDatabase provideDatatBase(){
return new SqliteDatabase();
}
public static ObjectA provideObjectA(){
return new ObjectA(provideService(...));
}
}
使用
Service service = Injector.provideService();
2） 使用库：适用于Android dagger2
优势
使测试更容易更改服务时，只需在Injector类中更改如果您使用使用构造函数注入，当您查看Client的构造函数时，您将看到Client类有多少依赖项
缺点
如果使用构造函数注入，则在创建客户端时创建服务对象，有时我们在客户端类中使用函数而不使用服务，因此创建的服务被浪费
依赖注入定义
https://en.wikipedia.org/wiki/Dependency_injection
依赖项是可以使用的对象（服务）注入是将依赖项（Service）传递给将使用它的依赖对象（Client）
其他回答
依赖注入（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框架那样被广泛强调和普及。
但这是一种通用的方法，可以解决以下问题：
应用程序开发（单一源代码发布生命周期）应用程序部署（具有独立生命周期的多个目标环境）
仅将配置与依赖项查找一起使用没有帮助，因为每个依赖项的配置参数数量（例如，新的身份验证类型）以及支持的依赖项类型数量（例如新的数据库类型）可能会发生变化。
例如，我们有两类客户机和服务。客户端将使用服务
public class Service {
public void doSomeThingInService() {
// ...
}
}
无依赖注入
方式1）
public class Client {
public void doSomeThingInClient() {
Service service = new Service();
service.doSomeThingInService();
}
}
方式2）
public class Client {
Service service = new Service();
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
方式3）
public class Client {
Service service;
public Client() {
service = new Service();
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
1） 2）3）使用
Client client = new Client();
client.doSomeThingInService();
优势
易于理解的
缺点
难以测试客户端类当我们更改Service构造函数时，我们需要在所有位置更改代码createService对象
使用依赖注入
方式1）构造函数注入
public class Client {
Service service;
Client(Service service) {
this.service = service;
}
// Example Client has 2 dependency
// Client(Service service, IDatabas database) {
// this.service = service;
// this.database = database;
// }
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();
方式2）沉淀剂注入
public class Client {
Service service;
public void setService(Service service) {
this.service = service;
}
public void doSomeThingInClient() {
service.doSomeThingInService();
}
}
使用
Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();
方式3）接口注入
检查https://en.wikipedia.org/wiki/Dependency_injection
===
现在，这段代码已经遵循了依赖注入，测试客户端类更容易。然而，我们仍然多次使用新的Service（），并且在更改Service构造函数时效果不佳。为了防止这种情况，我们可以使用DI注射器1） 简单手动喷油器
public class Injector {
public static Service provideService(){
return new Service();
}
public static IDatabase provideDatatBase(){
return new SqliteDatabase();
}
public static ObjectA provideObjectA(){
return new ObjectA(provideService(...));
}
}
使用
Service service = Injector.provideService();
2） 使用库：适用于Android dagger2
优势
使测试更容易更改服务时，只需在Injector类中更改如果您使用使用构造函数注入，当您查看Client的构造函数时，您将看到Client类有多少依赖项
缺点
如果使用构造函数注入，则在创建客户端时创建服务对象，有时我们在客户端类中使用函数而不使用服务，因此创建的服务被浪费
依赖注入定义
https://en.wikipedia.org/wiki/Dependency_injection
依赖项是可以使用的对象（服务）注入是将依赖项（Service）传递给将使用它的依赖对象（Client）
来自Christoffer Noring，Pablo Deeleman的书《学习角度-第二版》：
“随着我们的应用程序的增长和发展，我们的每一个代码实体都将在内部需要其他对象的实例，在软件工程领域中，这些对象被称为依赖关系。将这些依赖关系传递给依赖客户端的动作被称为注入，它还需要另一个代码主体（称为注入器）的参与。注入器将负责用于实例化和引导所需依赖项的功能，以便它们从成功注入客户端的那一刻起就可以使用。这一点非常重要，因为客户机不知道如何实例化自己的依赖关系，只知道为了使用它们而实现的接口。"
发件人：Anton Moiseev。《字体角度发展，第二版》一书：
“简而言之，DI帮助您以松散耦合的方式编写代码，并使代码更易于测试和重用。”
在进行技术描述之前，首先用一个真实的例子来形象化它，因为你会发现很多技术知识需要学习依赖注入，但大多数人都无法理解它的核心概念。
在第一张图中，假设你有一家拥有很多单位的汽车工厂。汽车实际上是在装配单元中制造的，但它需要发动机、座椅和车轮。因此，装配单元依赖于这些所有单元，它们是工厂的依赖。
你可以感觉到，现在在这个工厂维护所有的任务太复杂了，因为除了主要任务（在组装单元组装汽车）外，你还必须关注其他单元。现在维护成本很高，而且厂房很大，因此需要额外的租金。
现在，看第二张图。如果你找到一些供应商公司，他们会以比你自己生产成本更低的价格为你提供车轮、座椅和发动机，那么现在你就不需要在工厂里生产了。您现在可以为您的装配单元租用一栋较小的建筑，这将减少您的维护任务，并降低额外的租赁成本。现在你也可以只专注于你的主要任务（汽车组装）。
现在我们可以说，组装汽车的所有依赖都是由供应商注入工厂的。这是一个真实的依赖注入（DI）示例。
现在用技术术语来说，依赖注入是一种技术，一个对象（或静态方法）提供另一个对象的依赖。因此，将创建对象的任务传递给其他人并直接使用依赖关系称为依赖注入。
这将帮助您现在通过技术说明学习DI。这将显示何时使用DI，何时不使用DI。
.
让我们想象一下，你想去钓鱼：
没有依赖注入，你需要自己处理所有的事情。你需要找一艘船，买一根鱼竿，寻找诱饵等等。当然，这是可能的，但这给你带来了很多责任。在软件方面，这意味着你必须对所有这些东西进行查找。通过依赖注入，其他人负责所有准备工作，并为您提供所需的设备。你将收到（“被注射”）船、鱼竿和鱼饵——所有这些都准备好使用。
