spring boot项目，需要写一个接口吗？
工作十年接触过无数大大小小的springboot项目，我发现国内公司的项目喜欢把项目层级弄得很复杂，各种类不管是单一实现还是多实现，先写个接口再说。而我在外企同样是spring boot技术的大型项目，项目的层级结构很简单就4到5层，只要用不到接口的地方绝对不会写，能用实体内绝不用抽象类，孰优孰劣，仁者见仁智者见智。下面是国外大神对项目中使用接口的看法：
翻译：
使用 Spring boot 时，您经常使用服务（使用 注释的 bean @Service）。在 Internet 上的许多示例中，您会看到人们为这些服务创建接口。µ 例如，如果我们正在创建一个待办事项列表应用程序，您可能会创建一个TodoService带有TodoServiceImpl实现的接口。
在这篇博文中，我们将了解为什么我们经常这样做，以及是否有必要。
简短的回答
简短的回答很简单。不，您不需要接口。如果您创建一个服务，您可以命名该类本身TodoService并在您的 bean 中自动装配它。例如：
@Service
public class TodoService {
public List<Todo> findAllTodos() {
// TODO: Implement
return new ArrayList<>();
}
}
@Component
public class TodoFacade {
private TodoService service;
public TodoFacade(TodoService service) {
this.service = service;
}
}
无论您使用字段注入还是构造函数注入，您在此处看到的示例都将起作用。@Autowired
那何必呢？
所以，如果我们不需要它……那为什么我们经常写一个？嗯，第一个原因是一个相当历史的原因。但在我们看之前，我们必须解释注解是如何与 Spring 一起工作的。
如果您使用诸如 之类的注释@Cacheable，您希望返回缓存中的结果。Spring 这样做的方式是为您的 bean 创建一个代理并向这些代理添加必要的逻辑。最初，Spring 使用 JDK 动态代理。这些动态代理只能为接口生成，这就是为什么您必须在过去编写接口的原因。
但是，从十多年前开始，Spring 还支持 CGLIB 代理。这些代理不需要单独的接口。从 Spring 3.2 开始，您甚至不必添加单独的库，因为 CGLIB 包含在 Spring 本身中。
松耦合
第二个原因可能是在两个类之间创建松散耦合。通过使用接口，依赖于您的服务的类不再依赖于它的实现。这使您可以独立使用它们。例如：
public interface TodoService {
List<Todo> findAllTodos();
}
@Service
public class TodoServiceImpl {
public List<Todo> findAllTodos() {
// TODO: Implement
return new ArrayList<>();
}
}
@Component
public class TodoFacade {
private TodoService service;
public TodoFacade(TodoService service) {
this.service = service;
}
}
但是，在这个例子中，我认为TodoFacade和TodoServiceImpl属于一起。在此处添加接口会产生额外的复杂性。就个人而言，我认为不值得。
多种实现
松耦合可能有用的一个原因是如果您有多个实现。例如，假设您有两个 a 的实现TodoService，其中一个从内存中检索待办事项列表，另一个从某处的数据库中检索它。
public interface TodoService {
List<Todo> findAllTodos();
}
@Service
public class InMemoryTodoServiceImpl implements TodoService {
public List<Todo> findAllTodos() {
// TODO: Implement
return new ArrayList<>();
}
}
@Service
public class DatabaseTodoServiceImpl implements TodoService {
public List<Todo> findAllTodos() {
// TODO: Implement
return new ArrayList<>();
}
}
@Component
public class TodoFacade {
private TodoService service;
public TodoFacade(TodoService service) {
this.service = service;
}
}
在这种情况下，松散耦合非常有用，因为您TodoFacade不需要知道待办事项是存储在数据库中还是存储在内存中。那不是门面的责任，而是应用程序配置的责任。
您完成这项工作的方式取决于您要实现的目标。如果您TodoFacade必须调用所有实现，那么您应该注入一个集合：
@Component
public class TodoFacade {
private List<TodoService> services;
public TodoFacade(TodoService services) {
this.services = services;
}
}
如果其中一种实现应在 99% 的情况下使用，而另一种仅在非常特殊的情况下使用，则使用@Primary：
@Primary
@Service
public class DatabaseTodoServiceImpl implements TodoService {
public List<Todo> findAllTodos() {
// TODO: Implement
return new ArrayList<>();
}
}
使用@Primary，你告诉 Spring 容器，只要它必须注入一个TodoService. 如果必须使用另一个，则必须通过使用@Qualifier或注入特定实现本身来显式配置它。就个人而言，我会在一个单独的@Configuration类中执行此操作，因为否则，您会TodoFacade再次使用特定于实现的细节来污染您的。
例如：
@Configuration
public class TodoConfiguration {
@Bean
// Using @Qualifier
public TodoFacade todoFacade(@Qualifier("inMemoryTodoService") TodoService service) {
return new TodoFacade(service);
}
@Bean
// Or by using the specific implementation
public TodoFacade todoFacade(InMemoryTodoService service) {
return new TodoFacade(service);
}
}
控制反转
另一种松散耦合是控制反转或 IoC。对我来说，控制反转在处理多个相互依赖的模块时很有用。例如，假设我们有一个OrderService 和一个CustomerService。客户应该能够删除其个人资料，在这种情况下，应取消所有挂单。如果我们在没有接口的情况下实现它，我们会得到这样的结果：
@Service
public class OrderService {
public void cancelOrdersForCustomer(ID customerId) {
// TODO: implement
}
}
@Service
public class CustomerService {
private OrderService orderService;
public CustomerService(OrderService orderService) {
this.orderService = orderService;
}
public void deleteCustomer(ID customerId) {
orderService.cancelOrdersForCustomer(customerId);
// TODO: implement
}
}
如果我们这样做，事情会很快变糟。您的应用程序中的所有域都将绑定在一起，最终您将得到一个高度耦合的应用程序。
CustomerDeletionListener我们可以创建一个接口，而不是这样做：
public interface CustomerDeletionListener {
void onDeleteCustomer(ID customerId);
}
@Service
public class CustomerService {
private List<CustomerDeletionListener> deletionListeners;
public CustomerService(List<CustomerDeletionListener> deletionListeners) {
this.deletionListeners = deletionListeners;
}
public void deleteCustomer(ID customerId) {
deletionListeners.forEach(listener -> listener.onDeleteCustomer(customerId));
// TODO: implement
}
}
@Service
public class OrderService {
public void cancelOrdersForCustomer(ID customerId) {
// TODO: implement
}
}
@Component
public class OrderCustomerDeletionListener implements CustomerDeletionListener {
private OrderService orderService;
public OrderCustomerDeletionListener(OrderService orderService) {
this.orderService = orderService;
}
@Override
public void onDeleteCustomer(ID customerId) {
orderService.cancelOrdersForCustomer(customerId);
}
}
如果你看一下这个例子，你会看到控制反转在起作用。在第一个示例中，如果我们更改cancelOrdersForCustomer()内的方法OrderService，则CustomerService也必须更改。这意味着它OrderService处于控制之中。
在第二个示例中，OrderService不再受控制。当我们更改cancelOrdersForCustomer()模块时，只有OrderCustomerDeletionListener必须更改，这是订单模块的一部分。这意味着它CustomerService处于控制之中。此外，这两种服务都是松散耦合的，因为其中一个不直接依赖于另一个。
虽然第二种方法确实引入了更多的复杂性（一个新类和一个新接口），但它确实使得两个域都不会与另一个域高度耦合。这使它们更容易重构。此侦听器也可以重构为更受事件驱动的架构。这使得重构为领域驱动的模块化设计或微服务架构变得更加容易。
测试
我想谈的最后一件事是测试。有些人会争辩说您需要一个接口，以便您可以拥有一个虚拟实现（因此，有多个实现）。然而，像 Mockito 这样的模拟库解决了这个问题。
如果您正在编写单元测试，则可以使用MockitoExtension：
@ExtendWith(MockitoExtension.class)
public class TodoFacadeTest {
private TodoFacade facade;
@Mock
private TodoService service;
@BeforeEach
void setUp() {
this.facade = new TodoFacade(service);
}
// TODO: implement tests
}
这种方法允许你在不知道服务做什么的情况下正确地测试外观。通过使用Mockito.when()，您可以控制服务模拟应该返回什么，并且通过使用，Mockito.verify()您可以验证是否调用了特定方法。例如：
@Test
void findAll_shouldUseServicefindAllTodos() {
Todo todo = new Todo();
when(service.findAllTodos()).thenReturn(todo);
assertThat(facade.findAll()).containsOnly(todo);
verify(service).findAllTodos();
}
即使您正在编写需要运行 Spring 容器的集成测试，您也可以使用@MockBean注解来模拟 bean。确保您不扫描包含实际实现的包。
@ExtendWith(SpringExtension.class)
@SpringBootTest(classes = TodoFacade.class)
public class TodoFacadeTest {
@Autowired
private TodoFacade facade;
@MockBean
private TodoService service;
}
所以在大多数情况下，您在测试时不需要接口。
结论
所以，如果你问我是否应该为你的服务使用接口，我的回答是否定的。唯一的例外是，如果您尝试使用控制反转，或者您有多个实现需要处理。
你可能会想，创建一个接口不是更好吗，以防万一？我也会对此说不。首先，我相信“你不需要它”（YAGNI）原则。这意味着您不应该为了“我可能需要它”而在代码中添加额外的复杂性，因为通常情况下您不需要。其次，即使事实证明你确实需要它，也没有问题。大多数 IDE 允许您从现有类中提取接口，并且它将重构所有代码以在眨眼之间使用该接口。
