重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたのでこちらも是非みてください!!良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて良いコード/悪いコードで学ぶ設計入門第6章を読んでの気付きなど6章では条件分岐をずさんに扱った結果どんなことが起こるか??条件分岐がしたくなったら何を注意してどう書けば良いか??について学べる章だと思います。早期リターンがコードの見通しを良くする良いコード/悪いコードで学ぶ設計入門第6章には早期リターンについて悪いコードと良いコードを挙げながら説明されていました。条件分岐が何段にも入れ子になってたり、メソッド内で実処理の一部と実処理を行わないための条件判定が交互にでてきたり・・・・こうなるとかなりソースコードの見通しが悪くなります。実処理をメソッドの後方に固められます。早期リターンで書くのはそこまでハードルは高くないので、すぐにでも意識して良いコードを書く癖をつけていけるのではないかと思います。現場で役立つシステム設計の原則で早期リターンのところを読んでから意識するようにしていますが、ソースコードの見通しは全然違うなと感じています。早期continueや早期breakも基本的には同じような考え方なので、こちらも合わせて使えるといいのかなと。・interface設計を試みる・クラス化を試みる以前現場で役立つシステム設計の原則を読んで同じような内容をまとめたので条件分岐を書かずにinterfaceで処理を切り替える方法の詳細についてはこちらを参照ください。僕がごちゃごちゃ分岐処理を書くことになりそうな場合にどう考えているかイメージをお伝えしようと思います。分岐して実行したい実処理はここに(大抵は〇〇Serviceとか??)書くべきかを考え直します。他の箇所にも同じような分岐処理を書くことになるからです。最悪の場合同じような別の共通メソッドなり処理が作られ始める。この辺り(今、手を抜くと保守でとてつもなくしんどくなるということ)を理解した上で、switch文で分岐して実行したい処理毎に分析して実処理と必要なデータをセットでクラスに切り出していきます。次に、switch文で分岐したい実処理毎に切り出したクラス同士を俯瞰して例えば、すべてのクラスで料金の計算や手数料の計算を行っている??という観点で分析していきます。〇〇区分毎に料金の算出ロジックが違ってswitch文を書いて計算処理をcaseでベタ書きしているとか。いうのは区分毎にクラスに分割して全クラスに料金計算ロジックを持たせられます。いう〇〇区分クラスを個別に作ったらそれを1括りで同じように扱えるinterfaceを作ってさらにenumとmapを組み合わせて(詳細は前述の関連記事参照)・・・とやれば分岐を書かずに処理を切り替えられます。理由は例えば以下が挙げられると思います。(至る所にある)使う側で分岐をわざわざ書かなくて済むようになる。〇〇区分がさらに追加、区分毎に切り替えたい処理が追加などの場合はそれ用のクラスを追加してinterfaceを実装するだけでよい。使う側がシンプルになるのでテストコードも書きやすい。本では、interfaceを実装させておくことで実装漏れはコンパイルエラーで気付けるなども挙げられていました。分岐処理を丁寧なクラス分割およびinterfaceをきることで分岐処理を書かずに処理を切り替える方法について個人的には特に重要なポイントかなと思いました。現場で使えるレベルでの理解とはいきませんでした。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。