「良いコード／悪いコードで学ぶ設計入門」第10章 #ミノ駆動本

第9章から文字比率が高くなり、そのまま書き出すと文章を書写するだけになってしまう・・・ということで、小見出し＆ときどき感想って形式で。

目的駆動名前設計

名前から目的や意図が読み取れることを特徴とします。

例として挙げられているのは「商品」。

「予約」「注文」「出品」「発送」それらのロジックが入り込みやすい名称になってしまう。

これらを関心事ごとに分離し、隔離する。

関心が密結合になっているものを、疎結合高凝集とし、分離し、関心事に相応しい名称に変更する。

・・・ここは例示がめっちゃ鮮やかで、うちに出来るんかな？

となったところです。

まぁ、最初っから正解に辿り着けるものでもないので、意識しながら、良いコードに近づいていきたいですね。

関心の分離には、ビジネス目的を名前として表現することがポイントになります。

この辺りをヒントにやっていきましょう。

ここは筆者さんが先に重要ポイントをまとめてくれているので、引用します

可能な限り具体的で、意味範囲が狭い、特化した名前を選ぶ

存在ベースではなく、目的ベースで名前を考える

どんな関心ごとがあるか分析する

声に出して話してみる

利用規約を読んでみる

違う名前に置き換えられないか検討する

疎結合高凝集になっているか点検する

名前無頓着になるな
仕様変更時の「意味範囲の変化」に警戒
会話には登場するのにコード上に登場しない名前に注意
- 会話に登場する重要な概念が、ソースコード上で名前もつけられず、雑多なロジックの中に埋没していることが本当に頻繁に見受けられます。
形容詞で区別が必要な時はクラス化のチャンス

tmp とか foo とか baz とかを業務コードで使わない
技術駆動命名
- int とか str おか memory とか flag とか value01 とか
- ビジネス目的を指し示す命名に直す
ロジック構造をなぞった名前
- isMemberHpMoreThenZeroAndIsMemberCanActAndIsMemberMpMoreThanMagicCostMp
- 邪悪すぎるメソッド名
  - 業務のコードでこんなの見たら叫ぶと思う
- クラス内で、早期リターンのif文 * 3 で書き直されてた
驚き最小の原則
- メソッド名から類推できないコードを書かない
- ロジックの意図と名前を一致させる

データクラスに陥る名前
- データだけではなく、ちゃんとメソッドも同じクラスに設定しよう
- ただし、DTO（Data Transfer Object）のような、データ転送用途に使われる（データしか入っていないオブジェクトを用いる）設計パターンもある
Manager, Processr、Controller などの、意味が広すぎる名前は用いない
もっと具体的な、意味の狭い概念を見つけていく
連番連名

「動詞 + 目的語」のメソッド名に注意
- consumeMagicpoint
- addiemToParty
- 関心に無関係なメソッドは「動詞＋目的語」の形になる傾向がある
可能な限り動詞1語で済む名前にする
不適切な居場所の boolean メソッド
- boolean 型を返すメソッドは「Class名 is メソッド名」とした時に自然かどうかを考える
- This is member ins hungry
名前の省略
- しない

（2022/08/27 追記）

意図がわからなくなる省略はしない
基本的に名前は省略しない
省略をどう判断するか
- 意味が失われていないか？
- 問題が生じていないか？
- プログラム言語ごとの習慣に合致しているか？
- 命名方法がチームで一致しているか？