java 命名服务类的约定

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/26648670/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-11-02 10:19:24  来源:igfitidea点击:

Conventions for naming service classes

javanaming-conventionsservice-layer

提问by

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.

我正在开发一个简单的 Java 应用程序,用于通过 RESTful API 对数据库执行 CRUD 操作。它分为三层:控制器层、服务层和DAO层。

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

通常,我为每个域对象创建一个服务接口。说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
  • 它迫使我将具体类命名为 以外的其他名称UserService,尽管我只有该接口的一个具体实现
  • 所有不同的服务都没有实现相同的接口
  • 有大量的接口,它们的行为方式都一样

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 CrudServiceto convey the functionality provided by that interface. Then, I have a concrete service class implementing that interface with a type parameter User:

所以我选择这个名字CrudService来传达该界面提供的功能。然后,我有一个具体的服务类,使用类型参数实现该接口User

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

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

通过这种方式,我的服务具有UserService我认为更清晰易读的名称。

Questions

问题

  • What's the convention for naming service classes? What do you usually do?
  • Should I name a concrete class UserServicewhen that sounds like an interface?
  • What about the Implsuffix? Does it convey anything about the implementation?
  • 命名服务类的约定是什么?你平时做些什么?
  • UserService当听起来像一个接口时,我应该命名一个具体的类吗?
  • 怎么样的Impl后缀?它是否传达了有关实施的任何信息?

回答by Mihail-Florin Popa

To answer your questions:

回答您的问题:

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

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

  • Implsounds 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 Appleis an apple, not an App. Moreover, Impldoes not convey anything about the implementation (aka business logic.)

  • 命名服务类没有“特殊”约定。它们是类,因此它们在CamelCase 中应该是单数形式的名词:, , , , , , 等。CustomerCompanyEmployeeUserServiceWrapperManagerFileStream

  • 仅仅因为UserService听起来像您的界面并不意味着它是一个界面。UserService如果您不想,您也不必为您的班级命名。这最终取决于你。

  • Impl听起来很丑,看起来很吵。不要使用它。也不要使用前缀或其他后缀。使用完整的单词。记住基础知识:类是对象,所以 anApple是一个苹果,而不是一个App. 此外,Impl不传达任何有关实现的信息(也称为业务逻辑。)


For more info, check out the following great answers:


有关更多信息,请查看以下精彩答案: