明けましておめでとうございます。ここでは、一発目の記事も軽めのものにしていこう。X(旧Twitter)ではスペースが狭いなと思えるネタをこちらに書いていこう。
ということで、一発目はこちらのポッドキャスト番組の感想を書いてみる。
ポッドキャストでは、命名規則から逸れる状況や機能・概念の追加に伴うメソッド名のリネームについて議論されていた。特に重要なのは、「メソッドは目的に即した『what』を表現し、メソッド内部の実装は『how』を示すべきである」という点である。例えば、getUser メソッドが機能追加により最新の投稿も返すようになる場合、単に getUserAndLatestPosts という名前に変更するのは適切ではない。この理由は、メソッド名が実装の詳細（how）に焦点を当て過ぎており、将来的な変更に対応しにくくなるからである。メソッド名はその目的や機能（what）を反映すべきである。
ドメインオブジェクトの場合
ドメインオブジェクトでは、メソッド名はそのオブジェクトの責務や行動（what）を明確に示すべきである。例えば、メッセージ投稿（postMessage メソッド）にファイル投稿機能が追加された場合、postMessageAndFile という名前は避けられるべきだ。postMessage と uploadFile として機能を分離することは、メソッドの目的を明確にし、内部実装（how）を適切に隠蔽する。
UIロジックの場合
UIロジックでは、状況が異なることがある。UserProfile画面がプロフィール情報と最新の投稿を表示するようになった場合、getUserProfileAndLatestMessages のようなメソッドは、そのビューの要求（what）に適合しており、フロントエンドの複雑さを低減することができる。
クエリによるデータ取得
クエリによってデータを返すメソッドの名前（what）が変わることは一般的である。このアプローチは、返されるデータが何であるか（what）を明確にし、開発者にとって理解しやすくする。つまり、クエリのメソッドではドメインモデルより『what』と『how』が近くなる。ただし、具体的にどの永続化デバイスから読み込むかはメソッド名に含まれていないため、ある程度の抽象化は保たれている。
---
Howを直接反映したようなメソッド名を作ってしまって困るケースでは、TDD（テスト駆動開発）のようにテストから始めて、インターフェイスとなるメソッド名を利用者の観点から考えると良い。これにより、より目的に沿ったメソッド名を導出できる可能性が高まる。