데메테르의 법칙

**데메테르의 법칙**(Law of Demeter, **LoD**) 또는 **최소 지식 원칙**(principle of least knowledge)은 소프트웨어, 특히 객체 지향 프로그램 개발을 위한 디자인 가이드라인이다. 일반적인 형태로 LoD는 느슨한 결합의 특정 사례이다. 이 가이드라인은 이안 홀랜드(Ian Holland)가 1987년 말 노스이스턴 대학교에서 제안했으며,url-access=subscription 다음 세 가지 권고사항이 간결한 요약으로 제공된다.access-date=2012-07-05 # 각 단위는 다른 단위에 대해 제한된 지식만을 가져야 한다: 현재 단위와 "밀접하게" 관련된 단위만 해당한다. # 각 단위는 친구와만 대화해야 한다. (낯선 사람과 대화하지 말라.) # 즉각적인 친구와만 대화하라. 근본적인 개념은 주어진 객체가 "정보 은닉" 원칙에 따라 다른 어떤 것(자신의 하위 구성요소 포함)의 구조나 속성에 대해 가능한 한 적게 가정해야 한다는 것이다. 이는 모듈이 합법적인 목적을 위해 필요한 정보와 리소스만을 소유해야 한다고 규정하는 최소 권한의 원칙의 결과로 볼 수 있다. 이는 적응형 프로그래밍 및 관점 지향 프로그래밍 노력인 데메테르 프로젝트에서 유래하여 명명되었다. 이 프로젝트는 "분배의 어머니"이자 농업의 그리스 여신인 데메테르를 기리기 위해 명명되었는데, 이는 법칙 자체에도 구현된 상향식 프로그래밍 철학을 의미한다.website=www.khoury.northeastern.edu
# 역사
데메테르의 법칙은 1987년 데메테르 프로젝트에서 일하던 이안 홀랜드(Ian Holland)가 처음 제안했다. 이 프로젝트는 많은 관점 지향 프로그래밍(AOP) 원칙의 발상지였다. 프로젝트의 남은 부분 중 한 인용문은 이름의 유래를 명확히 하는 것 같다:title=The Demeter Project - What is Demeter? text=**데메테르** 그리스 농업의 여신. 데메테르 프로젝트는 우리가 제우스(Zeus)라는 하드웨어 기술 언어를 작업하고 있었고, 제우스의 구현을 단순화할 도구를 찾고 있었기 때문에 데메테르의 이름을 따서 명명되었습니다. 우리는 제우스와 관련된 도구 이름을 찾고 있었고, 제우스의 자매인 데메테르를 선택했습니다. 우리는 나중에 데메테르 스타일의 소프트웨어 개발이 소프트웨어를 구축하는 것이 아니라 성장시키는 것이라는 아이디어를 홍보했습니다. 우리는 본질적으로 점점 더 복잡한 UML 클래스 다이어그램의 시퀀스인 성장 계획(growth plan)이라는 개념을 도입했습니다. 성장 계획은 시스템을 점진적으로 구축하는 데 유용합니다.
# 객체 지향 프로그래밍에서
객체 `a`는 객체 인스턴스 `b`의 서비스(메서드 호출)를 요청할 수 있지만, 객체 `a`는 객체 `b`를 "통해" 또 다른 객체 `c`에 접근하여 서비스를 요청해서는 안 된다. 이렇게 하면 객체 `a`가 객체 `b`의 내부 구조에 대한 더 큰 지식을 암묵적으로 요구하게 된다는 의미이다. 대신, `b`의 인터페이스는 필요한 경우 수정되어 객체 `a`의 요청을 직접 처리하고, 관련 하위 구성요소로 전파할 수 있어야 한다. 또는 `a`가 객체 `c`에 대한 직접 참조를 가지고 직접 요청할 수도 있다. 이 법칙을 따르면 객체 `b`만이 자신의 내부 구조를 안다. 더 공식적으로, 함수에 대한 데메테르의 법칙은 객체 `a`의 메서드 `m`이 다음 종류의 객체 메서드만 호출할 수 있도록 요구한다:access-date = 2012-07-05 * `a` 자체 * `m`의 매개변수 * `m` 내에서 인스턴스화된 모든 객체 * `a`의 속성 * `m`의 범위 내에서 `a`가 접근할 수 있는 전역 변수. 특히, 객체는 다른 메서드가 반환한 객체의 메서드를 호출하는 것을 피해야 한다. 필드 식별자로 점(dot)을 사용하는 많은 최신 객체 지향 언어의 경우, 이 법칙은 단순히 "점 하나만 사용하라"고 명시될 수 있다.lccn=2018939833 즉, `a.m()`이 아닌 `a.m().n()` 코드는 법칙을 위반한다. 비유하자면, 개를 걷게 하고 싶을 때 개의 다리에 직접 걸으라고 명령하지 않고, 개에게 명령하면 개가 자신의 다리에 명령하는 것과 같다.
# 장점
데메테르의 법칙을 따르는 것의 장점은 결과적으로 만들어지는 소프트웨어가 더 유지보수하기 쉽고 적응성이 높아진다는 것이다. 객체들이 다른 객체의 내부 구조에 덜 의존적이므로, 객체 구현을 호출자를 재작업하지 않고도 변경할 수 있다. 바실리(Basili) 등은hdl-access=free 1996년에 클래스에 대한 응답(RFC, 해당 클래스의 메서드를 호출할 때 잠재적으로 호출되는 메서드 수)이 낮으면 소프트웨어 버그 발생 확률이 감소할 수 있음을 시사하는 실험 결과를 발표했다. 데메테르의 법칙을 따르면 RFC가 낮아질 수 있다. 그러나 그 결과는 또한 클래스당 가중 메서드 수access-date=2018-09-20(WMC, 각 클래스에 정의된 메서드 수)가 증가하면 소프트웨어 버그 발생 확률이 증가할 수 있음을 시사한다. 데메테르의 법칙을 따르면 WMC도 높아질 수 있다. 다층 아키텍처는 소프트웨어 시스템에서 데메테르의 법칙을 구현하기 위한 체계적인 메커니즘으로 간주될 수 있다. 계층형 아키텍처에서 각 계층 내의 코드는 해당 계층 내의 코드와 다음 하위 계층 내의 코드만 호출할 수 있다. "계층 건너뛰기"는 계층형 아키텍처를 위반한다.
# 단점
LoD는 소프트웨어 시스템의 적응성을 높이지만, 호출을 구성 요소로 전파하기 위해 많은 래퍼 메서드를 작성해야 할 수 있으며, 경우에 따라 이는 상당한 시간 및 공간 오버헤드를 추가할 수 있다.quote=A side-effect of this is that if you conform to LoD, while it may quite increase the maintainability and "adaptiveness" of your software system, you also end up having to write lots of little wrapper methods to propagate methods calls to its components (which can add noticeable time and space overhead).url-status=dead 메서드 수준에서 LoD는 좁은 인터페이스를 제공하며, 각 메서드는 밀접하게 관련된 객체의 소수의 메서드에 대해서만 알아야 하므로 작업을 수행하는 데 필요한 만큼의 정보만 접근할 수 있다.s2cid = 562521 반면에 클래스 수준에서 LoD를 올바르게 사용하지 않으면 많은 보조 메서드를 도입해야 하는 넓은(즉, 확장된) 인터페이스가 개발될 수 있다. 이는 LoD 자체의 결과라기보다는 잘못된 설계 때문이다. 래퍼 메서드가 사용되고 있다면, 래퍼를 통해 호출되는 객체가 호출 클래스의 의존성이어야 했음을 의미한다. 확장된 클래스 인터페이스 문제에 대한 한 가지 제안된 해결책은 관점 지향 접근 방식이다.s2cid = 2792493 여기서 메서드의 동작은 높은 추상화 수준에서 관점(aspect)으로 지정된다. 넓은 인터페이스는 구현을 지정하는 언어를 통해 관리된다. 순회 전략과 적응형 방문자 모두 작업에 참여하는 최소한의 클래스 집합만을 사용하며, 이들 클래스 간의 연결 정보는 추상화된다.
# 추가 자료
참고 자료 시작 *s2cid=12651917 *isbn=978-0534946029 *isbn=978-0-13-211917-7 *author-link=Craig Larman (from this book, "Law of Demeter" is also known as "Don't talk to strangers") *author-link=Steve McConnell *last3=Bogard 참고 자료 끝