关于服务类的几个问题

Question

我一直在学习使用服务类作为模板来创建和修改对象的值。

我的问题如下：

1. 服务类的定义是什么？我正在学习的这本书没有定义它们，我在网上找到定义时遇到了麻烦。

2. 当所有方法都可以写在一个类中时，为什么我们要使用单独的服务类？

3. 所有服务类都应遵循以下结构：

  

实例变量。

     

默认和非默认构造函数

     

Accessor和mutator方法

     

toString方法

     

等于方法

     

所需的其他帮助方法

或者服务类可以作为对象模板以外的其他东西吗？

Answer 1

对于您所询问的内容，没有严格的定义，只有人们或多或少地遵守“一般做法”，具体取决于具体情况。

通常，'service'类处理来自某种用户的请求，将业务逻辑和持久性封装在正在采取的操作之外。

例如，用户想要购买物品。服务类公开了一些方法buy(Item item)。服务类实例化了一些谁正在采取行动的概念。它完成了标记购买物品的所有“繁重工作”，调用处理汇款的类，调用负责在用户数据中放置“收据”的类等等。

不做的是直接做这些事情。它不会写入数据库，而是根据需要推荐到User，Item，Inventory和Receipt类，他们都知道如何保留自己的信息。 （或者它与执行此操作的数据库服务进行对话。）“服务”类确实将许多较低级别的功能粘合在一起。

在服务类中执行此操作的原因是代码库结构。例如，如果您有一个Item对象，它可能会被销售，管理员降低价格，员工标记为丢失等等进行修改。您可以将所有这些方法放入一个类中，但是那么当你想要更新结账流程时，你去哪里了？它变得痛苦。相反，您有不同的服务：PurchaseService，InventoryManagementService等。特定服务取决于您的用例，并且在逻辑上将事物分开是有意义的：例如，它可以通过动作类别（'购买'）或者它可以是用户类型（'CustomerService'，'OwnerService'，'EmployeeService'等），以便更容易处理不同的权限。

此外，服务类没有理由关心最终存储数据的方式和位置的细节。它应该与关于数据库或文件或您拥有的内容的细节“不可知”。它实际上只是操纵实际上有责任的特定类。请记住：每个班级应该只有一个责任域。如果一个类与数据库进行对话，则不应该进行“业务逻辑”，例如计算购买所欠税款。

请注意，Java 语言绝不会强制执行任何这些做法。它们只是人们为了提供额外的结构并使他们的生活更轻松而做的事情。编译器无关紧要。

“模板”的含义不清楚，但您布置的模板实际上是任何类的模板，因此不受此上下文的限制。

Answer 2

过去一种流行的做法是将行为方法放在不包含数据的类中，而是放在称为服务的单独类中（有时也称为管理器或处理程序）。

这种方法的最大问题在于它导致程序性（非面向对象）设计，因为您的域类只是带有getter和setter的包，并且应用程序的所有逻辑都在服务类中。有关Anemic Domain Model anti-pattern的更多信息。

请注意，这并不意味着，您的应用程序根本不应该有服务类。应该使用它们时，在提供的链接中进行了描述。

Answer 3

服务类可以被视为客户端与应用程序中的某些功能进行交互的一种方式。它通常是公开的，具有一些商业含义。例如，Employee类可能具有employeeId，firstName，lastName，address等属性，应声明为private。然后应该有那些称为setter和getter的访问器方法。现在应该有一个重写的hashcode和equals方法来查找对象之间的相等性。根据您计划使用的设计模式，服务类中可能有也可能没有任何业务规则。还应该覆盖此对象中的toString方法。 建议助手写在单独的助手班级。 一个简单的例子可以是MVC模式，您可以将Models视为服务类，将Controller视为辅助类（尽管它们不完全相同）。 有关这些主题的更多信息，请参阅以下链接：

1. getters and setters
2. Equals and HashCode