目的駆動名前設計：名前から目的や意図が読み取れることを特徴とする

命名が関心を分離できているか

例えば、商品というクラスという名前にreservationsやorders、shipmentsなどのような関心ごと全てが含まれていては密結合となりよろしくない。命名したときにこれではカバーする範囲、つまり関心ごとが広すぎる。

したがって、関心の分離をすることが重要。「関心ごと、つまりユースケースや目的、役割ごとに分離する」わけである。

例えば、商品クラスにいろいろなロジックが含まれている場合
予約品、注文品、在庫品、発送品のように分割して行けば良い。

大雑把で意味が不明瞭な命名になっていないか

先ほどの商品という名前はさまざまな状況をフォローできそうな名前だが、裏を返せばなんでも欠けてしまうクラスとなり、目的が不明なオブジェクトとなってしまう。

このメリットとしては

住所：配送元、再送先に変更
金額：請求金額、消費税額、延滞保証料、キャンペーン割引料金など
ユーザー名：アカウント名、表示名、本名など

ホワイトボードなどに書いてチームメンバーと登場人物や事柄を列挙したり、関係性を整理したり、分析したりしてみましょう。

顧客：宿泊客と支払者に分割するなど

#　会話には登場するがコード上に登場しない名前はないか

「元々の〜」「補正された〜」などのように形容詞をつけて説明していることがあればクラス化できないか検討する。

#　意図がわからない名前はないか
tmp, file, dataなどそれを見ただけで意図がわからない名前は避けよう。

メソッドの名前を見て、こう動くと思っていて蓋を開けたら予想外のことをやっていた...などとはならないように、名前に沿ったメソッドを記述すること

例えば、〜Manager、〜Processor、Controllerのような名前は意味が広すぎて秩序がない状態に陥る。単一責任を忘れずにクラス定義すること。
#　状況によって意味や扱いが異なる名前になっていないか

#　メソッドが不自然な場所に置かれていないか
Enemyクラスの中にパーティにアイテムを追加する、ゲームを終了するなどEnemyに関係のない、関心ごとがずれたメソッドが置かれていないか気をつけること。

#　動詞一語で済む名前になっているか（可能な限り）
動詞＋目的語になっている場合以下のようにできにか検討する
目的語の概念を表現するクラスを作る
そのクラスに動詞一語のメソッドを追加する

要は「〜がメソッド名する」という形が理想的なのかも。

#　名前の省略で意図が分からなくなっていないか（基本的に省略しない）
省略形が一般名称なら良いが、基本的には省略しないこと