Conventions for naming service classes

Question

I'm developing a simple Java application for doing CRUD operations against a database through a RESTful API. It's divided into three layers: the controller layer, the service layer and the DAO layer.

Normally, I create a service interface for each domain object. Say, User:

public interface UserService {
  List<User> getAll();
  User create(User entity);
  void update(User entity) throws Exception;
  void delete(Long id) throws Exception;
}

Then I implement that interface in a service class:

public class UserServiceImpl implements UserService { ... }

This approach I think has several drawbacks:

• It forces me to name the concrete class something other than UserService, although I only have one concrete implementation of that interface
• All the different services do not implement the same interface
• There's an explosion of interfaces that all behave the same way

Another approach

I'd create an interface that all services would implement:

public interface CrudService<T> {
  List<T> getAll();
  T create(T entity);
  void update(T entity) throws Exception;
  void delete(Long id) throws Exception;
}

So I choose the name CrudService to convey the functionality provided by that interface. Then, I have a concrete service class implementing that interface with a type parameter User:

public class UserService implements CrudService<User> { ... }

This way my services have names like UserService which I think is more clean and readable.

Questions

• What's the convention for naming service classes? What do you usually do?
• Should I name a concrete class UserService when that sounds like an interface?
• What about the Impl suffix? Does it convey anything about the implementation?

Colucci

Do you really need an interface if you know that you will have only one concrete implemention or is it just to follow what some people blindly call 'best practices' ? Have a look at this interesting article: adam-bien.com/roller/abien/entry/service_s_new_serviceimpl_why – Desensitize

@OlivierM. Excactly. Most of the time I create an interface before implementing the actual class just for the sake of using interfaces, because someone told me "using interfaces everywhere is good". Well I don't actually want that interface bloating my application given only one implementation which is likely never going to change. Here, there's only need for a single interface to tie together the services. – Colucci

Probably, in most situations, you don't need interfaces. If you are using EJB, for example, just annotate your bean with @Stateless, @Stateful or @Singleton. But sometimes, interfaces are needed. With EJB, if you would like a remote service, you need an interface annotated with @Remote. But do not let the exception becomes the rule. When a remote access is needed, create an interface with only the methods you would like to expose and make your bean implement it. – Overissue

Note that when using a modern IoC framework like Spring (which is almost always the case for "real" webapp development nowadays), it would still be highly beneficial (not to say mandatory) to declare interfaces for your services, as it makes everything (the use of framework-specific syntax, unit testing in general etc.) a whole lot simpler. – Lucier

@OlivierMasseau The "article" you cited is a poorly written opinion piece to address this issue IMHO :-) – Robber

@OlivierMasseau for "Do you really need an interface if you know that you will have only one concrete implemention" I can agree to this. But in modern web apps chances are there is always a cache layer implementation along with default service implementation. So chances are you start with at least two service implementations. – Robber

UserService userService = new DefaultUserService; ... UserService cachedUserService = new CachedUserService; – Robber

Answer 1

To answer your questions:

• There is no "special" convention for naming service classes. They are classes so they should be a noun(s) in singular form in CamelCase: Customer, Company, Employee, UserService, WrapperManager, FileStream, etc.

• Just because UserService sounds like an interface to you it does not mean it is one. You also do not have to name your class UserService if you do not want to. It is up to you in the end.

• Impl sounds ugly and looks noisy. Do not use it. Do not use prefixes or other suffixes either. Use whole words. Remember the basics: classes are objects, so an Apple is an apple, not an App. Moreover, Impl does not convey anything about the implementation (aka business logic.)

For more info, check out the following great answers:

• Interface naming in Java
• Java Interfaces/Implementation naming convention
• Java Interface Naming Conventions

Jeffries

"Impl" is a perfectly reasonable suffix if, for example, you have a service interface with one single implementation during runtime, but potentially multiple implementations to facilitate testing. – Dich