現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法〜 CHAPTER2 場合分けのロジックを整理する
増田 亨. 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition). Kindle 版.
前回
プログラムを複雑にする「場合分け」のコード
区分や種別がコードを複雑にする
システムを実現するプログラムには様々な「区分」や「分類」(= つまり実コード上では Enum で表現されるものか)がある。
この「区分」「分類」に対して条件分岐を実装するが、複数の「区分」「分類」が入り組み、分岐が複雑になると修正が厄介になる。
そのため、変更しやすい実装となるように設計するにはどうすればよいか、という話。
判断や処理のロジックをメソッドに独立させる
「区分」「分類」もやはりオブジェクト指向の考え方で実装する。
「区分」「分類」を一つの塊としてメソッドに抽出し、関連するデータやロジックを一つのクラスにまとめる。
else句をなくすと条件分岐が単純になる
else をなくして条件分岐を単純化するとのことで、それには「早期リターン」が良いとのこと。
Java を書いていたときは結構意識してたな。
例では条件分岐結果を設定して最後に return するためのローカル変数を排除し、else を使わずに早期リターンを行う。
この「else を使わずに早期リターン」を「ガード節」と言うらしい。初めて知った。
また、早期リターンをしやすくするために予め条件文をメソッドに抽出しておくとよい。
複文は単文に分ける
if の中に if が入ったりと、「複文」は意図がわかりにくくなるので避ける。
ここでもやはり「ガード節」を使えばシンプルになる。
また、「ガード節」は疎結合なため順序を入れ替えても良い。
区分ごとのロジックを別クラスに分ける
区分ごとのクラスを同じ「型」として扱う
区分ごとにクラスを分けた結果、区分同士を使い分ける条件分岐を書くと、クラスに整理した意味がなくなってしまう。
そのためにインターフェイスを使って同じ型として扱うようにプログラミングしていく。
つまりポリモーフィズムのことか（「多態」）。この本を読んで気づいたのは、カタカナ名詞をなるべく使わないように説明しているところ。
区分ごとのクラスのインスタンスを生成する
Map を使って区分ごとのインスタンスを受け取るテクニック。
Javaの列挙型を使えばもっとかんたん
列挙型(Enum)と多態を組み合わせることによって、if文/Switch文でごちゃごちゃしがちなコードをすっきりさせることができる。
これは10数年前にいた現場で実際やっていたのだけど、そのときはまだ「多態」とかあまり言われてなかったかもしれない時代(あくまでも観測範囲で)だった。
しかし、こういうテクニックが設計手法として確立されていくんだなと思うなど。
区分ごとの業務ロジックを区分オブジェクトで分析し整理する
「区分オブジェクト」とは、区分ごとの業務ロジックを、区分ごとにクラスとして独立させたオブジェクトである。
業務ロジックの見通しを良くし、わかりやすく整理する。
こうすることで複雑さを分析・整理することができる。
状態の遷移ルールをわかりやすく記述する
状態遷移を管理することも重要な関心事である。状態の制約条件を管理するにも列挙型を使うと良い。
まず組み合わせをマトリクスで整理する。次にある状態から遷移可能な状態をSetで宣言する。宣言元を「キー」に、遷移可能な状態をSetとしたMapを宣言する。こうすることで、現在の状態がどの状態に遷移できるのかを整理することができる。
まとめ
業務要件から出てくる「区分」に対して愚直に条件分岐を書いた場合、あっという間にソースコードが複雑化していくという課題から、以下にして見通しの良いコードにするのかというテーマ。
曰く、業務要件から「区分」を整理し、メソッドやクラスにまとめ、さらにif文・Switch文を削減するために「インターフェイス、多態」「関心の分離」「区分オブジェクト」「列挙型」を利用するといった設計・実装をする。
こうすることで「区分」が増えた場合でも変更が容易になったりと変更にも強いソースになるのだと思う。
実はこういった列挙型や多態などのテクニックは十数年前に Java を書いていた時にはもう利用していた覚えがあるのだけど、こうしてきちんと言語化と知識として理解していた気はしない。
もちろん今は知識としても持っているのだが、再確認する意味でもとても良い CHAPTER だった。
