为仅单一实现的Spring服务定义接口是否值得？

你提到的这种“为每个服务定义接口，即便只有单一实现”的做法，即便在Mockito能直接mock类的今天，依然有不少值得保留的实际价值：

先看你给出的示例代码：

public interface FooService {
  Foo getFoo(long id);

  Iterable<Foo> findAllFoos();

  void deleteFoo(long id);
}

@Service
@Transactional
public class FooServiceImpl implements FooService {
    // method implementations omitted
}

以下是继续使用接口的核心理由：

• 依赖倒置与扩展性：接口定义了服务的契约，依赖该服务的代码只面向接口编程，而非具体实现。哪天需要替换实现（比如新增一个带缓存的CachedFooServiceImpl，或者切换到另一种数据存储实现），不需要修改所有依赖方的代码，直接替换Bean即可，完全符合SOLID的依赖倒置原则。

• 清晰的职责边界：接口能明确划分服务对外暴露的能力，把实现细节隐藏在实现类中。其他开发者只需查看接口就能快速理解服务的功能，不用在复杂的实现类里找有用信息，大幅提升代码可读性。

• 测试的便利性：虽然Mockito可以mock类，但mock接口更灵活——不用担心实现类中的final方法、私有逻辑或者复杂构造函数带来的mock障碍。而且接口mock只需要关注契约方法，测试逻辑更简洁，也避免了因为实现类变更导致测试用例需要修改的情况。

• Spring AOP的兼容性：Spring默认使用JDK动态代理（基于接口），如果没有接口则会切换到CGLIB代理。JDK代理在性能和稳定性上更有优势，也不会出现CGLIB代理final方法失效、子类继承冲突等问题。

• 团队协作的契约标准：接口可以作为团队内部的API规范，配合JavaDoc能清晰定义每个方法的行为、参数和返回值，确保所有开发者遵循统一的交互标准，减少沟通成本。

当然，如果你的服务是极其简单的内部工具类，且能100%确定永远不会有其他实现，也可以选择不定义接口。但从长远维护和代码演进的角度看，定义接口的成本极低，却能为未来的扩展和维护埋下伏笔。

内容的提问来源于stack exchange，提问作者Dónal