連載目次
第1章：小さくまとめてわかりやすくする
第2章：場合分けのロジックを整理する →本記事
第3章：業務ロジックをわかりやすく整理する（公開予定）
はじめに
この記事は、増田亨さんの著書「現場で役立つシステム設計の原則」の、主に私自身へ向けた読書備忘録です。（追ってサンプルコードも追加予定）
とても素晴らしい本だと思うので、興味を持たれた方はぜひ読んでみてください。
リンクは記事の最後にあります。
本章の概要
第2章：場合分けのロジックを整理する
区分や種別ごとの場合分けのロジック（if文による条件分岐など）は、
プログラムを複雑にするやっかいな存在。
第1章の「小さくまとめてわかりやすくする」考え方を場合分けのロジックにも応用し、
整理していきます。
覚えておきたいキーワード
今後、理解を深めたい（または覚えておきたい）と感じたキーワードのメモです。
早期リターン
複数の条件判定がある場合に、判定結果が確定した時点で、ただちに return する書き方。
よく見かけるのは、判定結果を変数に格納して最後に return するケースです。
String result;
if(条件1){
result = 結果;
} else if(条件2){
result = 結果;
} else {
result = 結果;
}
return result;
このような書き方の場合、判定順の入れ替えが発生した時に修正が大変、などの副作用があります。
そこで下記のようにただちに結果を返すことで、コードがすっきり分かりやすくなります。これを「早期リターン」と呼びます。
if(条件1){
return 結果;
} else if(条件2){
return 結果;
} else {
return 結果;
}
さらに else 句をなくし、以下のように記述することもできます。このような書き方は「ガード節」と呼ばれます。
if(条件1) return 結果;
if(条件2) return 結果;
return 結果;
こうすると、それぞれのロジックが疎結合な状態となり、判定順の入れ替えや追加にも容易に対応できるようになります。
区分オブジェクト
それぞれの区分を異なるクラスとして切り出し、区分特有のロジックを各クラスに閉じ込めるやり方。
それぞれ同一インターフェースの実装クラスとしておき、使う側に、区分の追加や変更による影響を与えないようにします。
本章の個人的共感ポイント
本章のなかで特に共感したポイントのメモです。
開発現場で取り組んでみたい度合いを「★」の数で表現してみました。
判断や処理のロジックをメソッドに独立させる
if 文の中にごちゃごちゃと書かれた計算式を変更するよりも、メソッドに抽出した式を変更するほうがかんたんで安全です。変更すべき箇所とその影響範囲を特定のメソッドに閉じ込めることができます。（p50）
取り組みたい度：★★★★★
メソッドに切り出す時の単位やタイミングはいつも悩むところです。
今までは「複数の箇所から呼ばれたり、何度も繰り返し実行される処理であること」を基準にメソッド化することが多かったのですが、この本を読んで考え方が変わりました。意味のあるかたまりをメソッドとして抽出することで、処理の意図をコメントではなくメソッド名で説明できるようになりますし、テストもしやすくなります。
複文は単文に分ける
文の中に文を書く「複文」は、日本語の文章であれ、プログラミング言語の記述であれ、意図をわかりにくくします。そこで、複文を分解して、単文を並べるシンプルな構造に変えます。（p52）
取り組みたい度：★★★★★
文章の構造を説明する言葉として「単文」「重文」「複文」などがあります。
参考：単文・重文・複文とは
複文とは、ひとつの文章のなかに複数の単文が含まれているものを指しますが、日本語の文章でもプログラムでも、わかりにくい状態になりがちです。条件分岐が複雑で、if 文が何重も入れ子になってしまっているプログラムを何度も見たこともあります。
適切な単位で切り出して全体の見通しを良くし、意図をつたえやすい状態にするというのは、日本語の文章でもプログラムでも、全く同じことが言えるのではないでしょうか。
私自身は、日本語の文章を書くときには「相手に意図が伝わるかどうか」をとても気にするので、プログラムも同じくらい意識しなくては、と反省しています。。
区分ごとの業務ロジックを区分オブジェクトで分析し整理する
入り組みがちな区分ごとの業務ロジックを、区分ごとに別のクラスに独立させた区分オブジェクトは、オブジェクト指向らしいコードの整理のやり方です。(中略)クラスに分けることで、特定の場合のルールや計算方法を変更しても、影響範囲をそのクラスに閉じ込めることができます。（p62）
取り組みたい度：★★★☆☆
区分の追加や変更は、業務アプリケーションの世界ではよくある事です。
区分オブジェクトなら、呼び出し元や他の区分のロジックに影響を与えることなく、安全かつ楽に対応できるので、影響範囲の調査やテストも楽になりそうです。
ドメイン駆動設計ならではの考え方と思いますが、もう少し理解を深めてから取り入れたいと感じたため、★3つとしました。
次回予定
第3章：業務ロジックをわかりやすく整理する
5/13週中に投稿します。
参考文献
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
第2章：場合分けのロジックを整理する（p47〜p66）