【问题标题】:A Few Questions About Service Classes关于服务等级的几个问题
【发布时间】:2016-04-09 17:20:35
【问题描述】:

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

我的问题如下:

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

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

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

实例变量。

默认和非默认构造函数

访问器和修改器方法

toString 方法

等于方法

其他需要的帮助方法

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

【问题讨论】:

  • “服务类”不是一个广为人知的 OO 或 Java 概念。这意味着无论您的书的作者如何决定它在他的书的上下文中意味着什么。关于字段和方法的顺序,由你自己决定,但常规顺序一般是字段、构造函数、方法。
  • 我同意@JBNizet,我认为这个问题太宽泛了

标签: java class methods service


【解决方案1】:

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

通常,“服务”类处理来自某种用户的请求,将业务逻辑和持久性封装在所采取的操作之外。

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

直接做的是这些事情中的任何一个。它不写入数据库,而是根据需要推迟到UserItemInventoryReceipt 类,他们都知道如何保存自己的信息。 (或者它与执行此操作的数据库服务对话。)“服务”类确实将许多较低级别的功能粘合在一起。

您在服务类中执行此操作的原因是代码库结构。例如,如果您有一个 Item 对象,它可能会被销售、管理员降低价格、员工将其标记为缺失等进行修改。您可以将所有这些方法放在一个类中,但是当您想更新结帐流程时,您会去吗?它变得痛苦。相反,您有不同的服务:PurchaseServiceInventoryManagementService 等。特定的服务取决于您的用例,以及在逻辑上划分事物的意义所在:例如,可以按操作类别 ('购买”),也可以按用户类型(“CustomerService”、“OwnerService”、“EmployeeService”等),以便更轻松地处理不同的权限。

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

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

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

【讨论】:

    【解决方案2】:

    可以将服务类视为客户端与应用程序中的某些功能进行交互的一种方式。通常是公开的,具有一定的商业意义。例如,Employee 类可能具有应声明为私有的属性,例如employeeId、firstName、lastName、address。然后应该有那些称为 setter 和 getter 的访问器方法。现在应该有一个覆盖的 hashcode 和 equals 方法来查找对象之间的相等性。服务类中可能有也可能没有任何业务规则,具体取决于您计划使用的设计模式。还应该覆盖此对象中的 toString 方法。 建议将助手编写在单独的助手类中。 一个简单的示例可能是 MVC 模式,您可以将模型视为服务类,将控制器视为帮助类(尽管它们并不完全相同)。 有关主题的更多信息,您可以参考以下链接:

    1. getters and setters
    2. Equals and HashCode

    【讨论】:

      【解决方案3】:

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

      这种方法的最大问题是它会导致程序化(而非面向对象)设计,因为您的域类只是带有 getter 和 setter 的袋子,并且您的应用程序的所有逻辑都在服务类中。更多关于Anemic Domain Model anti-pattern

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-05-12
        • 2011-08-24
        • 2013-01-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多