条件分岐を整理する

親記事 : https://qiita.com/Regpon/items/1116679adadd8fb76f3f

判断や処理のロジックをメソッドへ

顧客の区分に応じて値段を変えるロジックがあるとする。
例として顧客区分が学生だった場合のロジックを考えてみる。

if (customerType.equals("student")) {
  price = basePrice * 0.7;
}

このようなロジックにすると、学生かどうかの判定、学生だった場合値段がどのようなロジックで生まれるのかがわかりにくいのと、管理がしにくくなる。
このロジックの変更を加える際、果たして本当にこの部分の変更だけで問題ないのか、他に同じようなロジックを持ってしまていないか考えなくてはならない。
そこで、学生かどうかを判断するロジック、学生だった場合の値段を決めるロジックを切り出し、再利用可能なメソッドに置き換えることを検討する。

すると以下のようになる。

if (isStudent(customerType)) {
  price = studentPrice(basePrice);
}

boolean isStudent(Customertype customerType) {
  return customertype.equals("student");
}

int studentPrice(int price) {
  return price * 0.7;
}

このようにしておくと、ごちゃごちゃと書かれた計算式や条件式を変更するよりも安全で安心感がある。

else句はなるべく無くす

学生や幼児など、顧客の区分に応じて様々な料金体系があった場合、条件分岐が多数生まれる。

Price price() {
  Price result;
  if (isStudent()) {
    result = studentPrice(); // 学生料金
  } else if (isToddler()) {
    result = toddlerPrice();  // 幼児料金
  } else {
    result = adultPrice();  // 成人料金
  }

  return result;
} 

しかし、このような実装はガード節という早期リターンする書き方でelse句を無くすことができる。

Price price() {
  if (isStudent()) return studentPrice(); // 学生料金
  if (isToddler()) return toddlerPrice();  // 幼児料金
  return adultPrice();  // 成人料金
} 

コードでelse句を見つけたらガード節に書き換えてelse句を無くすことができないか検討することを心がけると良い。
このようにすると新たな区分（例えば70歳以上の高齢者など）を追加した場合でも、追加が容易になる。

文献

本記事は 現場で役立つシステム設計の原則 変更を楽で安全にするオブジェクト指向の実践技法 　著：増田 亨 を読んで(なるべく)自分の言葉でまとめたものです。

興味を持っていただけたらこちらの本を読んでみていただけたらと思います。(勝手に宣伝)