Rails 助手应该假设存在一个实例变量，还是应该将它们作为参数接收？答案

【问题标题】：Should Rails helpers assume an instance variable exists or should they receive them as parameters?Rails 助手应该假设存在一个实例变量，还是应该将它们作为参数接收？
【发布时间】：2011-09-22 09:47:27
【问题描述】：

我想知道是否有特定的编程原则（Demeter？）支持 Rails 助手不应该使用控制器实例变量，而是应该接收这些变量作为函数参数的想法。例如，假设我的ChickensController#squawk 操作创建了一个名为@egg 的实例变量。此外，假设squawk 视图包含对名为cockadoodledoo 的助手的调用，实现如下：

def cockadoodledoo
  @egg.to_s
end

将@egg 作为参数传递会更好还是不必要地冗长，以便视图调用cockadoodledoo(@egg) 并使助手类似于：

def cockadoodledoo(egg)
  egg.to_s
end

我希望你们中的一个快乐的黑客在周五下午无聊到可以断言答案。 Cockadoodledoo！

This question here is similar, but was never accurately answered.

【问题讨论】：

哦，这么多不错的答案，只有一个复选标记要给....谢谢大家。

标签： ruby-on-rails function parameters parameter-passing

【解决方案1】：

将它们作为参数接收。否则，随着应用程序的增长，在重构、故障排除等时很难跟踪实例变量的设置位置。

另外，我相信一般的最佳实践是只在初始模板中的视图中使用实例变量...然后您应该从那里将变量传递给帮助程序和其他部分。

【讨论】：

有谁知道这个最佳实践在哪里提到或叫什么名字？
法比奥，我不同意。当然，我们不想在编程艺术中强制执行严厉的规则，但命名事物有很大的价值。例如，“DRY 原则”。

【解决方案2】：

我想说您应该始终将变量显式传递给您的助手，原因有两个：

您可以完全控制自己的行为
最重要的是，您可以测试您的助手

【讨论】：

我没有考虑可测试性。呃，我是不是被我的裤子脱了？（是的，我应该写更多的测试。）
提高测试助手的能力是关键。感谢您明确地调用它。

【解决方案3】：

我不知道是否有任何命名的原则来管理这类事情，但我会通过一个论点。该参数不仅使您的助手更易于测试，并且您的应用程序的数据流更易于遵循，而且还允许您将一个助手用于单个实例以及一个列表；如果你传递一个参数，那么两个：

<%= cockadoodledoo @egg %>

和：

<% @eggs.each do |egg| %>
    <%= cockadoodledoo egg %>
<% end %>

无需引入处理@eggs 中的列表而不是单个@egg 的特殊cockadoodledoo 即可按预期工作。

【讨论】：

【解决方案4】：

由于辅助消息混合到所有控制器中，因此可用于所有视图（包括部分视图和布局），因此建立明确的合同 - 参数总是明智的。

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

【讨论】：

没有理由，我只是在努力寻找一个（你知道，每条规则都有例外），但我想我可能太用力了。