데메터의 법칙

Law of Demeter

최소한의 지식의 법칙(LoD)이나 원칙은 소프트웨어, 특히 객체 지향 프로그램을 개발하기 위한 설계 지침이다.그 일반적인 형태에서 LoD는 느슨한 결합의 특정한 경우다.이 지침은 이안 홀랜드가 1987년 말 노스이스트 대학교에서 제안한 것으로,[1] 다음과 같은 각각의 방법으로 간결하게 요약할 수 있다.[2]

  • 각 단위는 다른 단위에 대한 제한된 지식만 가지고 있어야 한다. 단위는 현재 단위에 "가까이" 관련된다.
  • 각 부대는 친구들에게만 말을 해야 한다. 낯선 사람에게 말을 해서는 안 된다.
  • 가까운 친구들에게만 말하라.

기본적인 개념은 주어진 물체가 "정보 은닉"의 원칙에 따라 다른 어떤 것(그 하위 구성 요소 포함)의 구조나 속성에 대해 가능한 한 적게 가정해야 한다는 것이다.그것은 모듈이 정당한 목적에 필요한 정보와 자원만을 보유함을 지시하는 최소한의 특권 원칙에 대한 귀착물로 볼 수 있다.

그것은 적응형 프로그래밍과 측면 지향형 프로그래밍 노력인 Demeter Project에서 유래된 것으로 그렇게 이름 붙여졌다.이 프로젝트는 데메터, "분배 어머니"와 그리스 농업의 여신을 기리기 위해 이름이 붙여졌는데, 이는 또한 법 자체에 구현되어 있는 프로그래밍의 상향식 철학을 의미하기 때문이다.[citation needed]

역사

이 법은 데메터 프로젝트를 진행하던 이안 홀랜드가 처음 제안했던 1987년으로 거슬러 올라간다.데메터 프로젝트는 많은 AOP(Aspect Oriented Programming) 원칙의 발상지였다.

이 프로젝트의 남은 이름들 중 한 곳에서 인용한 것은 이 이름의 기원을 분명히 하는 것 같다.[3]

농업

그리스 농업의 여신.

데메터 프로젝트는 하드웨어 기술 언어 제우스를 연구하고 있었고 제우스의 구현을 단순화하는 도구를 찾고 있었기 때문에 데메터의 이름을 따서 명명되었다.우리는 제우스와 관련된 도구 이름을 찾고 있었고 제우스의 자매인 데메터를 선택했다.

나중에 우리는 데메터 스타일의 소프트웨어 개발은 소프트웨어를 만드는 것이 아니라 소프트웨어를 키우는 것이라는 생각을 홍보했다.우리는 기본적으로 점점 더 복잡한 UML 클래스 다이어그램의 시퀀스인 성장 계획의 개념을 도입했다.

성장 계획은 시스템을 점진적으로 구축하는 데 유용하다.

객체 지향 프로그래밍에서

물체a개체 인스턴스의 서비스를 요청할 수 있음(메서드 호출)b, 그러나 목적어a사물을 "철저하게" 통과시켜서는 안 된다.b다른 물체에 접근하기 위해c서비스를 요청하기 위해.그렇게 하는 것은 그 물체를 의미할 것이다.a암묵적으로 사물에 대한 더 많은 지식이 필요하다.b의 내부 구조

대신,b의 인터페이스는 필요한 경우 객체에 직접 제공할 수 있도록 수정되어야 한다.a의 요청, 관련 하위 구성 요소에 전파또는,a사물을 직접 언급할 수 있다.c직접 요청해봐법이 지켜지면 오직 목적만 따른다.b자신의 내부 구조를 알고 있다.

좀 더 형식적으로, 기능에 대한 데메터 법칙은 어떤 방법을 필요로 한다.m목적의a다음 종류의 객체의 방법만 호출할 수 있다.[4]

  • a그 자체;
  • m의 매개 변수;
  • 에 인스턴스화된 모든 개체m;
  • a의 속성;
  • 접근 가능한 전역 변수a의 범위 내에서m.

특히 개체는 다른 방법으로 반환된 개체의 메서드를 호출하지 않아야 한다.점을 필드 식별자로 사용하는 많은 현대 객체 지향 언어의 경우, 이 법칙은 간단히 "하나의 점만 사용"이라고 말할 수 있다.즉, 코드a.m().n()법을 어기다a.m()하지 않다비유하자면, 개가 걷기를 원할 때는 개의 다리를 직접 걷도록 명령하지 않고, 대신 개가 자신의 다리를 직접 걷도록 명령한다.

이점

데메터 법칙을 따를 때의 이점은 결과 소프트웨어가 보다 유지보수가 가능하고 적응성이 뛰어난 경향이 있다는 것이다.객체는 다른 객체의 내부 구조에 대한 의존도가 낮기 때문에 호출자를 재작업하지 않고도 객체 구현을 변경할 수 있다.

바실리 외 [5]연구진은 1996년에 낮은 등급의 응답(RFC, 해당 등급의 방법을 호출하는 것에 대응하여 잠재적으로 호출되는 방법의 수)이 소프트웨어 버그 확률을 줄일 수 있다는 실험 결과를 발표했다.데메터의 법칙에 따라 RFC가 낮아질 수 있다.그러나, 그 결과는 또한[6] 클래스당 가중 방법(WMC, 각 클래스에 정의된 방법의 수)의 증가가 소프트웨어 버그 확률을 증가시킬 수 있음을 시사한다.데메터의 법칙에 따라 WMC도 높아질 수 있다.

다층 구조는 소프트웨어 시스템에서 데메터 법칙을 구현하기 위한 체계적 메커니즘으로 간주될 수 있다.계층화된 아키텍처에서, 각 계층 내의 코드는 계층 내의 코드와 아래 계층의 다음 계층 내의 코드에만 호출을 할 수 있다."레이어 건너뛰기"는 레이어드 아키텍처를 위반할 수 있다.

단점들

LoD는 소프트웨어 시스템의 적응성을 증가시키지만, 전화를 구성요소에 전파하기 위해 많은 포장 방법을 써야 하는 결과를 초래할 수 있다. 경우에 따라, 이것은 눈에 띄는 시간과 공간 오버헤드를 추가할 수 있다.[5][7][8]

방법 수준에서 LoD는 좁은 인터페이스로 이어져 각각의 방법이 밀접하게 연관된 개체의 작은 세트에 대해 알 필요가 있기 때문에, 각각의 방법이 그 일을 수행하는 데 필요한 만큼의 정보만 접근할 수 있게 한다.[9]한편, 클래스 레벨에서는 LoD를 올바르게 사용하지 않는 경우, 많은 보조 방법을 도입해야 하는 넓은(즉, 확대된) 인터페이스가 개발될 수 있다.[7][8]이것은 LoD per se의 결과라기보다는 디자인이 형편없기 때문이다.만약 포장지 방법이 사용되고 있다면, 그것은 포장지를 통해 호출되는 물체가 호출 클래스의 종속성이었어야 했다는 것을 의미한다.

확대된 클래스 인터페이스 문제에 대한 해결책 중 하나는 높은 추상화 수준에서 방법의 행동을 하나의 측면으로 지정하는 측면 지향 접근법이다.[10]광범위한 인터페이스는 구현을 지정하는 언어를 통해 관리된다.횡단 전략과 적응형 방문자 모두 운영에 참여하는 최소한의 클래스 집합만 사용하며, 이러한 클래스 간의 연결에 대한 정보는 추상화된다.

참고 항목

참조

  1. ^ Lieberherr, K.J.; Holland, I.M. (September 1989). "Assuring good style for object-oriented programs". IEEE Software. 6 (5): 38–48. doi:10.1109/52.35588. ISSN 0740-7459.
  2. ^ Macedo, Emerson. "README.markdown: Demeter". GitHub. Retrieved 2012-07-05.
  3. ^ "The Demeter Project - What is Demeter?".
  4. ^ Bock, David. "The Paperboy, The Wallet, and The Law Of Demeter" (PDF). College of Computer and Information Science, Northeastern University. p. 5. Retrieved 2012-07-05.
  5. ^ a b Basili, Victor; Briand, L.; Melo, W. L. (October 1996). "A Validation of Object-Oriented Design Metrics as Quality Indicators" (PDF). IEEE Transactions on Software Engineering. 22 (10): 751–761. doi:10.1109/32.544352. hdl:1903/715. As expected, the larger the WMC, the larger the probability of fault detection.
  6. ^ "Weighted Methods per Class - Maisqual Wiki". maisqual.squoring.com. Retrieved 2018-09-20.
  7. ^ a b Appleton, Brad. "Introducing Demeter and its Laws". Retrieved 6 July 2013. 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).
  8. ^ a b "Tell, Don't Ask". The Pragmatic Programmers, LLC. Retrieved 6 July 2013. The disadvantage, of course, is that you end up writing many small wrapper methods that do very little but delegate container traversal and such. The cost tradeoff is between that inefficiency and higher class coupling.
  9. ^ Lieberherr, K.; Holland, I.; Riel, A. (1988). "Object-Oriented Programming: An Objective Sense of Style" (PDF). In Meyrowitz, Norman (ed.). Conference proceedings on Object-oriented programming systems, languages and applications (OOPSLA '88). ACM. pp. 323–334. doi:10.1145/62083.62113. ISBN 978-0897912846. Retrieved 2012-07-05. Easier software maintenance, less coupling between your methods, better information hiding, narrower interfaces, methods which are easier to reuse, and easier correct.ness proofs using structural induction.
  10. ^ Lieberherr, Karl; Orleans, Doug; Ovlinger, Johan (October 2001). "Aspect-oriented programming with adaptive methods". Commun. ACM. 44 (10): 39–40. CiteSeerX 10.1.1.192.6403. doi:10.1145/383845.383855. An adaptive method encapsulates the behavior of an operation into one place, thus avoiding the scattering problem, but also abstracts over the class structure, thus avoiding the tangling problem as well.

추가 읽기

외부 링크