第9章から文字比率が高くなり、そのまま書き出すと文章を書写するだけになってしまう・・・ということで、小見出し＆ときどき感想って形式で。
目的駆動名前設計
名前から目的や意図が読み取れることを特徴とします。
10.1 悪魔を呼び寄せる名前
例として挙げられているのは「商品」。
「予約」「注文」「出品」「発送」それらのロジックが入り込みやすい名称になってしまう。
これらを関心事ごとに分離し、隔離する。
関心が密結合になっているものを、疎結合高凝集とし、分離し、関心事に相応しい名称に変更する。
・・・ここは例示がめっちゃ鮮やかで、うちに出来るんかな？
となったところです。
まぁ、最初っから正解に辿り着けるものでもないので、意識しながら、良いコードに近づいていきたいですね。
関心の分離には、ビジネス目的を名前として表現することがポイントになります。
この辺りをヒントにやっていきましょう。
10.2 名前を設計する - 目的駆動名前設計
ここは筆者さんが先に重要ポイントをまとめてくれているので、引用します
10.3 設計時の注意すべきリスク
- 名前無頓着になるな
- 仕様変更時の「意味範囲の変化」に警戒
- 会話には登場するのにコード上に登場しない名前に注意
会話に登場する重要な概念が、ソースコード上で名前もつけられず、雑多なロジックの中に埋没していることが本当に頻繁に見受けられます。
- 形容詞で区別が必要な時はクラス化のチャンス
10.4 意図がわからない名前
- tmp とか foo とか baz とかを業務コードで使わない
- 技術駆動命名
- int とか str おか memory とか flag とか value01 とか
- ビジネス目的を指し示す命名に直す
- ロジック構造をなぞった名前
isMemberHpMoreThenZeroAndIsMemberCanActAndIsMemberMpMoreThanMagicCostMp
- 邪悪すぎるメソッド名
- 業務のコードでこんなの見たら叫ぶと思う
- クラス内で、早期リターンのif文 * 3 で書き直されてた
- 驚き最小の原則
- メソッド名から類推できないコードを書かない
- ロジックの意図と名前を一致させる
10.5 構造を大きく歪ませてしまう名前
データクラスに陥る名前
- データだけではなく、ちゃんとメソッドも同じクラスに設定しよう
- ただし、DTO（Data Transfer Object）のような、データ転送用途に使われる（データしか入っていないオブジェクトを用いる）設計パターンもある
Manager, Processr、Controller などの、意味が広すぎる名前は用いない
もっと具体的な、意味の狭い概念を見つけていく
連番連名
10.6 名前的に居場所が不自然なメソッド
「動詞 + 目的語」のメソッド名に注意
- consumeMagicpoint
- addiemToParty
- 関心に無関係なメソッドは「動詞＋目的語」の形になる傾向がある
可能な限り動詞1語で済む名前にする
不適切な居場所の boolean メソッド
- boolean 型を返すメソッドは 「Class名 is メソッド名」とした時に自然かどうかを考える
This is member ins hungry
名前の省略
- しない
10.7 名前の省略
（2022/08/27 追記）
意図がわからなくなる省略はしない
基本的に名前は省略しない
省略をどう判断するか
- 意味が失われていないか？
- 問題が生じていないか？
- プログラム言語ごとの習慣に合致しているか？
- 命名方法がチームで一致しているか？
