0

In a typical CRUD application we could have entities such as users, orders, invoices etc.

For the service layer it's a common pattern to create the service interface and its implementation.

  • UserService
  • UserServiceImpl
  • OrderService
  • OrderServiceImpl
  • InvoiceService
  • InvoiceServiceImpl

I know it's a good practice to code in terms of interfaces, but for this particular case where the service implementation most probably won't change, do we really have to create an interface and its implementation with that ugly "Impl" suffix?

It might be that I just have a problem with that naming convention? Is there another way to address the design and creation of the service layer?

This might be a slightly different approach in the naming convention:

  • UserService
  • DefaultUserService
  • OrderService
  • DefaultOrderService
  • InvoiceService
  • DefaultInvoiceService

However, I feel that we are still coding in terms of interfaces "just" for the sake of coding in terms of interfaces in a situation where the implementations most probably won't change.

Carlos Gonzalez
  • 357
  • 1
  • 7
  • 1
    This is not suitable for the Q&A format, but there has been some discussion about this. I recommend you read through this (In case you haven't already): [Java Interfaces Implementation Convention](https://stackoverflow.com/questions/2814805/java-interfaces-implementation-naming-convention), [Program to interface, not the implementation](https://stackoverflow.com/questions/2697783/what-does-program-to-interfaces-not-implementations-mean). Conventions are not set in stone: I've seen prod code from third parties using C/C++/C# conventions in Java. It works for them, so they do they. – Jetto Martínez Feb 26 '22 at 16:29

0 Answers0