現場で役立つシステム設計の原則第2章を読んで|気付きや今後参考にしたいことなどをまとめてみました

はじめに

現場で役立つシステム設計の原則第2章 場合わけのロジックを整理するを読んで、

今まで現場で設計をしてきた自分の観点で、

特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。

 

現場で役立つシステム設計の原則第2章を読んでの気付きなど

2章では〇〇区分、〇〇種別・・・などが業務要件のなかで出てきて、

〇〇区分がこれでなおかつ、〇〇種別がこれの場合はこうするみたいなことは

複雑になりがち。それをどう整理するか??というテーマの章でした。

 

条件分岐は単文でなおかつ早期リターンで

本ではif文をシンプルで変更が安全になるポイントについて書いてありました。

  •  ifの条件やその場合の処理をメソッドに切り出して出して条件の変更による影響をメソッド内に留める
  •  elseを書かずに条件に一致したら即リターン
  •  if、else-if、elseといった複文を全部ifの短文に分けて、if文どうしを疎結合にする

 

特に早期リターンを利用してelseを書かないことと、ifの短文で場合わけを表現するという部分は

入り組んだif文を疎結合にシンプルにできるので普段から意識していこうと思います。

 

ifの条件やその場合のロジックをメソッドに切り出すというところは、さらに推し進めて

クラスに分けたり多態を使う方がより良いと感じています。(そのあたりは後述します)

 

区分毎にクラスを分けてさらに多態にし、区分の違いをifを使わずに表現

例えば、クレジットカード払い、電子マネー払いなどの支払区分があった場合、

それぞれでクラスを作成した方がさらに区分毎のロジックを独立させることができる。

ただ、クラスを分けただけではそれを使う側は区分の違いを意識する必要があり、

多態を使って例えば支払区分インタフェースをクレジットカード払い、電子マネー払いが

実装する形にすれば呼び出し側から区分の場合わけを排除できる。

 

ちょっと例は適当にアレンジしましたがざっくりこのようなことが本には記載されていました。

 

サンプルコードなどで多態の例を見ることはよくありますが、現場で多態を使ってこのように

整理できているところは僕は今までみたことがないので、、、

もう少しこの辺りを上手く使って整理できるところはないのかという観点を持てるようになると

いいのかなと感じました。

 

区分毎のロジックを列挙型で整理

例えばクレジットカード払いの場合支払手段コード値としてcreditCardが指定され、

現金だとcash、電子マネーだとelectronicMoneyがそれぞれ指定される例で考えると、

先ほどの多態とさらに列挙型を組み合わせることで、

コード値の指定だけで区分固有のロジックを利用できるやり方について本で紹介されていました。

 

現場で今まで見てきたコードではenumはコード値とラベル名をセットで持って、

コード値を定数として扱ったり、コード値からラベルに変換などの利用しか見たことしかなく、、、

コード値に専用クラスを紐づけるような使い方を見たことがなかったのですが、

確かに本で紹介されていたように整理できると、

今まで出会った複雑に入り組んだ条件分岐をかなり減らせたのではないかと思います。

 

 

第2章で自分が印象に残っているところはここまでですが、

自分の理解も含めてサンプルコードを作ってみたので最後に紹介します。

 

お題は、

ポイント管理システムをイメージしたもので

支払方法によってポイント還元率が異なり、そこを条件分岐を排除しつつ作ってみました。

(例が簡単すぎたかもしれませんが、、、応用はいくらでもできると思います)

 

こんなイメージ

 

支払方法区分に対してそれぞれクラスを作成(支払方法インタフェースを実装する形)と、

enumを用意。(利用される側)

 

 

支払い方法明細というクラスで付与ポイントを算出する際に、支払方法enumを利用する。

(利用する側)

 

 

 

インタフェースはこんな感じで作りました。

>>該当ソースコード(github)

 

ポイント還元率を返すというメソッドだけ定義しています。

それを、実装する側では例えばクレジットカード払いだと還元率2%としたかったので

こんな感じ。

>>該当ソースコード(github)

 

さらに、このようにそれぞれの支払方法をenumで列挙しました。

>>該当ソースコード(github)

 

一方使う側は、

支払方法明細クラスのコンストラクタで支払方法名、支払金額を受け取って、

それに対する付与ポイント数を算出します。

その際、支払方法名からenumを使って一切条件分岐をすることなく支払方法毎のポイント還元率を利用して

ポイントの算出ができました。

(サンプルがシンプルすぎましたが、もうちょっと支払方法毎に複雑なロジックがあった場合でも

応用がききます)

>>該当ソースコード(github)

 

まとめ

現場で役立つシステム設計の原則第2章 場合わけのロジックを整理するを読んで、

個人的には特に以下3点の考え方は重要だと感じました。

 

  • 条件分岐は単文でなおかつ早期リターンで
  • 区分毎にクラスを分けてさらに多態にし、区分の違いをifを使わずに表現
  • 区分毎のロジックを列挙型で整理

 

手段の紹介ももちろん参考にできますが、

考え方やそう考える理由などを正しく把握する方が手段を把握するよりもはるかに重要!!!

って思います。

 

2022/3/22追記

現場で役立つシステム設計の原則を読んでみて、

今後現場で取り入れたいこと、気付きなどなど

まとめ記事を作ったので是非こちらも見てください!!

現場で役立つシステム設計の原則を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください