关于服务类的几个问题

Question

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

我的问题如下：

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

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

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

实例变量。

默认和非默认构造函数

访问器和修改器方法

toString 方法

等于法

其他需要的帮助方法

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

Answer 1

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

这种方法的最大问题是，它会导致过程式（而不是面向对象）设计，因为您的域类只是带有 getter 和 setter 的包，并且应用程序的所有逻辑都位于服务类内。有关贫血域模型反模式的更多信息。

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

Answer 2

对于您要问的内容没有硬性定义，只有人们根据情况或多或少遵守的“一般做法”。

通常，“服务”类处理来自某种用户的请求，封装业务逻辑和持久性，远离正在执行的操作。

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

它不直接做这些事情。它不写入到数据库中，但是委托给User，Item，Inventory并Receipt为需要的类，谁都知道如何保持自己的信息。（或者它与执行此操作的数据库服务对话。）“服务”类确实将许多较低级别的功能粘合在一起。

在服务类中执行此操作的原因是代码基础结构。例如，如果您有一个Item对象，它可能会因销售、管理员降低价格、员工将其标记为丢失等而被修改。您可以将所有这些方法放在一个类中，但是然后您去哪里何时更新结帐流程？它变得痛苦。相反，您有不同的服务：PurchaseService、InventoryManagementService等。特定的服务取决于您的用例，以及在逻辑上划分事物的合理位置：例如，它可以按操作类别（“购买”）或它可以按用户类型（“CustomerService”、“OwnerService”、“EmployeeService”等），以便更轻松地处理不同的权限。

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

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

您所说的“模板”是什么意思不清楚，但是您布置的模板实际上是任何类的模板，因此不受此上下文的限制。