Question

在我的Spring项目中，我有许多简单的服务来获取数据（只是一个简单的CRUD）。启动该项目的开发人员的设计是为每个服务（如

）创建实现

public interface UserService

然后像

public class UserServiceImpl implements UserService

由于UserService没有更多的实现机会，所以我真的讨厌这些Impl后缀，而且阅读的内容也更多（例如，this article），我意识到有生病的理由

上周，我与一个团队的朋友进行了讨论，我与他分享了我的想法，但他回答的是“基本上您是对的，但Spring喜欢界面并且与之合作比与类合作更好”。

不幸的是，我不是Spring方面的专家，但是我试图寻找一些论据，但我没找到答案，因为他是对的。

在Spring中是否有一些强有力的论点使用这种方法为每个小服务类都提供接口？

Answer 1

我可以从现实世界的项目中得知，如果在没有接口且只有实现类的情况下也可以工作。遵循“您将不需要它”（YAGNI）的原则，如果遵循该规则，则可以简化代码。

当然，您可以编写和重用测试实现，但是您可以对模拟进行相同的操作，例如mockito并覆盖测试用例的实现类的行为。

Answer 2

无论想从哪里获得依赖注入（DI）模式的好处，都需要针对抽象（通常是接口）进行编程。

DI有更多好处，但最具说服力的似乎是它允许进行单元测试。当您想要独立于类的依赖项（接口的生产实现）进行测试时，您的接口将至少再有一个实现（模拟实现）。

也就是说，这并不意味着每个类都必须实现某些接口。代码的某些部分可以紧密地耦合在一起而没有问题。

请注意，是否使用Spring在使用DI /不使用DI决策中不起作用。

Answer 3

我已经浏览了这里的所有答案，但想在代理上添加更多内容

AOP 可以使用 JDK 代理或 CGlib 代理

如果 Class 已经实现了接口，它将使用 JDK 代理（只要你有选择，就首选）。如果 Class 没有实现接口，它将使用 CGlib 代理。

Answer 4

这不是必须的，也可能不是基于意见的，但是您正在添加接口以实现将来的服务灵活性，

尽管您没有看到实际的用法，但是它将允许您在单元/集成测试中使用特定服务的不同实现

您可以添加测试实现而不是当前实现，并在执行测试时使用它代替真实服务（例如，通过使用不同的Spring配置文件）

这可以通过@Simulant指出的模拟来完成

Answer 5

正如其他人所建议的，它实际上取决于用例。尽管Spring和Java通常是从一种冗长的语言开始设计的，其中假定接口可以充当客户端，但是实现类却可以看到，但是如今，尤其是我发现越来越少的冗长的代码。如今借助Spring Boot和类似lombok的库。

因此，创建服务，DAO的接口不是强制性的，但是如果您正在相当中等的代码库上工作，则有多个开发人员以及可能在应用程序外部使用这些API的客户端，则它是首选方法。但是，如果您正在从事小型项目或概念验证项目，则也可以在一个Java类上创建一个CRUD应用程序。

Answer 6

目前完全不需要，微服务或迷你代码库很受欢迎。因此，通常情况下，在Rest api后端中，您实际上没有机会对某些接口进行服务器实现。在这种情况下，使用@Serivice进行具体的类就足够了。