디미터 법칙 (Law of Demeter)이란?

최근 클린코드를 읽던 중 디미터 법칙에 대해 알게 되었습니다. 용어 자체는 생소하긴 한데 법칙의 내용 자체는 크게 어렵지 않고, 평상시 개발에서 흔히 마주칠 수 있는 내용을 다룬 법칙이기 때문에 한번 정리를 해보려고 합니다.

 

디미터 법칙이란?

디미터 법칙(Law of Demeter)은 데메테르 법칙이라고도 불리며 줄여서 LoD라고도 불립니다. 이 법칙은 "최소한의 지식 원칙(The Principle of Least Knowledge)으로 알려져 있으며, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 것을 의미합니다.

실제로 Demeter라는 프로젝트를 진행하던 개발자들은 어떤 객체가 다른 객체에 대해 지나치게 많은 정보를 알고 있다 보니, 서로에 대한 결합도가 높아지고 이로 인해 좋지 못한 설계를 야기한다는 사실을 발견하게 됩니다. 그래서 이를 개선하고자 다른 객체에게 어떠한 자료(내부 구조)를 가지고 있는지 숨기고 함수를 통해 공개하게 만들었는데 이것이 바로 디미터 법칙입니다.

즉, 간단하게 말하면 여러개의 .(dot)을 최대한 사용하지 말라는 법칙으로 말할 수 있으며, 디미터 법칙을 준수하게 되면 캡슐화를 높여 객체의 자율성과 응집도를 높일 수 있습니다. 한번 직접적인 예시를 통해 좀 더 자세히 알아보겠습니다.

 

디미터 법칙 예제

@Getter
public class Employee {

    private final String name;
    private final Enterprise enterprise;
    
    public int getEnterprisePostalCode() {
        return this.enterprise.getAddressPostalCode();
    }

}

@Getter
public class Enterprise {

    private final int employeeNumber;
    private final String domain;
    private final Address address;

    public int getAddressPostalCode() {
        return this.address.getPostalCode();
    }
    
}

@Getter
public class Address {

    private final String street;
    private final int postalCode;
    private final String city;

}

위와 같이 Employee, Enterprise, Address 클래스가 정의되어 있고, 직원이 속한 회사의 우편번호를 검색하려는 경우를 한번 살펴보겠습니다.

public class App {

    public static void main(String[] args) {
        final Address address = new Address("종로구 청와대로 1", 03054, "서울특별시");
        final Enterprise enterprise = new Enterprise(100, "청와대", address);
        final Employee employee = new Employee("안주형", enterprise);

        // 1번 - 디미터 법칙 위반 코드!!
        System.out.println(employee.getEnterprise().getAddress().getPostalCode());

        // 2번 - 디미터 법칙 준수 코드!!
        System.out.println(employee.getEnterprisePostalCode()); 
    }
}

위의 두 로직은 정말 흔하게 볼 수 있는 코드이지만 하나는 디미터 법칙을 위반하는 코드입니다. 둘 다 회사의 우편번호를 얻는 로직이지만 1번의 경우는 2번과 달리 객체에게 우편번호를 얻어오기 위한 메시지를 보내는 것이 아닌 객체가 가지고 있는 자료를 직접 확인하고 있습니다. 따라서 처음에 말했던 문제인 다른 객체가 어떠한 자료를 갖고 있는지 지나치게 잘 알게 됩니다.

2번의 경우는 1번의 코드처럼 여러개의 .(dot)를 사용하여 참조하지 않고, 함수라는 메시지를 통해 자료를 제공받고 있기 때문에 디미터 법칙을 잘 준수하는 코드가 됩니다.

예제 코드 플로우

즉, A에서 C의 정보를 얻어 오기 위한 방법은 C에서 B로, B에서 A로 값을 캡슐화하여 값을 가져오도록 하는 것입니다.

 

예외

단, DTO와 자료구조 같은 경우에는 내부 구조를 외부에 노출하는 것이 당연하므로 디미터 법칙을 적용하지 않습니다. 또한 Java Stream API처럼 메서드 체이닝(method chaining)을 사용하는 경우는 디미터 법칙을 위반하지 않습니다. 디미터 법칙은 결합도와 관련된 이야기이므로, 본질을 잊고 .(dot)에 매몰되어서는 안 됩니다.

 

정리

정리하자면 디미터의 법칙은 객체의 내부 구조를 외부로 드러내지 않는 것이 중요하며 이를 준수하기 위해 객체 간 .(dot)를 최대한 쓰지 않도록 하는 것입니다. 최종적으로 디미터의 법칙을 준수함으로써 객체의 결합도를 낮출 수 있고 변경에 유연하고 유지보수하기 쉬운 코드를 작성할 수 있습니다. 

 

참고

1. https://1kevinson.com/the-law-of-demeter/
2. https://mangkyu.tistory.com/147
3. 클린코드 6장