我很好奇一般的依赖倒置原理，以及它是否应该严格执行。混凝土类注入被认为是不好的做法
我知道使用接口进行注入通常会促进松散耦合，这具有积极影响。
但是，有些类型的类最有可能总是只有一个实现，并且可能不会随着时间而改变。我真的很怀疑是否有一个界面支持每个对象，例如FooService，带有FooServiceImpl。
我处于困境中，因为我认为具体的课堂注射通常被许多人所忽视。
tl; dr
即使某些类不可能发生更改，依赖注入总是只能用接口完成，因此，通过接口支持它似乎会增加不必要的复杂性？
你是对的，只要有多个实现，依赖注入就开始有用。我明白你只有一个具体的实现，但如果你遵循最佳实践，你会想要单元测试每个类。如果一个BarService依赖于你的FooService，你将编写一个单元测试BarServiceTest，它依赖于FooService的假实现（模拟或类似的）。
换句话说，只要你编写单元测试你的应用程序，你最终会得到你的服务的实现：真正的在运行时使用的，假的用于单元测试（或单个实现，但配置不同在上下文中）。
只是几件事情。
Dependency injection (DI)！== Inversion of Control (IoC)！== Dependency Inversion Principle (DIP)
我不记得上比this
第二个方面其他的话题更好的（即相同的简短和解释性）读取语言和（或）工具依赖。当然，我不能说所有的语言和他们的工具 - 堆栈可用，但可能是一些测试倍增接口将是一个更好的方法比生成一个类作为被嘲笑的类的子类更好。
所以对于
我个人的（主观）的答案应该依赖注入总是用接口来完成而已，甚至 当某些类是不可能通过 界面更改，因此，支持它似乎增加不需要的复杂性？
绝对是'no'由于类结构中不需要的复杂性。此外，执行DI通常意味着使用某种依赖注入容器来管理依赖关系，这意味着需要额外的配置工作。
就我个人而言，只有当我确实明确地具有这样的意图时，才会通过意图介绍接口。代码中出现的所有其他接口只是在开发/重构过程中提取（换句话说，只有当我或我的代码满足这些需求时，才会创建抽象）。