> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# デメテルの法則

> デメテルの法則は、モジュールが直接の協力者だけと通信する設計原則です。起源、実装方法、過剰適用時の失敗まで整理します。

<Info>
  **カテゴリ**: 原則<br />
  **タイプ**: オブジェクト指向設計原則<br />
  **起源**: Northeastern University の Demeter Project、1987年前後に Ian Holland らが提唱<br />
  **別名**: 最小知識の原則
</Info>

<Note>
  **先に答えると** — **デメテルの法則**（Law of Demeter）は、モジュールが遠い内部構造をたどらず、直接の協力者だけとやり取りするべきだという設計ルールです。狙いは結合度を下げ、変更時の連鎖的な破壊を抑えることにあります。
</Note>

## デメテルの法則とは？

**デメテルの法則**（Law of Demeter）は、オブジェクトが「自分自身」「直接保持する要素」「引数」「その場で生成したオブジェクト」にだけメッセージを送るべきだという原則です。

> 深くたどって取得するより、直接の協力者に意図を伝えて実行してもらう方が壊れにくい設計になります。

実務では `a.getB().getC().doX()` のような長い呼び出し連鎖を避けることが中心になります。[単一責任の原則](/ja/principles/single-responsibility)、[関心の分離](/ja/principles/separation-of-concerns)、[フェイルファスト](/ja/principles/fail-fast) と合わせると、保守性が大きく向上します。

### デメテルの法則の3段階の理解

* **入門**: 長いドット連鎖を減らし、直接の相手に処理を委ねる。
* **実践**: 意図が読める公開メソッドで内部ナビゲーションを隠す。
* **上級**: 変更伝播の半径を制御する境界設計として活用する。

## 起源

この法則は 1980 年代後半、Northeastern University の Demeter Project で体系化されました。Ian Holland の研究や関連論文で、オブジェクト間通信を局所化する設計指針として示されています。

背景にあった課題は保守コストです。呼び出し側が深い内部構造に依存すると、内部の小さな変更でも多数の呼び出し元が壊れます。通信先を近い協力者に限定することで、変更の波及範囲を小さくできます。

現在は OOP だけでなく、API 設計やレイヤードアーキテクチャの実務でも使われる基本原則です。

## 要点

デメテルの法則は「文法ルール」ではなく「結合制御の運用ルール」です。

<Steps>
  <Step title="友達とだけ話し、見知らぬ内部には触れない">
    メソッドは自分と直接の協力者に集中し、深い内部構造への到達を避けます。
  </Step>

  <Step title="深い取得を意図メソッドへ置き換える">
    必要な情報は、直接の協力者が提供する公開メソッド経由で受け取る設計にします。
  </Step>

  <Step title="長い呼び出し連鎖を設計負債の兆候として扱う">
    連鎖が多い場所は、責務分離や境界設計の見直し候補です。
  </Step>

  <Step title="厳格さと可読性のバランスを取る">
    形式的に守るためだけのラッパー増殖は避け、意図と保守性を基準に判断します。
  </Step>
</Steps>

## 応用場面

この原則は実装だけでなく、レビュー基準や API 戦略にも適用できます。

<CardGroup cols={2}>
  <Card title="バックエンドサービス層">
    深いリポジトリ連鎖を避け、業務意図を表すサービスメソッドに集約します。
  </Card>

  <Card title="フロントエンド状態設計">
    深い props 参照を減らし、selector や adapter で境界を明確化します。
  </Card>

  <Card title="SDK / ライブラリ設計">
    内部オブジェクトグラフを露出せず、安定した入口 API を提供します。
  </Card>

  <Card title="チームレビュー運用">
    train wreck 呼び出しを結合ホットスポットとして検出し、優先的に改善します。
  </Card>
</CardGroup>

## 事例

受注処理系の改修では、深いオブジェクト参照を集約境界の facade メソッドに置き換えるパターンがよく採用されます。公開されている複数の実務事例でも、この変更によってモデル変更時の影響範囲が縮小したと報告されています。

測定指標としては「1 チケットあたりの変更ファイル数」と「リリース後の回帰不具合件数」が使われます。呼び出し連鎖を短くし境界を固定すると、これらの指標が改善しやすくなります。

## 限界と失敗パターン

デメテルの法則は有効ですが、過剰適用は逆効果です。

* **ラッパー過多**: 価値の薄い中継メソッドが増え、可読性が低下する。
* **API の痩せすぎ**: 何でも隠しすぎると、高度な利用がしにくくなる。
* **形式的準拠**: 見た目は守っていても、意味的には強く結合している場合がある。

## よくある誤解

現場では「ドット連鎖を禁止するだけ」と誤解されがちです。

<AccordionGroup>
  <Accordion title="誤解：メソッドチェーンはすべて禁止">
    **訂正**: 安定した fluent API と、内部構造漏洩を伴う連鎖は区別して扱うべきです。
  </Accordion>

  <Accordion title="誤解：ラッパーを増やせば自動的に良設計になる">
    **訂正**: 意図を明確化し、変更を隔離できるときだけラッパーは価値を持ちます。
  </Accordion>

  <Accordion title="誤解：OOP 専用の教条で実務には不要">
    **訂正**: 核心は局所的な依存関係の維持であり、どのアーキテクチャでも有効です。
  </Accordion>
</AccordionGroup>

## 関連概念

デメテルの法則は、隣接原則と組み合わせるほど効果が出ます。

<CardGroup cols={3}>
  <Card title="単一責任の原則" href="/ja/principles/single-responsibility">
    責務境界を明確にし、不要な横断依存を減らします。
  </Card>

  <Card title="関心の分離" href="/ja/principles/separation-of-concerns">
    層間の責任を分け、深い構造依存を防ぎます。
  </Card>

  <Card title="最小権限の原則" href="/ja/principles/least-privilege">
    「必要最小限だけ許可する」という同型の考え方を安全設計に適用します。
  </Card>
</CardGroup>

## 一言で言うと

<Tip>デメテルの法則は、通信を近い協力者に限定して変更伝播を抑える、保守性重視の境界設計原則です。</Tip>