目的駆動名前設計：名前から目的や意図が読み取れることを特徴とする
命名が関心を分離できているか
例えば、商品というクラスという名前にreservationsやorders、shipmentsなどのような関心ごと全てが含まれていては密結合となりよろしくない。命名したときにこれではカバーする範囲、つまり関心ごとが広すぎる。
したがって、関心の分離をすることが重要。「関心ごと、つまりユースケースや目的、役割ごとに分離する」わけである。
例えば、商品クラスにいろいろなロジックが含まれている場合
予約品、注文品、在庫品、発送品のように分割して行けば良い。
大雑把で意味が不明瞭な命名になっていないか
先ほどの商品という名前はさまざまな状況をフォローできそうな名前だが、裏を返せばなんでも欠けてしまうクラスとなり、目的が不明なオブジェクトとなってしまう。
命名のポイントを押さえているか？
可能な限り具体的で、意味範囲が狭い、特化した名前になっているか
このメリットとしては
- 名前とは無関係なロジックを排除しやすくなる
- クラスが小さくなる
- 関係するクラスの個数が少なくなり、結合度が低減する
- 関係クラスの個数が少ないため、仕様変更時に考慮を要する影響範囲が小さくなる
- 目的に特化した名前なのでどこを変更すればいいかすぐ探し出せる
- 結果として開発生産性が向上する
存在ベースではなく、目的ベースの名前になっているか
住所：配送元、再送先に変更
金額：請求金額、消費税額、延滞保証料、キャンペーン割引料金など
ユーザー名：アカウント名、表示名、本名など
どんな関心ごとがあるか分析したか
ホワイトボードなどに書いてチームメンバーと登場人物や事柄を列挙したり、関係性を整理したり、分析したりしてみましょう。
声に出して話してみたか
利用規約を読んだか
違う名前に置き換えられないか検討したか
顧客：宿泊客と支払者に分割するなど
疎結合高凝集になっているか点検したか
# 会話には登場するがコード上に登場しない名前はないか
形容詞で区別が必要なときはクラス化のチャンス
「元々の〜」「補正された〜」などのように形容詞をつけて説明していることがあればクラス化できないか検討する。
# 意図がわからない名前はないか
tmp, file, dataなどそれを見ただけで意図がわからない名前は避けよう。
驚き最小の原則を守っているか
メソッドの名前を見て、こう動くと思っていて蓋を開けたら予想外のことをやっていた...などとはならないように、名前に沿ったメソッドを記述すること
クラスが巨大化する名前になっていないか
例えば、〜Manager、〜Processor、Controllerのような名前は意味が広すぎて秩序がない状態に陥る。単一責任を忘れずにクラス定義すること。
# 状況によって意味や扱いが異なる名前になっていないか
連番命名になっていないか
# メソッドが不自然な場所に置かれていないか
Enemyクラスの中にパーティにアイテムを追加する、ゲームを終了するなどEnemyに関係のない、関心ごとがずれたメソッドが置かれていないか気をつけること。
# 動詞一語で済む名前になっているか（可能な限り）
動詞＋目的語になっている場合以下のようにできにか検討する
目的語の概念を表現するクラスを作る
そのクラスに動詞一語のメソッドを追加する
要は「〜がメソッド名する」という形が理想的なのかも。
# 名前の省略で意図が分からなくなっていないか（基本的に省略しない）
省略形が一般名称なら良いが、基本的には省略しないこと