Subscribed unsubscribe Subscribe Subscribe

ジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと家族と共に流れ着き、ベルリンのスタートアップで働くソフトウェアエンジニアの日記

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

Rails 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の値が100以上か判断してからsound_alarmsを起こしている。こんな実装をしてしまうと全てのsound_alarmsの前に100以上かの判断が必要になってしまう。


良い例

system_monitor.check_for_overheating

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

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

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

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

tango-ruby.hatenablog.com


Rubyのリファクタリングについて詳しく解説した記事
tango-ruby.hatenablog.com

tango-ruby.hatenablog.com