Law of Demeter

Law of Demeter

Law of Demeter(데메테르의 법칙) 는 " 최소 지식 원칙 (Principle of Least Knowledge)" 이라고도 불리며, 소프트웨어의 각 모듈이나 객체가 자신과 밀접하게 연관된 객체와만 상호작용해야 한다는 설계 지침이다. 이 원칙은 객체 간 불필요한 의존성과 결합도를 줄여 시스템의 유연성, 유지보수성, 테스트 용이성을 높인다. 대표적으로 “A.getB().getC().doSomething()” 과 같은 체이닝 호출을 지양하고, 중간 객체의 책임을 명확히 분리하는 방식으로 적용된다. 실무에서는 Facade, Service Layer, DTO, 의존성 주입 등 다양한 패턴과 기법으로 활용된다.

핵심 개념

Law of Demeter (디미터 법칙) 또는 Principle of Least Knowledge (최소 지식의 원칙) 는 객체지향 프로그래밍에서 객체 간의 상호작용을 제한하여 느슨한 결합 (Loose Coupling) 을 달성하는 설계 원칙이다.

핵심 철학:

• 객체는 자신의 직접적인 " 친구 " 들과만 대화해야 함
• " 낯선 사람 " 과는 대화하지 말아야 함
• 다른 객체의 내부 구조나 속성에 대해 최소한만 가정해야 함

핵심 규칙: 한 메서드는 다음 객체에만 메시지를 보낼 수 있다:

• 자기 자신 (this)
• 메서드 인자 (argument)
• 자신이 생성한 객체
• 자신의 인스턴스 변수

목적 및 필요성

1. 결합도 감소: 컴포넌트 간 상호의존성 최소화
2. 유지보수성 향상: 변경 시 영향 범위 제한
3. 캡슐화 강화: 객체의 내부 구현 은닉
4. 적응성 증대: 요구사항 변경에 대한 유연한 대응
5. 정보 숨김: 불필요한 세부사항 노출 방지

주요 기능 및 역할

• 객체 간 직접적인 상호작용만 허용해 의존성 최소화
• 정보 은닉 (캡슐화) 강화
• 시스템의 안정성 및 유연성 향상

특징

• 느슨한 결합 (Loose Coupling) 지향
• 정보 은닉 (Information Hiding) 강조
• 유지보수성, 확장성, 테스트 용이성 향상

핵심 원칙 및 주요 원리

• " 친구의 친구와는 대화하지 않는다 (Only talk to your immediate friends)".
• 객체의 메서드는 다음과 같은 객체의 메서드만 호출해야 한다:
  • 자기 자신의 메서드
  • 메서드의 매개변수로 전달된 객체의 메서드
  • 자기 자신의 필드로 선언된 객체의 메서드
  • 메서드 내에서 생성된 객체의 메서드
• 객체 체이닝 (Chained Calls) 지양

flowchart TD
    A[Object A] -->|has| B[Object B]
    B -->|has| C[Object C]
    A -.->|"X (위반)"| C
    A -->|"O (준수)"| B

세 가지 핵심 권고사항:

1. 각 단위는 다른 단위에 대해 제한된 지식만 가져야 함
2. 각 단위는 친구들과만 대화해야 함
3. 직접적인 친구들과만 대화해야 함

형식적 정의: 클래스 C 의 메서드 M 은 다음 유형의 객체 메서드만 호출할 수 있다:

• M 의 인수 객체들 (C 자신 포함)
• C 의 인스턴스 변수 클래스들
• M 에 의해 생성된 객체들
• 전역 변수 및 C 의 직접적인 구성 요소 객체들

캡슐화 메커니즘:

flowchart LR
    subgraph "Law of Demeter 준수"
        A1[Object A] -->|"명령/위임"| B1[Object B]
        B1 -->|"내부 처리"| C1[Object C]
    end
    
    subgraph "Law of Demeter 위반"
        A2[Object A] -->|"직접 접근"| B2[Object B]
        A2 -.->|"체이닝 접근"| C2[Object C]
        B2 --> C2
    end

구현 기법

위임자 메서드 (Delegate Methods)

정의: 내부 객체의 기능을 직접 노출하지 않고 래퍼 메서드를 통해 접근
구성: 공개 메서드 → 내부 객체의 비공개 메서드 호출
목적: 내부 구조 은닉과 인터페이스 안정성 확보

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// ❌ Law of Demeter 위반
class OrderProcessor {
    processOrder(order) {
        const street = order.getCustomer().getAddress().getStreet();
        // 깊은 탐색으로 인한 강한 결합
    }
}

// ✅ Law of Demeter 준수 - 위임 메서드 사용
class Order {
    getCustomerStreet() {
        return this.customer.getAddressStreet(); // 위임
    }
}

class OrderProcessor {
    processOrder(order) {
        const street = order.getCustomerStreet(); // 직접 요청
    }
}

명령 패턴 (Command Pattern)

정의: 데이터를 요청하는 대신 수행할 행동을 명령
구성: 명령 객체 → 수신자 객체의 메서드 실행
목적: Tell Don’t Ask 원칙 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// ❌ 데이터 요청 후 처리
class PayrollProcessor {
    calculatePay(employee) {
        const hours = employee.getTimesheet().getHours();
        const rate = employee.getDepartment().getPayRate();
        return hours * rate; // 외부에서 계산
    }
}

// ✅ 행동 명령
class PayrollProcessor {
    calculatePay(employee) {
        return employee.calculatePay(); // 행동 위임
    }
}

인터페이스 분리 (Interface Segregation)

정의: 넓은 인터페이스를 좁고 집중된 인터페이스로 분리
구성: 다중 특화 인터페이스 → 단일 책임 구현
목적: 불필요한 의존성 제거

의존성 주입 (Dependency Injection)

정의: 필요한 객체를 외부에서 주입받아 직접 참조
구성: 생성자/세터 주입 → 직접 의존성 확보
목적: 간접적 의존성 제거

장점과 단점

도전 과제

분류에 따른 종류 및 유형

실무 적용 예시

활용 사례

사례 1: 전자상거래 주문 처리 시스템

시나리오: 온라인 쇼핑몰에서 주문 처리 과정에 Law of Demeter 적용

시스템 구성:

graph TB
    subgraph "Order Processing System"
        OC[Order Controller]
        OS[Order Service]
        O[Order]
        C[Customer]
        P[Payment]
        I[Inventory]
        S[Shipping]
    end
    
    OC -->|"processOrder(orderData)"| OS
    OS -->|"createOrder()"| O
    OS -->|"validatePayment()"| P
    OS -->|"checkInventory()"| I
    OS -->|"arrangeShipping()"| S
    
    O -->|"calculateTotal()"| O
    O -->|"validateCustomer()"| C

Law of Demeter 위반 사례:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// ❌ 위반: 깊은 객체 탐색
class OrderController {
    processOrder(orderData) {
        const customer = orderData.getCustomer();
        const address = customer.getAddress().getStreet(); // 위반
        const paymentMethod = customer.getPayment().getMethod().getType(); // 위반
        const discount = customer.getMembership().getLevel().getDiscount(); // 위반
        
        // 복잡한 결합 관계로 인한 취약한 코드
    }
}

Law of Demeter 준수 개선안:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// ✅ 개선: 책임 위임과 캡슐화
class OrderController {
    processOrder(orderData) {
        const order = this.orderService.createOrder(orderData);
        const result = order.process(); // 단일 진입점
        return result;
    }
}

class Order {
    process() {
        this.validateCustomerEligibility(); // 위임
        this.calculateTotalWithDiscounts(); // 위임
        this.processPayment(); // 위임
        this.reserveInventory(); // 위임
        this.arrangeShipping(); // 위임
        return this.getOrderSummary();
    }
    
    // 각 메서드는 해당 도메인 객체에 위임
    validateCustomerEligibility() {
        return this.customer.validateForOrder();
    }
    
    calculateTotalWithDiscounts() {
        const discount = this.customer.getApplicableDiscount();
        return this.items.calculateTotal(discount);
    }
}

시스템 구성 다이어그램:

sequenceDiagram
    participant Controller
    participant OrderService
    participant Order
    participant Customer
    participant Payment
    participant Inventory
    
    Controller->>OrderService: processOrder(data)
    OrderService->>Order: createOrder()
    Order->>Customer: validateForOrder()
    Customer-->>Order: validation result
    Order->>Payment: processPayment()
    Payment-->>Order: payment result
    Order->>Inventory: reserveItems()
    Inventory-->>Order: reservation result
    Order-->>OrderService: order summary
    OrderService-->>Controller: process result

Workflow:

1. 주문 접수: Controller 가 OrderService 에 주문 처리 요청
2. 주문 생성: OrderService 가 Order 객체 생성 및 초기화
3. 고객 검증: Order 가 Customer 에게 주문 자격 검증 위임
4. 결제 처리: Order 가 Payment 에게 결제 처리 위임
5. 재고 확인: Order 가 Inventory 에게 재고 확보 위임
6. 배송 준비: Order 가 Shipping 에게 배송 준비 위임
7. 결과 반환: 각 단계의 결과를 Controller 에 전달

각 컴포넌트의 역할:

• Order: 주문 프로세스 전체 조율 및 상태 관리
• Customer: 고객 정보 관리 및 자격 검증
• Payment: 결제 수단 관리 및 결제 처리
• Inventory: 재고 관리 및 예약 처리
• Shipping: 배송지 관리 및 배송 일정 수립

사례 2: 전자상거래 시스템에서의 Law of Demeter 적용

시나리오: 전자상거래 플랫폼에서 주문 처리 (Checkout) 를 담당하는 OrderService 클래스가 Customer, Cart, Payment, Shipping 등의 도메인 객체와 상호작용함.

문제 발생 전:

1

customer.getCart().getItems().forEach(i -> i.getProduct().getName());

➡ Law of Demeter 위반 (너무 많은 체이닝)

리팩토링 후:

1

customer.describeCartItems();  // 위임 메서드 도입

시스템 구성:

classDiagram
    class OrderService {
        +checkout()
    }
    class Customer {
        +describeCartItems()
    }
    class Cart {
        +getItems()
    }
    class Item {
        +getProduct()
    }
    class Product {
        +getName()
    }
    OrderService --> Customer : uses
    Customer --> Cart : owns
    Cart --> Item : contains
    Item --> Product : references

Workflow 다이어그램:

sequenceDiagram
    participant OrderService
    participant Customer
    participant Cart
    participant Item
    participant Product

    OrderService->>Customer: describeCartItems()
    Customer->>Cart: getItems()
    Cart->>Item: 각 아이템 반환
    Item->>Product: getProduct()
    Product-->>Item: 이름 반환

담당 역할:

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

하위 주제로 분류한 추가 학습 내용

관련 분야와 추가 학습 내용

용어 정리

참고 및 출처

공식 문서 및 백그라운드

• Law of Demeter - Wikipedia
• Law of Demeter (General Formulation) - Northeastern University

실무 적용 및 자바 기반 예제

• Law of Demeter in Java - Baeldung
• Law of Demeter in Java – GeeksforGeeks
• The Law of Demeter by Example - Paweł Pluta
• The Law of Demeter by Example - Medium

설계 원칙 설명 및 해설

• Demystifying the Law of Demeter - InfoWorld
• The Genius of the Law of Demeter - DZone
• Understanding the Law of Demeter - Test Double
• Law of Demeter - DevIQ
• Law of Demeter (Principle of Least Knowledge) - DEV Community
• Understanding the Law of Demeter and Design Approaches - LinkedIn
• The Law of Demeter Software Design Principle - Pinte.ro

기타 관련 설계 원칙/도구 참고

• Essential Software Design Principles - Design Gurus
• JetBrains - IntelliJ Structural Search
• SonarQube 공식 문서