创新型适配器

Question

我有很多这样的代码

additional_params = {
  date_issued: pending.present? ? pending.date_issued : Time.current,
  gift_status: status,
  date_played: status == "Opened" ? Chronic.parse("now") : (opened.present? ? opened.date_played : nil),
  email_template: service&.email_template,
  email_text: service&.email_text,
  email_subject: service&.email_subject,
  label: service&.label,
  vendor_confirmation_code: service&.vendor_confirmation_code
}
SomeService.new(reward, employee: employee, **additional_params).create

相同的模式适用于许多模型和服务。

此模式的名称是什么？

如何重构当前的解决方案？

有没有解决这类问题的捷径？就像draper或其他什么

Answer 1

对我来说，这看起来有点像每种类型的实体的上帝对象。您希望您的服务能够处理与您的实体相关的所有事情。实体本身只是充当数据容器，并不对其数据负责。这被称为贫血模型。

首先，您需要了解同一实体可以有多个表示。您可以有几个不同的类来表示一个用户。在"List user“页面上，类只包含信息的一个子集，可能与来自帐户系统的信息(上次登录、登录尝试等)相结合。在用户注册页面上，您有另一个类，因为为用户提供所有信息是无效的。

这些类称为数据传输对象。它们的目的是提供特定用例所需的信息，并将内部实体与外部API (即网页)分离。

一旦您这样做了，您的服务类将开始收缩，并且您需要为每个方法调用使用更少的自定义参数。

现在，您的服务类有两个职责:管理所有实体和负责它们的业务规则。

要解决这个问题，您应该开始只通过行为(方法)修改您的实体，而不是直接更新字段。这样做时，您将自动将逻辑从服务类移动到实体类。

完成此操作后，您的服务类将更加清晰。

你可以阅读关于领域驱动设计的文章来获得灵感(不需要使用DDD，但可以从应用层的结构中获得灵感)。

Answer 2

您可以尝试构建器模式。我不熟悉ruby gem，但是你可以在这里找到信息：https://en.wikipedia.org/wiki/Builder_pattern和https://en.wikipedia.org/wiki/Fluent_interface