ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2010-08-26

[]Replace Nested Conditional with Guard Clauses

f:id:asakichy:20100527231436p:image条件分岐のネストからガード節へf:id:asakichy:20100527231438p:imageガード節による入れ子条件記述の置き換え

どんなとき?

正常な実行経路がはっきりしないような条件分岐を持つメソッドがある。

どうすれば?

すべての特殊条件をガード節で処理する。

たとえば?

Before

def pay_amount
  if @dead
    result = dead_amount
  else
    if @separated
      result = separated_amount
    else
      if @retired
        result = retired_amount
      else
        result = normal_pay_amount
      end
    end
  end
  result
end

After

def pay_amount
  return dead.amount if @dead
  return separated_amount if @separated
  return retired_amount if @retired
  normal_pay_amount
end

どうして?

条件式は、2つの形態があります。

第1の形態は、どちらのコースを辿っても正常なふるまいの一部になる、というものです。第2の形態は、条件式に対する一方の答が正常条件のふるまいで、もう一方の答が異常条件のふるまいを示している、というものです。

これら2種類の条件分岐は目的が異なります。両方の答が正常なふるまいなら、if/thenとelseに分岐する形を使います。片方の答が異常条件を示す場合には、条件をチェックし、その条件が真ならreturnするように書きます。この種のチェックは、「ガード節」と呼ばれます。

if-then-else構文を使う場合、if/thenの分岐先とelseの分岐先には同等のウェイトを置いています。両方の分岐先が同じように実行され、重要だということを読者に伝えます。それに対し、ガード節は「これはまれなケースで、発生した場合には何かちょっとしたことを行って外に出る」ということを明確に表現することができます。

どうやって?

このリファクタリングのポイントは、片方を強調することです。ガード節を使い、メインフローをできる限り強調するようにします。

このリファクタリングをよく使うのは、メソッドの出入口を1つに絞れと教え込まれたプログラマと一緒に働くときです。現代のプログラミング言語は、入口が1つになるよう強制しています。それに対し、出口を1つに絞るというのは意味のあるルールではありません。

目的にすべきは、ルールを守ることではなく、コードの明確性です。出口を1つにするとメソッドの意味がはっきりするのなら、出口を1つにします。そうでなければ、出口を1つに絞る意味はありません。

ちなみに

元祖はケント師の「Guard Clause(ガード条件)@実装パターン」です。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/asakichy/20100826/1282782447