Rails助手应该假设存在实例变量,还是应该将它们作为参数接收?

yba*_*kos 40 parameters ruby-on-rails function parameter-passing

我想知道是否有一个特定的编程原理(Demeter?)支持Rails助手永远不应该使用控制器实例变量的想法,相反,它们应该接收诸如函数参数之类的变量.例如,假设我的ChickensController#squawk操作创建了一个名为的实例变量@egg.此外,假设squawk视图包含对调用的调用程序的调用cockadoodledoo,如下所示实现:

def cockadoodledoo
  @egg.to_s
end
Run Code Online (Sandbox Code Playgroud)

@egg作为参数传递会更好还是不必要地冗长,这样视图调用cockadoodledoo(@egg)和帮助器类似:

def cockadoodledoo(egg)
  egg.to_s
end
Run Code Online (Sandbox Code Playgroud)

我希望你们中的一个快乐的黑客在星期五下午感到厌倦,以便给出答案.Cockadoodledoo!

这个问题类似,但从未准确回答过.

ker*_*lin 33

接受他们作为一个参数.否则,随着应用程序的增长,在重构,故障排除等时,很难跟踪实例变量的设置位置.

另外,我认为通常的最佳做法是只在初始模板中的视图中使用实例变量...并且从那里你应该将var传递给帮助程序和其他部分.

  • 法比奥,我不同意.当然,我们不想在编程艺术中强制执行严格的规则,但在命名事物方面有很大的价值.例如,"DRY原则". (7认同)

apn*_*ing 20

我会说你应该总是明确地将变量传递给你的助手,原因有二:

  • 你完全控制你的行为

  • 最重要的是,你可以测试你的助手

  • 我没有考虑可测试性.呃,我刚被裤子弄下来了吗?(是的,我应该写更多的测试.) (3认同)

mu *_*ort 12

我不知道是否有任何命名原则来管理这类事情,但我会传递一个论点.该参数不仅可以使您的帮助程序更容易测试,而且您的应用程序的数据流更容易遵循,但它也可以让您为单个实例和列表使用一个帮助程序; 如果你传递一个参数,那么:

<%= cockadoodledoo @egg %>
Run Code Online (Sandbox Code Playgroud)

和:

<% @eggs.each do |egg| %>
    <%= cockadoodledoo egg %>
<% end %>
Run Code Online (Sandbox Code Playgroud)

将按预期工作,而不会引入一个特殊的cockadoodledoo处理列表@eggs而不是单个列表@egg.

  • 这是一个免费的多功能性的一个很好的例证,谢谢. (2认同)

Fáb*_*sta 8

由于辅助消息被混合到所有控制器中,因此可用于所有视图(包括部分和布局),因此建立明确的合同(参数)总是明智的.

我能想到的唯一例外是当一个实例变量也可用于所有视图和控制器时,如菜单或类似的东西.

  • 没有理由,我只是努力寻找一个(你知道,每条规则都有例外),但我想我可能会过于努力. (3认同)