CODEWITHSUNDEEP
javanaming-conventionsservice-layer
user1019830
user1019830

Reputation:

Conventions for naming service classes

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:

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

Upvotes: 12

Views: 27898

Answers (1)

Mihail
Mihail

Reputation: 243

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:

Upvotes: 6

Related Questions