Question

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

通常，我为每个域对象创建一个服务接口。说，User：

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

然后我在服务类中实现该接口：

public class UserServiceImpl implements UserService { ... }

我认为这种方法有几个缺点：

它迫使我将具体类命名为UserService以外的其他类，尽管我只有该接口的一个具体实现
所有不同的服务都没有实现相同的界面
界面爆炸，所有界面都表现相同

另一种方法

我创建了一个所有服务都将实现的接口：

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

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

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

这样我的服务的名称就像UserService，我觉得它更干净，更易读。

问题

命名服务类的惯例是什么？你通常做什么？
当听起来像界面时，我应该命名具体的类UserService吗？
Impl后缀怎么样？它是否传达了有关实施的任何内容？

Answer 1

回答你的问题：

命名服务类没有“特殊”约定。它们是类，因此它们应该是 CamelCase ：Customer，Company，Employee中单数形式的名词， UserService，WrapperManager，FileStream等
仅仅因为UserService听起来像是一个接口，它并不意味着它就是一个。如果您不想，也不必为您的班级UserService命名。最后由你决定。
Impl听起来很丑，看起来很吵。不要使用它。不要使用前缀或其他后缀。用整个词。记住基础：类是对象，因此Apple是苹果，而不是App。此外，Impl没有传达任何有关实现的内容（又称业务逻辑）。

有关详细信息，请查看以下优秀答案：

Interface naming in Java

Java Interfaces/Implementation naming convention

Java Interface Naming Conventions

命名服务类的约定

另一种方法

问题

1 个答案: