良いコード/悪いコードで学ぶ設計入門第6章を読んで|気付きや今後参考にしたいことなどをまとめてみました

はじめに

良いコード/悪いコードで学ぶ設計入門第6章 分岐処理ー迷宮化した分岐処理を解きほぐす方法ーを読んで、

8年間現場で設計をしたり、設計に関する勉強会への参加や技術書を読んできた自分の観点で、

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

 

良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたので

こちらも是非みてください!!

良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて

 

良いコード/悪いコードで学ぶ設計入門第6章を読んでの気付きなど

6章では条件分岐をずさんに扱った結果どんなことが起こるか??

条件分岐がしたくなったら何を注意してどう書けば良いか??

について学べる章だと思います。

 

早期リターンがコードの見通しを良くする

良いコード/悪いコードで学ぶ設計入門第6章には早期リターンについて

悪いコードと良いコードを挙げながら説明されていました。

 

条件分岐が何段にも入れ子になってたり、

メソッド内で実処理の一部と

実処理を行わないための条件判定が交互にでてきたり・・・・

 

こうなるとかなりソースコードの見通しが悪くなります。

それを実処理を行う条件にマッチしなければ即リターン(早期リターン)を使うことで、

実処理を行わないための条件をメソッドの先頭に固まり、

実処理をメソッドの後方に固められます。

 

早期リターンで書くのはそこまでハードルは高くないので、

すぐにでも意識して良いコードを書く癖をつけていけるのではないかと思います。

 

自分も、新卒の時に早期リターンで何気なく書いたり、書かなかったりしてたのを、

現場で役立つシステム設計の原則で早期リターンのところを読んでから意識するようにしていますが、

ソースコードの見通しは全然違うなと感じています。

 

早期continueや早期breakも基本的には同じような考え方なので、

こちらも合わせて使えるといいのかなと。

 

条件分岐を書かずにinterfaceで処理を切り替える

良いコード/悪いコードで学ぶ設計入門第6章にこのようなことが書かれていました。

 

【初級者】

・迷わずif文やswitch文を使う

・ロジックをベタ書きする

 

【中級者】

・interface設計を試みる

・クラス化を試みる

 

以前現場で役立つシステム設計の原則を読んで同じような内容をまとめたので

条件分岐を書かずにinterfaceで処理を切り替える方法の詳細については

こちらを参照ください。

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

 

詳細なサンプルプログラムは上記の記事を参照して頂くとして、

この記事では、

僕がごちゃごちゃ分岐処理を書くことになりそうな場合に

どう考えているかイメージをお伝えしようと思います。

 

まず、

分岐して実行したい実処理はここに(大抵は〇〇Serviceとか??)書くべきかを考え直します。

 

理由は・・・

大抵とある箇所に分岐をごちゃごちゃ書き始めると、

他の箇所にも同じような分岐処理を書くことになるからです。

 

また、共通メソッドを作って、

フラグやいろんなパラメータを渡して無理やり分岐処理を書くと

1箇所に分岐処理が集まる(単一責任選択の原則)から良いようにも感じますが、

結局仕様変更時に分岐を増やしたり変更する際の影響範囲が広いのと、

変更を繰り返すうちに相当複雑になり、

最悪の場合利用するのが怖くなって使われなくなり、

最悪の場合同じような別の共通メソッドなり処理が作られ始める。。。。からです。

 

 

この辺り(今、手を抜くと保守でとてつもなくしんどくなるということ)を理解した上で、

 switch文で分岐して実行したい処理毎に分析して実処理と必要なデータをセットで

クラスに切り出していきます。

 

次に、switch文で分岐したい実処理毎に切り出したクラス同士を俯瞰して

例えば、

すべてのクラスで料金の計算や手数料の計算を行っている??

という観点で分析していきます。

 

〇〇区分毎に料金の算出ロジックが違ってswitch文を書いて計算処理を

caseでベタ書きしているとか。。。

こういうのは区分毎にクラスに分割して全クラスに料金計算ロジックを持たせられます。

 

こういう〇〇区分クラスを個別に作ったらそれを1括りで同じように扱えるinterfaceを作って

さらにenumとmapを組み合わせて(詳細は前述の関連記事参照)・・・

とやれば分岐を書かずに処理を切り替えられます。

 

 

では、ベタ書きで分岐処理書けば一瞬なのにわざわざここまでやるのか、、、

 

理由は例えば以下が挙げられると思います。

(至る所にある)使う側で分岐をわざわざ書かなくて済むようになる。

〇〇区分がさらに追加、区分毎に切り替えたい処理が追加などの場合は

それ用のクラスを追加してinterfaceを実装するだけでよい。

使う側がシンプルになるのでテストコードも書きやすい。

 

本では、

interfaceを実装させておくことで実装漏れはコンパイルエラーで気付ける

なども挙げられていました。

確かに・・・

 

逆にせっかくinterfaceを切ったのに、

使う側がinstanceofで実体を確認して分岐処理を書かれてしまったといった話もありました、、、

(やられたらなかなかショックだな)

 

 

まとめ

良いコード/悪いコードで学ぶ設計入門第6章 分岐処理ー迷宮化した分岐処理を解きほぐす方法ーでは、

 

分岐処理の早期リターンを使った良いコードの書き方と、

分岐処理を丁寧なクラス分割およびinterfaceをきることで分岐処理を書かずに処理を切り替える方法

について個人的には特に重要なポイントかなと思いました。

 

僕は学生時代にオブジェクト指向を学習してinterfaceについても知ってはいましたが、

現場で使えるレベルでの理解とはいきませんでした。。。

こういうリアルで泥臭い例とセットで学習していれば現場でもう少し使えたかもなと、、

 

コメントを残す

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

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