混凝土类注射被认为是不良做法

Question

我一般对依赖倒置原则感到好奇，是否应该一直严格执行。

我知道使用接口注入通常会促进松散耦合，这会产生积极的影响。

但是，某些类型的类很可能总是只有一个实现，并且可能不会随着时间的推移而改变。我真的在质疑让界面支持的每个对象，例如FooService，带有FooServiceImpl。

我处于两难境地，因为我认为具体的班级注射通常不受许多人的欢迎。

tl;博士 依赖注入总是应该只使用接口，即使某些类不太可能改变，因此，通过接口支持它似乎会增加不必要的复杂性吗？

Answer 1

你是对的，一旦有多个实现，依赖注入就会开始有用。我知道你只有一个具体的实现，但如果你遵循发展最好的实践，你会想要对每个类进行单元测试。如果BarService依赖于你的FooService，你将编写一个单元测试BarServiceTest，它依赖于伪造的FooService实现（模拟或类似的东西）。

换句话说，只要你编写单元测试你的应用程序，你最终会得到你的服务的实现：在运行时使用的真实的，用于单元测试的假的（或单个实现，但根据具体情况配置）上下文）。

Answer 2

只是几件事。

Dependency injection (DI)！== Inversion of Control (IoC)！== Dependency Inversion Principle (DIP)

我不记得更好（同样简短和解释）阅读this以外的主题

第二个方面是语言和（或）工具相关。当然我不能说所有的语言和他们的工具 - 堆栈可用，但可能是一些测试加倍接口将比生成double作为子类的更好的方法。上课被嘲笑。

所以我的个人（和主观）答案

  

依赖注入总是应该只使用接口，甚至   当某些类不太可能改变时，因此支持它   界面似乎增加了不必要的复杂性？

由于类结构中不必要的复杂性，

绝对是'不'。此外，做DI通常意味着使用某种依赖注入容器来管理依赖关系，这反过来意味着额外的配置工作。

就个人而言，只有当我确实明确地拥有这样的意图时，才会按意图引入接口。代码中出现的所有其他接口只是在开发/重构过程中的提取（换句话说，只有当我或我的代码需要这些时才创建这样的抽象）。