디자인 모델 6 대 원칙 5 - 디 미트 원칙

디 미트 원칙 (최소 지식 원칙)
정의:
디 미트 원칙 은 '최소 지식 원칙' 이 라 고도 부른다.그 의 미 는 한 대상 이 다른 대상 에 대해 가장 적 게 알 고 있다 는 것 이다. 즉, 한 종 류 는 자신 에 대한 결합 이 필요 하 다 는 것 이다.
합 또는 호출 클래스 는 가장 적 게 알 고 있 으 며, 그것 이 제공 하 는 인터페이스 만 알 면 된다.
문제 의 유래: 클래스 와 클래스 간 의 관계 가 밀접 할 수록 결합 도가 크 고 한 클래스 가 변 할 때 다른 클래스 에 대한 영향 도 크다.
해결 방안: 클래스 와 클래스 간 의 결합 을 최대한 낮 춥 니 다.
      디 미트 법칙 은 직접적인 친구 와 만 통신 한 다 는 더 간단 한 정의 도 있다.이른바 직접적인 친구: 모든 대상 은 다른 대상 과 결합 관계 가 있 습 니 다. 두 대상 간 에 결합 관계 가 있 으 면 우 리 는 이 두 대상 간 에 친구 관계 라 고 말 합 니 다.의존, 관련, 조합, 집합 등 결합 방식 이 매우 많다.그 중에서 우 리 는 구성원 변수, 방법 파라미터, 방법 반환 값 에 나타 난 종 류 를 직접적인 친구 라 고 부 르 고 국부 변수 에 나타 난 종 류 는 직접적인 친구 가 아니다.즉, 낯 선 종 류 는 국부 변수의 형식 으로 클래스 내부 에 나타 나 지 않 는 것 이 좋다.
아래 의 코드 는 방법 체 내부 에서 다른 종류 에 의존 하여 디 미트 법칙 을 심각하게 위반 했다.예 를 들 어 선생님 이 체육 위원 에 게 모든 여학생 의 수 를 확인 하 게 하 는 것 이다.

public class Teacher {
	public void commond(GroupLeader groupLeader) {
		List<Girl> listGirls = new ArrayList<Girl>();
		for (int i = 0; i < 20; i++) {
			listGirls.add(new Girl());
		}
		groupLeader.countGirls(listGirls);
	}

}

위의 예 에서 체육 교 사 는 자신 과 직접적인 관계 가 없 는 여학생 류 를 알 게 된 것 은 허용 되 지 않 는 다.
정확 한 방법 은:

public class Teacher {
	public void commond(GroupLeader groupLeader) {
		groupLeader.countGirls();
	}
}

public class GroupLeader {
	private List<Girl> listGirls;
	 
    public GroupLeader(List<Girl> _listGirls) {
        this.listGirls = _listGirls;
    }
 
    public void countGirls() {
        System.out.println("     ：" + listGirls.size());
    }
}

 수정 후 교사 와 여학생 간 강 한 결합 없 이 체육 위원 을 직접 호출 하 는 countGirls ().
    주의: 한 종 류 는 친구 와 만 교류 하고 낯 선 종 류 는 교류 하지 않 습 니 다. getA (). getB (). getC (). getD () 가 나타 나 지 마 십시오.따라서 하나의 방법 은 한 클래스 에 존재 하지 않 는 대상 을 최대한 도입 하지 않 는 다. 물론 JDK API 가 제공 하 는 클래스 는 제외한다.

   친구 사이 에 도 거리 가 있다.하나의 공개 적 인 Public 속성 이나 방법 이 많 을 수록 수정 할 때 관련 된 면 이 크 고 변경 으로 인 한 위험 확산 도 커진다.따라서 친구 클래스 간 의 거 리 를 유지 하기 위해 디자인 할 때 Public 방법 과 속성 을 더 줄 일 수 있 는 지, private, package - private (패키지 유형, 클래스, 방법, 변수 전에 접근 권한 을 추가 하지 않 으 면 기본적으로 패키지 형), proctected 등 접근 권한 으로 수정 할 수 있 는 지, final 키 워드 를 추가 할 수 있 는 지 등 을 반복 적 으로 평가 해 야 한다.주의: 디 미트 법칙 은 '수 줍 음' 과 같은 점 을 요구 합 니 다. 대외 적 으로 너무 많은 Public 방법 과 비 정적 인 Public 변 수 를 발표 하지 말고 최대한 내성 적 이 고 private, package - private, proctected 등 방문 권한 을 많이 사용 합 니 다.

자기 것 이 고 자기 것 이다        만약 에 하나의 방법 이 본 류 에 놓 이면 유형 간 의 관 계 를 증가 하지 않 을 뿐만 아니 라 본 류 에 부정적인 영향 을 미 치지 않 으 면 본 류 에 둔다.

 디 미트 법칙의 사용 에는 한계 가 있다.

       이 는 인터페이스 격 리 원칙 에서 인터페이스의 디자인 이 한계 가 있다 고 언급 한 것 처럼 디 미트 원칙 을 지나치게 사용 하면 이런 중개 와 전달 류 가 대량으로 발생 하여 시스템 의 복잡 도가 커진다.이 사례 에서 우 리 는 체육 위원 그룹 리더 류 를 통 해 전달 되 기 때문에 디 미트 법칙 을 채택 할 때 반복 적 으로 균형 을 잡 아야 한다. 구조 가 뚜렷 할 뿐만 아니 라 내부 집적 과 낮은 결합 도 해 야 한다.