カテゴリ: 原則
タイプ: オブジェクト指向設計原則
起源: Northeastern University の Demeter Project、1987年前後に Ian Holland らが提唱
別名: 最小知識の原則
タイプ: オブジェクト指向設計原則
起源: Northeastern University の Demeter Project、1987年前後に Ian Holland らが提唱
別名: 最小知識の原則
先に答えると — デメテルの法則（Law of Demeter）は、モジュールが遠い内部構造をたどらず、直接の協力者だけとやり取りするべきだという設計ルールです。狙いは結合度を下げ、変更時の連鎖的な破壊を抑えることにあります。
デメテルの法則とは？
デメテルの法則（Law of Demeter）は、オブジェクトが「自分自身」「直接保持する要素」「引数」「その場で生成したオブジェクト」にだけメッセージを送るべきだという原則です。深くたどって取得するより、直接の協力者に意図を伝えて実行してもらう方が壊れにくい設計になります。実務では
a.getB().getC().doX() のような長い呼び出し連鎖を避けることが中心になります。単一責任の原則、関心の分離、フェイルファスト と合わせると、保守性が大きく向上します。
デメテルの法則の3段階の理解
- 入門: 長いドット連鎖を減らし、直接の相手に処理を委ねる。
- 実践: 意図が読める公開メソッドで内部ナビゲーションを隠す。
- 上級: 変更伝播の半径を制御する境界設計として活用する。
起源
この法則は 1980 年代後半、Northeastern University の Demeter Project で体系化されました。Ian Holland の研究や関連論文で、オブジェクト間通信を局所化する設計指針として示されています。 背景にあった課題は保守コストです。呼び出し側が深い内部構造に依存すると、内部の小さな変更でも多数の呼び出し元が壊れます。通信先を近い協力者に限定することで、変更の波及範囲を小さくできます。 現在は OOP だけでなく、API 設計やレイヤードアーキテクチャの実務でも使われる基本原則です。要点
デメテルの法則は「文法ルール」ではなく「結合制御の運用ルール」です。応用場面
この原則は実装だけでなく、レビュー基準や API 戦略にも適用できます。バックエンドサービス層
深いリポジトリ連鎖を避け、業務意図を表すサービスメソッドに集約します。
フロントエンド状態設計
深い props 参照を減らし、selector や adapter で境界を明確化します。
SDK / ライブラリ設計
内部オブジェクトグラフを露出せず、安定した入口 API を提供します。
チームレビュー運用
train wreck 呼び出しを結合ホットスポットとして検出し、優先的に改善します。
事例
受注処理系の改修では、深いオブジェクト参照を集約境界の facade メソッドに置き換えるパターンがよく採用されます。公開されている複数の実務事例でも、この変更によってモデル変更時の影響範囲が縮小したと報告されています。 測定指標としては「1 チケットあたりの変更ファイル数」と「リリース後の回帰不具合件数」が使われます。呼び出し連鎖を短くし境界を固定すると、これらの指標が改善しやすくなります。限界と失敗パターン
デメテルの法則は有効ですが、過剰適用は逆効果です。- ラッパー過多: 価値の薄い中継メソッドが増え、可読性が低下する。
- API の痩せすぎ: 何でも隠しすぎると、高度な利用がしにくくなる。
- 形式的準拠: 見た目は守っていても、意味的には強く結合している場合がある。
よくある誤解
現場では「ドット連鎖を禁止するだけ」と誤解されがちです。誤解：メソッドチェーンはすべて禁止
誤解：メソッドチェーンはすべて禁止
訂正: 安定した fluent API と、内部構造漏洩を伴う連鎖は区別して扱うべきです。
誤解：ラッパーを増やせば自動的に良設計になる
誤解：ラッパーを増やせば自動的に良設計になる
訂正: 意図を明確化し、変更を隔離できるときだけラッパーは価値を持ちます。
誤解：OOP 専用の教条で実務には不要
誤解：OOP 専用の教条で実務には不要
訂正: 核心は局所的な依存関係の維持であり、どのアーキテクチャでも有効です。
関連概念
デメテルの法則は、隣接原則と組み合わせるほど効果が出ます。単一責任の原則
責務境界を明確にし、不要な横断依存を減らします。
関心の分離
層間の責任を分け、深い構造依存を防ぎます。
最小権限の原則
「必要最小限だけ許可する」という同型の考え方を安全設計に適用します。