デメテルの法則（Law of Demeter, LoD）は、オブジェクト指向プログラミングにおける重要な設計指針の一つであり、「最小知識の原則」とも呼ばれます。この記事では、なぜ「直接の友達」とだけやり取りすべきなのか、その理由と具体的な実践方法、さらにSNSでの意外な反応までを詳しく解説します。
デメテルの法則の基本：なぜ「直接の友達」以外と話してはいけないのか
デメテルの法則とは、1987年にノースイースタン大学のデメテルプロジェクトで提唱された、ソフトウェアの結合度を低く保つための設計原則です。その核となる考え方は、「オブジェクトは、自分に直接関係のあるオブジェクト（直接の友達）のメソッドのみを呼び出すべきである」という非常にシンプルなものです。この原則を守ることで、あるオブジェクトが他のオブジェクトの内部構造や詳細を深く知りすぎることを防ぎ、システム全体を疎結合に保つことが可能になります。
具体的には、メソッド内で呼び出して良いオブジェクトは以下の4つのカテゴリーに限定されます。まず、そのオブジェクト自身のメソッド。次に、メソッドの引数として渡されたオブジェクト。そして、そのメソッド内で新しく生成されたオブジェクト。最後に、そのオブジェクトが保持しているフィールド（インスタンス変数）です。これ以外の、例えば「友達の友達」に当たるオブジェクトのメソッドを直接呼び出すことは、デメテルの法則に違反していると見なされます。この原則は、詳細については以下のWikipediaなどで詳しく解説されています。“デメテルの法則 – Wikipedia”
この法則が重視される理由は、ソフトウェアの変更に対する柔軟性を確保するためです。もし、あるクラスAがクラスBを経由してクラスCのメソッドを呼び出している場合、クラスAはクラスBの内部にクラスCが存在することを知っていなければなりません。すると、将来的にクラスBの内部構造が変更され、クラスCが不要になったり別のクラスに置き換わったりした際、本来無関係であるはずのクラスAまで修正が必要になってしまいます。このような「連鎖的な修正」を防ぐために、情報の開示を最小限に抑えることが推奨されるのです。
メソッドチェーンを避けるべき理由：結合度を下げて保守性を高める
デメテルの法則の典型的な違反例としてよく挙げられるのが、「a.getB().getC().doSomething()」のようにメソッド呼び出しが連鎖する、いわゆる「メソッドチェーン」です。これは通称「列車事故（Train Wreck）」とも呼ばれ、コードの可読性を下げるだけでなく、保守性を著しく損なう原因となります。呼び出し元のコードが、依存するオブジェクトの内部構造に深く立ち入りすぎている状態を、コードの臭い（Code Smell）の一つである「不適切な親密さ（Inappropriate Intimacy）」と呼びます。
メソッドチェーンが常態化しているコードでは、一つのクラスを変更した際の影響範囲がどこまで及ぶか予測することが困難になります。これは、ユニットテストの作成を難しくする要因でもあります。テスト対象のオブジェクトが複数の階層にわたるオブジェクトに依存している場合、テストの準備として膨大なモックオブジェクトを作成しなければならず、テストコード自体が複雑化してしまうからです。結果として、「テストを書くのが面倒だからテストを書かない」という悪循環に陥るリスクがあります。このあたりの設計思想については、Qiitaの記事でも活発に議論されています。“デメテルの法則を整理してみた。”
また、この法則は「Tell, Don’t Ask（尋ねるな、命じろ）」という原則とも密接に関連しています。オブジェクトから情報を聞き出して（Ask）外部で処理を判断するのではなく、そのオブジェクトに対して「何をしたいか」を直接伝える（Tell）ことで、ロジックを適切な場所にカプセル化できます。情報を外に漏らさず、内部で完結させることで、各オブジェクトの独立性が高まり、結果としてシステム全体が「変更に強い」構造へと進化していくのです。
【具体例】車とエンジンのコードで学ぶ違反例とリファクタリング
デメテルの法則をより深く理解するために、具体的なコードの例で考えてみましょう。例えば、「ドライバー（Driver）が車（Car）のエンジン（Engine）を始動させる」という処理を実装する場合を想定します。違反している例では、Driverクラスのコードは次のようになります。「car.getEngine().start()」。一見すると普通の実装に見えますが、これはDriverがCarの内部にEngineがあることを知っており、さらにEngineがstartメソッドを持っていることも知っている状態です。
この設計の問題点は、もし将来的にCarがEngineを持たなくなり、モーター（Motor）で動く仕様に変更された場合、Driverクラスのコードまで書き直さなければならない点にあります。これをデメテルの法則に従ってリファクタリングすると、Carクラスに「start()」というメソッドを追加し、Driverは単に「car.start()」とだけ呼び出すように変更します。これにより、Carの内部でEngineを使っているのか、それともMotorを使っているのかという詳細はDriverから隠蔽されます。カプセル化が促進され、DriverとEngineの間の直接的な依存関係が解消されるのです。
このような設計変更は、コードの可読性を向上させるだけでなく、役割分担を明確にします。「車を動かすのは車の責任であり、ドライバーがエンジンの細かい操作まで指示する必要はない」という現実世界の直感に近いモデリングが可能になります。この考え方は、オブジェクト指向における「関心の分離」を体現するものであり、大規模なシステム開発においてコンポーネント間の境界線を明確に引くために非常に役立ちます。詳細な事例や解説については、以下のエンジニア向けブログも参考になります。“デメテルの法則を整理してみた。 – Zenn”
SNSでの評価と反応：設計原則からFGOの話題まで幅広く分析
SNS上での「デメテルの法則」に関する反応を分析すると、技術的な議論以外にも面白い傾向が見られます。特にX（旧Twitter）では、エンジニアたちが自身の開発経験に基づいた意見を交換しています。多くのユーザーが「デメテルの法則を意識し始めると、クラスの設計が劇的に綺麗になる」と肯定的に捉える一方で、「厳密に守ろうとすると、単に委譲するためだけのメソッド（Middle Man）が大量に発生してしまい、逆にコードが読みにくくなる」という悩みも吐露されています。
また、SNS特有の現象として、人気スマートフォンゲーム「Fate/Grand Order (FGO)」に関連した投稿が混ざることがあります。2026年2月頃には、ギリシャ神話の女神である「デメテル」がゲーム内に実装され、大きな話題となりました。これにより、エンジニアが「デメテルの法則」について検索しようとすると、ゲームの攻略情報やファンアートが大量にヒットするという事態が発生し、TL（タイムライン）では「デメテルの法則を調べたいのに、女神様しか出てこない！」というエンジニアたちの叫びが投稿されるなど、一種のネタとして盛り上がりを見せました。こうした現象は、専門用語が一般的な言葉やキャラクター名と重複した際に起こる、テック系SNSにおける「あるある」と言えるでしょう。
具体的なユーザーの声としては、「デメテルの法則を適用したら、テストコードのモック地獄から解放された」という成功体験から、「ドットを繋げまくる書き方に慣れている若手に、なぜこれがダメなのか説明するのが難しい」といった教育現場での苦労話まで様々です。いずれにせよ、この法則は単なる机上の空論ではなく、多くのエンジニアが現場で向き合い、試行錯誤を繰り返している実戦的なテーマであることが伺えます。
実践でのバランス：法則を厳密に守るか柔軟に変えるかの判断基準
デメテルの法則は強力なガイドラインですが、常に100%厳密に適用すれば良いというわけではありません。ソフトウェア設計には常に「トレードオフ」が存在します。法則を過剰に守ろうとすると、本来のロジックとは関係のない「中継用のメソッド」が全てのクラスに溢れかえり、コードの全体像を把握するのが困難になる場合があります。これは「Middle Man（中間者）」という別のコードの臭いを引き起こす可能性があるため注意が必要です。
実務における判断基準の一つは、その「ドット（.）」で繋がっているオブジェクトが何であるかを確認することです。例えば、JavaやJavaScriptでよく使われる「流れるようなインターフェース（Fluent Interface）」や、設定情報を組み立てる「Builderパターン」などでは、メソッドチェーンが意図的に使われます。これらはデメテルの法則の「違反」に見えますが、実質的には一つのオブジェクトの状態を構築している過程であることが多いため、例外的に許容されるのが一般的です。重要なのは、データの所有構造を壊していないか、そして変更の波及範囲が不自然に広がっていないかを見極めることです。
設計に迷った際は、「将来この内部構造が変わる可能性があるか？」と自問自答してみてください。変更の可能性が高い、あるいは影響が大きそうな部分にはデメテルの法則を適用し、しっかりと壁を築いてカプセル化すべきです。逆に、標準ライブラリのデータ構造（ListやMapなど）のように、構造が変わることがまず考えられない場合は、ある程度のチェーンを許容しても大きな問題にはなりにくいでしょう。柔軟な発想で、保守性とシンプルさの最適なバランスを探ることが、プロフェッショナルなライター兼開発者に求められるスキルです。より深い知見を得るには、Stack Overflowなどのコミュニティでの議論も非常に示唆に富んでいます。“Am I breaking the Law of Demeter? – Stack Overflow”
デメテルの法則を活用するためのまとめ
- 直接の友達とだけ話す：メソッド呼び出しを直近のオブジェクトに限定し、依存関係をシンプルに保つ。
- メソッドチェーンを避ける：a.b.c()のような「列車事故」を最小限にし、内部構造の漏洩を防ぐ。
- 「Tell, Don’t Ask」を意識する：データを聞き出すのではなく、オブジェクトに処理を依頼する設計を心がける。
- バランスが重要：厳密に守りすぎて「中間者」が増えすぎないよう、柔軟な適用を検討する。
- 保守性の向上を目標にする：法則を守ることは目的ではなく、変更に強いコードを作るための手段であることを忘れない。
デメテルの法則を日々の開発に取り入れることで、あなたの書くコードはより美しく、そして何より「未来の自分やチームメンバー」にとって優しいものになるはずです。まずは自分の書いているコードに「ドット」がいくつ並んでいるか、チェックすることから始めてみましょう。
