Ruby on rails 仅为一次使用创建帮助器方法是否有好处？

我注意到，在Rails教程中，有时作者会生成只使用一次的助手方法。这让我觉得很可笑，但在学习ActionCable时，我注意到DHH在两年前为ActionCable做的介绍中也做了同样的事情。所以，也许有一点是我遗漏的。为了便于说明，这里是DHH的代码

# app/jobs/message_broadcast_job.rb
class MessageBroadcastJob < ApplicationJob
  queue_as :default

  def perform(message)
    ActionCable.server.broadcast 'room_channel', message: render_message(message)
  end

  private
    def render_message(message)
      ApplicationController.renderer.render(partial: 'messages/message', locals: { message: message })
    end
end

---

第一个结构比我的有什么好处吗？我只看到了一个毫无意义的抽象。

您所写的很好，但在RubyonRails中有一些过程需要遵循&遵循与否是您自己的选择

我们使用助手的原因如下

在应用程序中组织好代码。 使用DRY概念，这样，如果需要相同的助手方法，可以由多个方法或操作使用。 希望它明确了在RubyonRails应用程序中使用helpers的目的

谢谢和问候

---

Harender

创建助手方法或任何方法有两个合理的理由：

使一段代码可重用 让所有阅读该代码的人都清楚该代码的目的 我认为这两种方法都是有效的。您应该问问自己，创建一个helper方法是否会增加应用程序逻辑的清晰性，并使任何人甚至您都更容易理解正在发生的事情。如果是这样的话，我认为创建一个只使用一次的助手是可以的

---

在大型应用程序中，我发现清晰性通常比额外几行代码更重要。以后可能有人会发现它的另一个用途。

我发现第一个更容易阅读和理解。在第一种方法中，每种方法只做一件事。其他人，或者将来，你可能会欣赏到更清晰和责任分离。确切地说，DRY只是提取功能以分离方法的一个原因。这不是唯一的原因。render_message获取一个message对象并返回一个字符串，这一点很容易一目了然。在示例2中，说明您的perform方法的作用更为困难。到目前为止的评论似乎是个人偏好，这很好。似乎没有比这更重要的了。DRY在这里不适用，因为它只使用一次。关于要遵循的流程，您指的是什么流程？我仍然看不到抽象的任何意义，特别是因为它需要更多的代码行，而不是更少的代码行。

def perform(message)
  ActionCable.server.broadcast 'room_channel', { 
    message: ApplicationController.renderer.render(
      partial: 'messages/message', 
      locals: { message: message }
    )
  }
end