Rubyのリファクタリング:「聞くな、言え」の法則

元ネタはこちら。
Tell, Don't Ask

キャッチフレーズから非常に分かりやすい。

Tell, Don't Ask 言え！、聞くな

理想的なオブジェクト指向設計においてはオブジェクトに対してただやって欲しいことを「言う」だけ。
こちらでどうればいいのか聞いたり、判断したりしないこと。
サンプルで見るとそれは明快。

悪い例

<% if current_user.admin? %>
  <%= current_user.admin_welcome_message %>
<% else %>
  <%= current_user.user_welcome_message %>
<% end %>

これはいちいち current_user が Admin かどうか、聞いて（判断して）からメッセージを送っているので、そこがダメ。

ただしくはただ言うだけにするべき。
良い例

<%= current_user.welcome_message %>

welcome_message をただ呼んで（言って）るだけ。

また別の例がこちら。
悪い例

def check_for_overheating(system_monitor)
  if system_monitor.temperature > 100
    system_monitor.sound_alarms
  end
end

上記の例が悪いのは temperature の値が１００以上か判断してから sound_alarms を起こしている。こんな実装をしてしまうと全ての sound_alarms の前に１００以上かの判断が必要になってしまう。

良い例

system_monitor.check_for_overheating

class SystemMonitor
  def check_for_overheating
    if temperature > 100
      sound_alarms
    end
  end
end

呼び出し元はただ check_for_overheating を呼ぶだけ。１００以上か？などの判断を意識する必要はない。それらの判断は SystemMonitor で行うべき。

Ruby のリファクタリングをしていると「なぜそのように変更した方がいいのか？」「他のコードにもその変更基準を適用すべきか？」などの質問が多くある。そこで「Tell, Don't Ask（聞くな、言え！）の法則だよ」と分かりやすいキャッチフレーズと共に伝えることで理解が容易になり、かつその後も継続して受け入れられやすくなる。

ただこの様な枝葉のテクニックを使って、コード品質を上げるよりも本質的にオブジェクト指向設計とは何か？を理解した後でテクニックを磨いた方が遠回りに見えて実は最短コースではある。
オブジェクト指向設計の理解にはこちらの書籍が絶賛オススメ中。いつもこのブログでこの本とオススメしてしまっているが、これ以上にいい本が見当たらないからだ。それぐらいに良書であることを保証する。

英語とプログラミングを同時に勉強するなら「Practical Object-Oriented Design in Ruby」の一択

Ruby のリファクタリングについて詳しく解説した記事