핵심 인사이트 (3줄 요약)

  • 느슨한 결합 (Loose Coupling): 객체는 직접 연관된 '친구'와만 소통해야 하며, 친구의 친구(내부 구조)에 깊이 관여해서는 안 된다는 원칙이다.
  • 기차 충돌(Train Wreck) 방지: a.getB().getC().doAction()과 같은 긴 메서드 체이닝을 방지하여 코드의 가독성과 유지보수성을 높인다.
  • 캡슐화의 완성: 객체의 내부 구조를 숨기고 인터페이스만을 통해 협력하게 함으로써 변경의 전파 범위를 최소화한다.

Ⅰ. 개요 (Context & Background)

  • 정의: 소프트웨어 설계에서 객체가 이웃 객체의 내부 구조를 알지 못하도록 제한하는 원칙으로, "Don't talk to strangers"라는 별칭으로 불린다.
  • 배경: 객체 간의 의존성이 깊어질수록 하나의 클래스 수정이 연쇄적인 오류를 유발하는 '취약한 코드'가 생성되므로, 이를 방지하기 위해 제안되었다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

[ Bad Practice: Train Wreck ]          [ Good Practice: Law of Demeter ]
+----------+      +----------+         +----------+      +----------+
| Client   |----->| Order    |         | Client   |----->| Order    |
+----------+      +----------+         +----------+      +----------+
      |                |                     |                |
      | getCustomer()  |                     | processOrder() |
      v                v                     v                v
+----------+      +----------+         +----------+      +----------+
| Customer |----->| Address  |         | Customer |<-----| Address  |
+----------+      +----------+         +----------+      +----------+
      | getZipCode()                         (Hidden from Client)
  • 핵심 규칙 (Only talk to your immediate friends):
    1. 객체 자신의 메서드를 호출할 수 있다.
    2. 메서드의 파라미터로 전달된 객체의 메서드를 호출할 수 있다.
    3. 메서드 내에서 생성된 객체의 메서드를 호출할 수 있다.
    4. 객체의 직접적인 멤버 변수(이웃)인 객체의 메서드를 호출할 수 있다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

비교 항목디미터의 법칙 위반 (Dot notation)디미터의 법칙 준수 (Delegation)
코드 가독성user.getWallet().getMoney().amount()user.pay(amount)
결합도User, Wallet, Money 모두에 의존User에게만 의존 (느슨한 결합)
유지보수Wallet 구조 변경 시 Client 코드 수정 필요User 내부 구현만 수정하면 됨
캡슐화 수준낮음 (내부 구조 노출)높음 (정보 은닉)

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

  • 기술사적 판단: 디미터의 법칙은 단순히 도트(.)를 하나만 쓰라는 규칙이 아니다. 핵심은 **"객체에 묻지 말고 시켜라(Tell, Don't Ask)"**이다. 객체의 상태를 가져와서 판단하는 것이 아니라, 해당 객체가 스스로 업무를 수행하도록 메시지를 던지는 설계가 중요하다.
  • 적용 시 주의사항: 과도한 준수는 '위임 메서드(Wrapper)'를 과다하게 생성하여 클래스가 비대해질 수 있으므로, 단순한 데이터 구조(DTO)나 빌더 패턴 등에서는 유연하게 적용해야 한다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

  • 기대효과: 코드의 모듈성이 향상되고 단위 테스트 작성이 쉬워진다. 특정 모듈의 변경이 시스템 전체로 퍼지는 것을 차단하여 대규모 시스템의 안정성을 확보한다.
  • 결론: 디미터의 법칙은 객체지향의 본질인 '협력'과 '책임'을 실천하는 가장 기초적이면서 강력한 가이드라인이다.

📌 관련 개념 맵 (Knowledge Graph)

  • 상위 개념: 객체지향 설계(OOD), 정보 은닉(Information Hiding)
  • 동급 개념: SOLID 원칙 중 SRP(단일 책임 원칙), Tell, Don't Ask
  • 하위 기술: 캡슐화(Encapsulation), 위임(Delegation)

👶 어린이를 위한 3줄 비유 설명

  1. 친구의 가방 안에서 필통을 꺼내 연필을 가져오는 건 예의가 아니에요. (법칙 위반)
  2. 친구에게 "연필 좀 빌려줘"라고 말하면 친구가 필통에서 연필을 꺼내서 줄 거예요. (법칙 준수)
  3. 이렇게 서로의 물건을 직접 건드리지 않고 부탁만 하면 싸울 일이 없답니다!