Java 使用没有接口的SpringDI正确吗

我正在使用spring依赖项注入，在这里我可以通过一些外部xml文件注入对象依赖项

我的问题是:

在不使用接口的情况下使用spring DI可以吗？

因为使用DI，我们希望实现一件事：

如果一个类被具有相同方法但不同定义的其他类替换，那么我们不需要在引用该类的代码中进行任何更改

如果我使用接口，因为接口可以指向实现该接口的任何类，那么这很好，但是如果我通过DI直接注入类对象，那么DI就没有任何意义，因为在这种情况下，如果类被替换，我还必须在引用它的地方更改代码

如果有什么不对劲，请让我纠正

假设我有

Class Datasource{

    String url;
    String user;
    String database;

}

现在我正在使用它，没有DI

Class Abc{

     Datasource datasource = new Datasource();
}

这有什么问题？如果我使用DI，我能得到什么好处

---

获取单例对象是DI的唯一目标吗？

依赖项注入与接口、类、枚举或。。。是关于

想象一下下面的课程

public class PersonService {

    private PersonRepository repository = new PersonRepository();
}

显然这没有什么错。但是，如果

PersonRepository

需要其他依赖项，如果它将另一个复杂对象作为构造参数，该怎么办。突然间，

PersonService

被如何构造对象及其所有依赖项的逻辑所拖累。而它只想使用对象

public class PersonService {

    private PersonRepository repository;

    public PersonService() {
         InitialContext ctx = new InitialContext();
         repository = ctx.lookup("java:comp/env/repositories/person");
    }
}

上面的代码与JNDI绑定，您将如何（轻松地）测试它？当然，您可以构建自己的模拟JNDI服务，并使用构建的或模拟的存储库对其进行预配置，但这相当麻烦

 public class PersonService {

      private final PersonRepository repository;
      public PersonService(PersonRepository repository) {
          this.repository=repository;
      }
 }

以上内容基本上使一切都成为可能，

PersonService

上没有关于如何构建

PersonRepository

的问题，这只是一个简单的问题，它来自哪里并不重要。它是实际的类还是（基于类的）代理，这并不重要

---

因此，依赖注入，您希望将要使用的

PersonRepository

交给

PersonService

它应该与它的来源、构造方式或它是否是实际对象的代理无关。它只需要一个

PersonRepository

这不是您希望通过依赖项注入实现的目标。您希望将配置相关objct（即使用存储库的服务）的控制外部化。DI与替换依赖项无关。无论是否使用接口，依赖注入都可以并且将起作用。我们在XMLs中没有提到接口，而是提到类。在实时应用程序中，类很少被其他类替换或交换。如果DI不是“如果一个类正在被重新…”@M.Deinum如果DI不是“如果一个类…”那么DI的好处是什么，为什么我要将控制外部化？因为您可能需要重用对象（单例）或提供实际对象的代理。你不知道；如果在另一个对象中实例化对象，则无法获得所有这些。然而，这并不是你不想到处构造对象的主要好处。想象一下需要一个数据源，你可能想配置它一次，让其他类使用它，你不想让每个类都设置一个

数据源
@M.Deinum不明白你的意思，请参阅我的问题更新谢谢你的回答，这是有道理的，如果对象创建是一个有点复杂的任务，那么应该使用DI，但我见过许多项目，在这些项目中，对象创建非常简单，比如new Abc（），但人们仍然使用DI来注入Abc。这不是简单，而是责任。。。
PersonService
不负责构造所需的引用对象。把它们交给那个物体就行了。