Question

我有一个项目，我正在研究红宝石，它需要一些工人的大量工作。大多数业务逻辑都包含在这些工作者中，并且它们变得非常复杂。我设计的技术模拟了compose方法模式，但它在很大程度上依赖于实例变量来保持状态。我设置它的方式似乎合乎逻辑，但我希望从社区获得一些关于这是否错误的反馈，或者不是我能够设置它的最简洁的方法。

我基本上使用worker perform（Sidekiq）方法作为一种开关

def perform(transaction_id, data, account_id)
  @transaction_id = transaction_id
  @data           = data
  @account        = Account.new(account_id)

  @campaign_tag   = nil
  @match_str      = nil
  @options        = nil

  has_starter_tag     || return
  find_campaign       || return
  determine_options   || return
  find_active_option  || return
  reservation_over    || return
  already_filled      || return

  send_to_inventory
end

每种方法都遵循相同的逻辑。检查规则，如果不满意，执行操作（发送电子邮件，等等......）并返回false，从而停止执行。如果满意，请存储完成交易所需的一些ivar数据并返回true，从而进入下一步。

def has_starter_tag
  result = true

  @campaign_tag = find_starter_tag(@account, @data[:variable])
  if !@campaign_tag
    result = false
    send_email_about_badness
    log_some_stuff
  end

  result
end

要测试此代码，我会存储每个方法所依赖的实例变量。我知道这是代码味道，因为我的测试知道实现而不是接口。也就是说，我喜欢这些方法的干净界面，我觉得我可以扫描源并确切知道发生了什么。

如果我做错了，有人可以请一些时间并以正确的方式（或至少以其他方式）解释这一点吗？我一直有一些问题要弄清楚如何处理必须执行许多小步骤的对象，这些步骤似乎都是相互依赖的。

Answer 1

我的直觉是你试图过度设计这一点。

您所描述的内容并不算作设计模式 - 它只是将所需的功能分成多个单独的方法。问题在于这些方法彼此紧密耦合，除了“分组”功能之外，将它们分开并没有多少用途。函数似乎唯一的共同点是它们检查某些内容并取消检查失败的工作。除了重复的功能之外，您可以通过将所有代码放在一个函数中并用空行分隔各个部分来实现相同的效果。

有时候在代码中找到一些OOP解决方案或设计模式可能会适得其反。在一天结束时真正重要的是，它是否提供了优势？它节省了代码吗？它是否使代码易于维护和扩展？（代码是否需要才能轻松扩展？）为了OOP，不要试图使用OOP。

面向对象的方式来处理复杂的方法

1 个答案: