为什么在服务层和dao层中始终只有单个实现接口？

Question

我已经工作/见过一些Spring-Hibernate Web应用程序项目，这些项目具有与实际服务和dao类一样多的接口。

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

1. Spring可以将实际实现连接为给定类中的依赖项（松耦合）

   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等。但是我仍然没有在孤立的应用程序中拥有如此多的接口背后得到了一个务实的理由。

Answer 1

接口还有更多优点-如代理中那样。如果您的类实现了接口，则默认情况下，AOP将使用JDK动态代理。如果直接使用实现，则必须通过使proxy-target-
class = true来强制使用CGLIB代理。与JDK代理不同，它们需要字节码操作。

在这里阅读更多内容。