『良いコード／悪いコードで学ぶ設計入門』を読んで気になったことのメモ

はじめに 話題となっている『良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』 (出版社のページ) を読みました。 全体的には「うんうん、そうだよね」と同意できることが多かったです。 もちろん、初めて目にするような考え方, アイディア, テクニックもありました。 一方、気になったことやちょっと引っかかったこともありましたので、メモしておきます。 あくまでもメモなので結論のようなことはありません。 p.55: HitPoint.isZero HitPoint クラスに isZero メソッドがあります。 「ヒットポイントがゼロであれば true」という仕様で、実装は次のようになっています。

[kazkaz03]

isDisabledは前からモヤモヤしてるけど、メジャーなプロジェクトでも結構使われたりするんだよな

[hase0510]

早期returnは例が悪くない？ 値を別の値にマッピングする処理だから、if...elseの方が合うのはそれはそうという感じ。Rustならmatch、C#ならswitch式の方がよさそう。／一般的な早期リターンではelseを使わない方がいいと思う。

[uxlayman]

objはふつうはenableである→intのデフォルト値である0、boolのデフォルト値であるfalseを「普通」としたい→変数名をdisabledにしたい という動機なんだせ。若干強迫観念じみてるけど、まあそういうことなんだぜ、てことで

[xlc]

「早期 return」で else がないのはむしろ読みやすいと思うけどな。「プリミティブ型を使うな」には同意できない。DOMではイベントが 'click' のような文字列だがあれでいいと思ってる。列挙型にする方が奇妙だろう。

[diveintounlimit]

納得できる部分もあるが大枠重箱の隅。

[ene0kcal]

順に①ZEROとMINとint（正負有）の意味を要再検討、設計②elseがある方が厳密③Immutableの理解を更に深めて④数値型idなら正のみの型が望ましいが⑤パフォーマンス（ボトルネック解消）とリーダブルコードの要求精度による

[buzztaiki]

immutable なリストに add したいとかだと cons cell が欲しくなる。

[hariboten]

Immutable なオブジェクトにadd()したいって要求が不毛な気が

[greenbow]

個人的には isNotEnabled の方が好み。isBefore/isAfter みたいに、単語として対義語でも論理否定じゃない場合もあるので読むとき少し迷うんですよね。

[kknsd]

本見てないので適当だけど、早期リターンのところのロジックが今後も変わりうるのならば、その条件と戻り値を返すメソッドをHealthCondition(か別クラス)の中にくくりだすのじゃ。そしたらガード節１行ですむ。

[turanukimaru]

isDisabled にモヤるなら isEnabled と isNotEnabled を作ればいいよ（真顔。全ての対になってる言葉が思いつくとは限らない。流石に Disabled がピンと来ない英語話者はそんな多くないだろうけど。

[remonoil]

isEnabledが必要になったらisEnabledを追加すればいいんだよ