Naming - 目的駆動命名
ソフトウェアの意図を名前から読み取れるようにするための命名スキル。
命名の原則
1. 目的駆動で考える
存在駆動（何であるか）ではなく、目的駆動（何のためか）で名前を設計する。
code
// 存在駆動（避ける） UserData, ItemList, StringHelper // 目的駆動（推奨） AuthenticatedUser, PurchasableItems, EmailValidator
2. 具体性を最大化する
可能な限り具体的で、意味が狭く、目的に特化した名前を選ぶ。
code
// 曖昧（避ける） process(), handle(), Manager, Service, Utils // 具体的（推奨） calculateShippingCost(), validateEmailFormat(), OrderFulfillmentCoordinator, PaymentGatewayClient
3. 関心の分離を確認する
一つの名前が複数の責務を示唆していないか点検する。
code
// 複数の関心が混在（避ける） UserManagerAndValidator saveAndNotify() // 関心が分離（推奨） UserRepository + UserValidator save() → onSaved → notify()
命名ワークフロー
- •
業務目的を分析する
- •このコードは何を達成しようとしているか？
- •どんなビジネス価値を提供するか？
- •ユーザーにとっての意味は何か？
- •
用語を調査する
- •プロジェクトの用語集・利用規約を探す
- •ドメイン固有の専門用語を確認する
- •既存コードで使われている命名パターンを調べる
- •
候補を列挙する
- •最低3つの候補を出す
- •各候補の長所・短所を比較する
- •
置き換え可能性をテストする
- •別の名前で置き換えられないか検討する
- •置き換えられるなら、より具体的な名前がある
- •
関心の分離を点検する
- •名前が単一の責務を表しているか？
- •「and」「or」「with」が含まれていないか？
- •名前を説明するのに複数の文が必要ないか？
アンチパターン
| パターン | 問題 | 改善例 |
|---|---|---|
XxxManager | 責務が不明確 | 具体的な動作を名前に |
XxxService | 何でも入る | 目的を明示 |
XxxUtils/Helper | 凝集度が低い | 機能ごとに分割 |
doXxx() | 当然すぎる | 何をするか具体的に |
XxxInfo/Data | データの目的が不明 | 用途を名前に含める |
良い命名の特徴
- •読めば目的がわかる: コメントなしで意図が伝わる
- •検索可能: grepで見つけやすい
- •発音可能: チームで議論できる
- •一貫性: 同じ概念には同じ言葉を使う
- •適切な長さ: スコープに応じた詳細度