Do Service Layers Need Interfaces? A Critical Discussion on Spring‑Based Projects

When a project uses a dependency‑injection framework such as Spring, the necessity of defining interfaces for Service layers is questioned. The author argues that interfaces are often unnecessary because Spring can inject concrete classes directly.

Reasons Not to Use Interfaces

The three usual reasons for adding interfaces—enabling top‑level code before implementation, supporting Spring AOP proxying, and allowing multiple implementations—are examined and found unconvincing. Without interfaces, developers can still write controller code, use CGLIB for AOP, and rarely need multiple Service implementations.

Project Structure and Interface Implementation

Typical layered architecture (Controller → Service → Dao) is presented, followed by two alternative structures for handling multiple implementations: (1) adding a new package inside Service with separate implementations, and (2) creating an entirely new Service module. The first approach is simpler, while the second offers clearer modular separation.

To combine their advantages, the author suggests extracting the interface and its implementations into independent modules (Service, ServiceImpl, ServiceImpl2) and toggling the desired implementation via build or dependency configuration, allowing identical package structures and minimal configuration changes.

Disadvantages of Not Using Interfaces

Not using interfaces can hinder multi‑implementation scenarios because IDEs cannot generate code from a contract, nor provide compile‑time checks for missing methods. Copy‑pasting code to create new implementations is a less elegant workaround.

Summary

The article concludes that interfaces are unnecessary for most Service layers in Spring projects unless multiple implementations are required; otherwise, developers can simplify the codebase by omitting them.