【问题标题】：what reasons are there to use interfaces (Java EE or Spring and JPA)有什么理由使用接口（Java EE 或 Spring 和 JPA）
【发布时间】：2012-01-17 12:49:47
【问题描述】：

大多数 J2EE（Spring 和 JPA）类都设计有接口。 除了继承，这有什么技术原因吗？像动态代理或 AOP 一样，我需要更多关于此的技术细节

前

public interface UserDAO {
   void delete();
   void update();
   void save();
   List<User> get();
}

public class UserDAOImpl implements UserDAO {
   public void delete(){}
   public void update(){}
   public void save(){}
   public List<User> get(){}
}

【问题讨论】：

spring and interfaces 的可能重复项

标签： spring design-patterns jakarta-ee

【解决方案1】：

有 3 个主要原因，IMO：

第一个原因：代理。

如果你向 Spring 询问 UserDAO 类型的 bean，它实际上会返回一个封装了实际 UserDAOImpl 实例的代理。这允许它划分事务、验证安全授权、日志访问、计算统计等。可以在没有接口的情况下完成，但需要字节码操作。

第二个原因：可测试性。

在对使用 UserDAO 的业务服务进行单元测试时，您通常会注入一个模拟 UserDAO 实现。再一次，当 UserDAO 是一个接口时，这更容易做到。使用具体类是可能的，但并非总是如此，而且使用接口仍然更容易

第三个原因：解耦。

通过使用接口，您可以为客户定义 DAO 的真实合约。当然，在具体实现中它需要一个setDataSource() 方法，但客户并不关心这个。他们所需要的只是 DAO 提供的一组数据访问方法。通过分离接口和具体实现，您可以确保客户端不依赖 DAO 的实现细节。

【讨论】：

谢谢。 +1 第一个原因（可以在没有接口的情况下完成，但需要字节码操作）
你的意思是三个都+1，对吧？当您编写接口代码时，单元测试会容易得多。
视情况而定。如果只有一个实现并且您没有创建框架或库，为什么还需要接口。
@James 如今，有了 Mockito 和 Spring 良好的 CGLib 支持，接口不再需要了。但是使用 EasyMock（它不像 Mockito 那样聪明地模拟具体类）具有接口确实很有帮助。
为什么字节码操作被视为不受欢迎的事情？

【解决方案2】：

我看到的接口是合同。例如，一组软件工程师（实施类）可能与公司（接口）有特定的合同。公司可根据项目需要，不定期更换工程师。由于它们遵循相同的合同并遵循相同的规则，因此每次项目需要更改时，切换比从外部引入资源（编写新类）更容易。您只需更改配置即可切换实现类。
接口是干净的，并且是对类实现的规则的单点访问。

链接

【讨论】：

对现有问题的引用，无需进一步讨论，几乎总是应该是接近/重复投票或评论，IMO。
@Dave Newton - 将人们指向正确的方向有时会消耗一些我觉得应该“奖励”的时间。一个赞成票说“这个答案很有用”，并且由那些认为它有用的人选择了哪个 IMO 是可以接受的。
我很乐意让你相信任何你想要的；根据here 和here，不建议使用“仅链接”。
@Dave Newton 感谢您指出这一点。我会记住这一点，但这又是某人的意见:)。无论如何，再次感谢您的宝贵时间。
如果“某人”是指“基本上负责该网站的人”（继续搜索元数据；您会反复找到相同的信息），是的——都是意见。

【解决方案3】：

因为你提到了 Spring 明确的。

Spring AOP 可以在不同的配置中使用。默认使用 java 动态代理 (java.lang.reflect.Proxy)。这只能应用于接口

Spring AOP 默认为 AOP 代理使用标准 J2SE 动态代理。这使得任何接口（或一组接口）都可以被代理。

@见Spring Reference Chapter 7.1.3 AOP Proxies @见Dynamic Proxy Classes

【讨论】：