間が空いてしまいましたが、第2回目の感想とかです。
前回はこちら。 patorash.hatenablog.com
会社のブログのレポートはこちら。 tech.rhizome-e.com
2章 場合分けのロジックを整理する
感想は箇条書きでメモってました。
- 区分や種別が条件分岐を生む。区分がロジックを複雑にする。
- それに対処するために、elseをなくして早期リターンを行うとコードが簡潔になる。これは今もよくやっている。
- if文の条件をメソッドにして名前を与えると、条件が分かりやすくなる。これもよくやっている。
- if文同士の関係を疎結合にするというのは、バグが起きにくいし、コードも見やすく、理解しやすくなる。
- Javaのインターフェースを使っての実装例として分かりやすくてよかった。
- Rubyだとインターフェースに該当するものがないので、無理やりModuleで作るしかない。呼び出したら例外を発生させるメソッドを定義するとか。
- Javaの列挙型（enum）は使ったことがないんだけれど、列挙型もクラスとして扱えるというのは知らなかった。
- 値オブジェクトの次は、区分オブジェクト。業務ロジックとしての区分は頻繁に出てくる。
- 権限だったり、顧客区分だったり。ここを設計で綺麗にできると、迷いが生じにくそう。
- 状態遷移のルールを区分オブジェクトにしてしまうという発想はなかった。これもまた条件分岐でやっていたと思うのだが、これならば一目瞭然でわかりやすい。Rubyならば、Setを使って実装するとよさそう。
雑感
よくやっている手法が出てきたので、まぁその辺りはできるようになってるな、うんうんと思いながら読み進めました。早期returnするとコードの階層が浅くなるのでいいですよね。if文の条件も、割と頻繁に出てくる可能性があるので、再利用性が高まるし、なにより条件に名前を付けられるのがわかりやすくなって良いっすね。
インターフェースを使うことで、区分に型を強制できるので、表現力があっていいなと思いました。そして、列挙型を使うことで更に簡潔に…。Rubyには現時点では列挙型がないので羨ましい。これはどうやればRubyで表現できるのか？という話し合いをしたりしました。
状態の遷移先を事前にHashMapに定義しておくのも、なるほどなぁと思いました。こうやってif文を減らしていくのか…。
読めば読むほど、リファクタリングがしたくなる本ですね！しかしなんか読書会の場ではリファクタリングに対して後ろ向きな意見がちらほら出て、やや残念な感じでした。リファクタリングしたらテストし直さないといけなくなるから…と。え、テストがあるからリファクタリングできるんじゃないの？って話したんですが、手動テストし直さないといけなくなるんで、というので、なんかルールが間違ってるんじゃない？ということは言いましたが、他のチームのことなのでこれ以上はとやかくは言えず。日々、リファクタリングに取り組んでほしい！
