java - 你能给我一个没有框架的依赖注入(inject)的例子吗？

Question

我想降低两个组件之间的耦合度，于是想到了依赖注入(inject)，但是一直以来，我都是使用Spring来实现的。但是现在，我在一个不适合使用这个框架的项目中工作(它太重了)。

那么你能给我一个例子来为我自己实现依赖注入(inject)吗？

Answer 1

Dependency Injection是一种无需框架支持即可轻松使用的模式。有些人甚至更喜欢没有框架支持的它，但至少，框架是否真的有益取决于 way you use such framework以及您正在构建/维护的应用程序的类型和大小。

依赖注入(inject)就是简单地将依赖从外部注入(inject)到组件中。最常见和推荐的方法是通过构造函数注入(inject)。这意味着一个类应该将其所有依赖项指定为构造函数参数。

你应该总是设计你的代码，就好像根本没有 DI 框架一样；您的应用程序代码应该忽略此类框架的存在。这意味着你不应该用特定于框架的属性来装饰你的代码。它们会污染您的代码并导致供应商锁定。如果您使用的 DI 库需要使用属性，请切换到不同的库。

依赖注入(inject)的使用将在整个应用程序中“冒泡”。这意味着应用依赖注入(inject)模式的类会将创建其依赖项的责任移到调用堆栈中。这意味着该类的使用者现在负责创建其依赖项。但是由于该消费者也应该应用依赖注入(inject)，这意味着它再次推高了创建依赖关系的责任。当所有类都应用依赖注入(inject)模式时，这意味着需要在应用程序的单个位置创建完整的对象图。这实际上是一件好事。这个地方叫做composition root .

同样，您不需要使用 DI 库(又名 IoC 容器)，您的应用程序代码绝对不应依赖于它。您应该应用依赖注入(inject)模式(和 SOLID 原则)来使您的应用程序可维护。 DI 库可用于使您的组合根可维护，但只有在它使组合根更易于维护时才应使用它。不使用 DI 库可为您提供对创建对象图的完整编译时支持。使用 DI 库会让你失去这种编译时支持，所以使用它的好处应该大于失去编译时支持的坏处。此外，您需要确保可以在应用程序启动期间或至少在测试套件中验证对象图的构建。如果您的 DI 容器使这变得困难甚至不可能，那么切换您的库或手动构建您的对象图可能是更好的选择。