디자인 모델 - 최소 지식 원칙
최소 지식 원칙 (Least Knowledge Principle), 최소 지식 원칙 (Least Knowledge Principle) 또는 디 미트 법칙 (Law of Demeter) 은 대상 프로그램 을 대상 으로 설계 한 지도 원칙 으로 코드 의 느슨 한 결합 을 유지 하 는 전략 을 묘사 했다.간단하게 요약 하면:
Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
각 단원 은 다른 단원 에 대해 유한 한 지식 만 가지 고 현재 단원 과 밀접 한 관 계 를 가 진 단원 만 이해한다.
좀 더 간결 하 게:
Each unit should only talk to its friends; don't talk to strangers.
각 단원 은 그의 '친구' 와 만 이 야 기 를 나 눌 수 있 고 '낯 선 사람' 과 이 야 기 를 나 눌 수 없다.
좀 더 간결 하 게:
Only talk to your immediate friends.
자신의 직접적인 친구 와 만 이 야 기 를 나누다.
대상 을 대상 으로 하 는 프로그램 디자인 에 응용 할 때 '류 는 협력 류 와 상호작용 을 해 야 하지만 그들의 내부 구 조 를 이해 할 필요 가 없다' 고 묘사 할 수 있다.
A class should interact directly with its collaborators and be shielded from understanding their internal structure.
디 미트 법칙 (Law of Demeter) 은 Northeastern University 의 Ian Holland 가 1987 년 에 'Law of Demeter' 라 는 명칭 은 당시 진행 중인 연구 인 'The Demeter Project' 에서 나 온 것 이 라 고 주장 했다.
Demeter = Greek Goddess of Agriculture; grow software in small steps.
2004 년 에 Karl Lieberherr 는 논문 'Controlling the Complexity of Software Designs' 에서 LoD 의 정 의 를' Only talk to your friends' 에서 다음 과 같이 개선 했다.
Only talk to your friends who share your concerns.
개 선 된 원칙 은 LoDC (Law of Demeter for Concerns) 라 고 하 는데 소프트웨어 디자인 에 두 가지 주요 한 이점 을 가 져 왔 다.
It leads to better information hiding.
It leads to less information overload.
더 좋 은 정 보 를 숨 기 고 더 적은 정 보 를 다시 불 러 오 는 것 이다.LoDC 원칙 은 지향 적 인 소프트웨어 개발 (AOSD: Aspect - Oriented Software Development) 에서 좋 은 응용 을 하고 있다.
최소 지식 원칙 이 대상 프로 그래 밍 에서 의 응용
'Law of Demeter' 를 대상 프로 그래 밍 에 적용 할 때 'LoD - F: Law of Demeter for Functions / Methods' 라 고 약칭 할 수 있다.
대상 O 의 한 방법 m, m 방법 은 다음 과 같은 유형의 대상 에 만 접근 할 수 있 습 니 다.
구체 적 으로 대상 은 가능 한 한 다른 방법 으로 돌아 오 는 대상 을 호출 하 는 방법 을 피해 야 한 다 는 것 이다.
현대 대상 을 대상 으로 하 는 프로 그래 밍 언어 는 보통 '.' 를 방문 표지 로 사용 하 는데 LoD 는 '한 점 만 사용 (use only one dot)' 으로 간략화 할 수 있다.즉, 코드 a. b. Method () 는 LoD 를 위 반 했 고 a. Method () 는 LoD 에 부합 했다.예 를 들 어 사람 은 개 에 게 걸 으 라 고 명령 할 수 있 지만 개의 다 리 를 직접 지휘 해 서 는 안 되 고 개가 다 리 를 지휘 해 야 한다.
너 는 아래 와 같은 코드 를 본 적 이 있 니?
public Emailer(Server server) {…} // taking a server in the constructor
public void sendSupportEmail(String message, String toAddress) {
EmailSystem emailSystem = server.getEmailSystem();
String fromAddress = emailSystem.getFromAddress();
emailSystem.getSenderSubsystem().send(fromAddress, toAddress, message);
}위의 이 디자인 에는 몇 가지 문제 가 있다.
위의 이 몇 가지 문제 외 에 또 하나의 문 제 는 이 코드 가 테스트 할 수 있 는 것 입 니까?이 종 류 는 의존 주입 (Dependency Injection) 을 사 용 했 기 때문에 서버, Email System, Sender 류 를 모 의 할 수 있 습 니 다.그러나 진짜 문 제 는 이러한 아 날로 그 코드 를 제외 하고 API 에 대한 수정 은 모든 테스트 사례 를 파괴 하고 디자인 과 테스트 를 매우 취약 하 게 만 드 는 것 이다.
상기 문 제 를 해결 하 는 방법 은 최소 지식 원칙 을 응용 하고 구조 함수 만 을 통 해 직접 의존 하 는 대상 을 주입 하 는 것 이다.Emailer 는 서버 클래스 에 Email System 이 포함 되 어 있 는 지 알 필요 도 없고, Email System 에 Sender 가 포함 되 어 있 는 지도 모른다.
public Emailer(Sender sender, String fromAddress) {…}
public void sendSupportEmail(String message, String toAddress) {
sender.send(fromAddress, toAddress, message);
}이 설 계 는 비교적 합리적이다.현재 Emailer 는 서버 와 Email System 에 의존 하지 않 고 구조 함 수 를 통 해 모든 의존 항목 을 얻 었 습 니 다.이 동시에 Emailer 도 이해 하기 쉬 워 졌 다. 왜냐하면 모든 상호작용 대상 이 명시 적 으로 나타 나 기 때문이다.
Emailer 와 Server, Email System 도 결합 을 이해 하 는 효과 가 있 습 니 다.Emailer 는 서버 와 Email System 의 내부 구 조 를 알 필요 가 없고 서버 와 Email System 에 대한 수정 은 Emailer 에 영향 을 주지 않 습 니 다.
그리고 이 메 일 러 는 더 쉽게 재 활용 된다.다른 환경 으로 전환 할 때 하나의 다른 Sender 만 실현 하면 된다.
테스트 에 있어 서 지금 우 리 는 Sender 의존 을 모 의 하면 된다.
최소 지식 원칙 의 장점 과 단점 을 활용 하 다.
장점: Law of Demeter 를 준수 하면 모듈 간 의 결합 을 낮 추고 소프트웨어 의 유지보수 성과 중용 성 을 향상 시킨다.
단점: Law of Demeter 를 응용 하면 클래스 에서 중간 에 사용 할 포장 방법 (Wrapper Method) 을 많이 디자인 해 야 하기 때문에 클래스 디자인 의 복잡 도 를 높 일 수 있다.
참고 자료
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
