为什么在服务和 dao 层中总是有单一的实现接口？

我工作/看到过一些春季休眠的Web应用程序项目，其接口与实际的服务和dao类一样多。

我一直认为这两个是拥有这些单一实现接口的主要原因：

1. 弹簧可以将实际实现作为给定类中的依赖项（松散耦合）

   public class Person { 
       @Autowired 
       private Address address;
   
       @Autowired 
       private AccountDetail accountDetail;
   
       public Person(Address address, AccountDetail accountDetail) 
       { // constructor
   

2. 在单元测试时，我可以创建模拟类并单独测试类。

   Address mockedAddress = mock(Address);
   AccountDetail mockedAccountDetail = mock(AccountDetail);
   Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
   // unit test follows
   

但是，最近，我意识到：

Spring可以将具体的实现类作为依赖项：

public class Person { 

@Autowired 
private AddressImpl address;

@Autowired 
private AccountDetailImpl accountDetail;

public Person(AddressImpl address, AccountDetailImpl accountDetail) { 
// constructor

像EasyMock这样的模拟框架也可以模拟具体的类。

AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
// unit test follows

此外，根据这次讨论，我认为总结是，在单个应用程序中，界面大多被过度使用，可能是出于惯例或习惯。在我们与其他应用程序接口的情况下，它们通常是最有意义的，例如世界各地的许多应用程序使用的slf4j。在单个应用中，类几乎与接口一样具有抽象性。

所以，我的问题是，为什么我们仍然需要接口，然后有单个实现，如*ServiceImpl和*DaoImpl类，并且不必要地增加我们的代码库大小。在嘲笑具体类时，是否有一些我不知道的问题。

每当我和我的队友讨论这个问题时，我得到的唯一答案是，基于接口实现服务和dao类是每个人都遵循的设计 - 他们提到了弹簧最佳实践，OOP，DDD等。但是我仍然不明白在一个孤立的应用程序中拥有这么多接口背后的实际原因。