java - 为什么服务层和 dao 层总是有单一的实现接口(interface)？

Question

我已经工作过/见过一些 spring-hibernate Web 应用程序项目，它们的接口(interface)与实际的服务和 dao 类一样多。

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

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

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

所以，我的问题是为什么我们仍然需要接口(interface)，然后有像 *ServiceImpl 和 *DaoImpl 类这样的单一实现，并且不必要地增加了我们的代码库大小。模拟具体类是否存在一些我不知道的问题。

每当我和我的队友讨论这个问题时，我得到的唯一答案是基于接口(interface)实现服务和 dao 类是每个人都遵循的设计——他们提到了 Spring 最佳实践、OOP、DDD 等。但我仍然在一个独立的应用程序中拥有如此多的接口(interface)，不要从实际出发。

Answer 1

接口(interface)有更多的优势——就像代理一样。如果你的类实现了一个接口(interface)，JDK 动态代理将默认用于 AOP。如果您直接使用实现，您将被迫通过设置 proxy-target-class=true 来使用 CGLIB 代理。与 JDK 代理不同，这些需要字节码操作。

阅读 here了解更多信息。

阅读 what reasons are there to use interfaces (Java EE or Spring and JPA) 上的另一个讨论了解更多信息。