디자인 모델 - 6 대 원칙 과 분석

디 미트 의 법칙      디자인 모델 의 선 5: 디 미트 법칙 [이 편 은 비교적 알 기 쉽게 썼 다.]
인터페이스 격 리 원칙
 
단일 직책 원칙  [그 중 하 나 는 행동 이 속성 과 관련 이 있어 야 한 다 는 것 이다.]
리 씨 치환 원칙
후진 원칙 에 의존 하 다.
  개폐 원칙
 
나의 평론:
1. 단일 직책 [있어 야 하고 한 가지 원인 으로 인해 발생 하 는 변경]
1. 후진 원칙 (Dependence Inversion Principle) 에 의존 합 니 다. [원 리 는 인 터 페 이 스 를 이용 한 방법 호출 으로 하위 방법 을 수행 하 는 것 입 니 다] DIP 에서 cook 은 만 들 면 먹 을 수 있다 는 뜻 입 니 다. noodles. eat () 이전에 어떤 음식 을 만 드 는 과정의 코드 는 생략 되 었 습 니 다.그리고 나 는 eat 를 beEat 로 바 꾸 어 자연의 의미 에 더욱 가 까 워 질 것 을 건의 합 니 다. 
eat 방법 은 Tutu 에 넣 습 니 다. 그런데 토끼 가 밥 을 하고 밥 을 먹 는 것 을 표현 하려 면 이렇게 됩 니 다. tutu. cook (food); tutu.eat(food); 물론 밥 을 하 는 데 시간 이 걸 리 고 해 야 먹 을 수 있다 면 동기 화: tutu. cook (food, function (food 1) {tutu. eat (food 1)}  리 턴 을 다 하고 나 서 야 먹는다.이렇게 되면 국수 류 는 방법 이 없 으 니 Tutu 로 옮 겨 더욱 추상 적 인 '음식 류' 속성 이 되 는 것 이 좋 습 니 다. 왜냐하면 음식 은 주동 적 인 행동 이 없 기 때 문 입 니 다.예:

function Tutu {
    Foods food=null;
    //      ，   
    function cook(food, callback)
    {
        //do cook
		console.log('    ：'+ food)
        callback(food)
    }
    function eat(food1)
    {
        //do eat
		console.log(' '+food1)
    }
}


function Home {
    tutu = new Tutu();
	tutu.cook('  ');
	tutu.eat('  ');
}

 하 긴 뭘 하고 뭘 먹 는 지, 하지만 음식 은 토끼 의 속성 으로 도 이상 하 다.토끼 는 먹 을 것 이 아니 기 때문에 늘 먹 을 것 을 가지 고 다 니 지 않 아 도 된다. 음식 은 확실히 단독으로 토끼 와 결합 해 야 한다. 앞으로 몇 가지 밥 을 더 끓 여 냉장고 에 넣 으 라 고 하면 Foods 가 할 때 냉장고 동작 을 많이 저장 해 야 한다. 이 동작 은 토끼 류 에 결합 된다. [속성 과 관련 된 방법 은 류 에 있다] 토끼 가 먹 는 물건 이 라 고 해서 항상 냉장 고 를 끌 고 다 닐 수 는 없다. (⊙ ⊙ ⊙ b 땀) cook 이 끝나 면 Foods 의 인 스 턴 스 (어떤 밥) 를 냉장고 에 보관 하면 되 지 않 을 까? 그래서 이전 코드 로 돌아 가 음식 에 저장 방법 (store) 을 추가 하고 앞에서 말 한 eat 를 돌 이 켜 보면 store 와 비슷 하 다 는 것 을 알 수 있 습 니 다. Tutu 류 로 옮 겨 야 합 니까? 그러면 음식 을 Tutu 리 로 옮 길 수 있 는 방법 도 없 지 않 습 니까? 그리고 eat 가 옮 긴 이 유 는 Tutu 에서 나 온 것 입 니 다.
 
2. 인터페이스 격 리
[2.1 클 라 이언 트 는 필요 하지 않 은 인터페이스 에 강제로 의존 해 서 는 안 됩 니 다. (원문 에 의존 한 이래)
2.2 클래스 간 의 의존 관 계 는 최소 인터페이스 에 세 워 져 야 합 니 다 ()]
인터페이스 격 리 원칙 을 완전히 따 르 면 문제 가 발생 할 수 있 습 니 다. 즉, 인터페이스의 디자인 입도 가 점점 작 아 집 니 다.
인터페이스 격 리 원칙 은 단일 직책 원칙 과 비슷 하지만 단일 직책 원칙 이 요구 하 는 것 은 유형 과 인터페이스 직책 이 단일 하고 직책 을 중시 하 며 업무 논리 적 인 구분 이다. 인터페이스 격 리 원칙 은 인터페이스의 방법 이 가능 한 한 적 고 유용 하도록 요구 하 는 것 이다 (한 모듈 에 대한).
 
3. 리 씨 교체: 하위 클래스 의 매개 변수 범위 가 부모 클래스 보다 작 으 면:
f. say (map); / / 부모 클래스 가 실 행 됩 니 다... 하위 클래스 를 호출 하 는 방법 입 니 다. HashMap 형식 으로 들 어 왔 기 때 문 입 니 다.
/ / 그러나 부모 클래스 say 의 매개 변수 유형 맵 이 HashMap 보다 범위 가 넓 기 때문에 부모 클래스 의 say 방법 이 실 행 됩 니 다.
/ / [이 사용 규칙 은: 부모 류 를 사용 하 는 곳 은 하위 클래스 로 교체 할 수 있 습 니 다]
 
s. say (map); / / 하위 클래스 가 실 행 됩 니 다...
 
3. 디 미트 법칙 [친구 들 이 한 논리 에서 본 류 를 너무 많이 사용 하지 못 하 게 하 는 방법 이 있 습 니 다. 이런 논리 가 있 으 면 겉치레 함 수 를 제공 하 는 것 이 좋 습 니 다. (제 가 겉치레 모델 을 빌려 서 말 하면 조합의 몇 가지 함 수 를 하나의 큰 함수 로 합성 하 는 것 입 니 다. 이것 은 RISC 와 유사 한 강력 한 기능 명령 은 몇 가지 기본 명령 의 기능 을 합 쳐 제공 하 는 것 입 니 다)]
예 1. teacher 와 낯 선 girl 은 의존 하지 말고 체육 위원 과 girl 만 의존 하 게 하고 장면 에 이 의존 을 주입 한다. 선생님 은 체육 위원 에 게 학생 수 를 점검 하 라 고 통지 했다. 선생님 은 모든 학생 을 알 필요 가 없다 (girl 류 에 의존 하지 않 는 다). 체육 위원 은 대리 같다.
예 2 에 서 는 위 저 드 의 친구 인 InstallSoftware 가 너무 많이 의존 하면 (InstallSoftware 의 특정한 방법 으로 위 저 드 를 호출 하 는 여러 가지 방법, 이렇게 결합 하 는 것 도 더욱 긴밀 하 다) 위 저 드 의 한 호출 방법 (first) 을 바 꾸 면 전체 블록 호출 에 영향 을 주 고 영향 범위 가 너무 넓다 는 것 을 말한다.
하나의 통 일 된 설치 프로 세 스 방법 (Wizard 리) 에 만 의존 하면 이런 영향 을 받 지 않 습 니 다.결론: 1 대 이상 {집합 more} 에 의존 하 는 것 이 라면 {m} 의 요 소 를 바 꾸 면 전체 {m} 에 영향 을 줄 수 있 습 니 다.
 
6. 개폐 원칙 [확장 개방, 수정 폐쇄]
인 터 페 이 스 를 확장 하여 문제 영역 을 확장 하 다.
 
내 질문:
1. LSP 리 씨 에서 커버 와 리 셋 을 말 했 는데 js 원생 언어 에서 만 덮어 쓸 수 있 음 을 발 견 했 습 니 다 (매개 변수 유형 에 따라 리 셋 을 실현 할 수 없 음). 그러면 리 셋 의 장점 은 어떤 것 이 있 습 니까?
1.1 가장 먼저 생각 나 는 것 은 같은 행위 가 서로 다른 데이터 유형 을 처리 해 야 한 다 는 것 이다.
1.2 에서 말 한 하위 클래스 인 스 턴 스 를 부모 클래스 에서 다시 불 러 오 는 방법 say 와 자신의 방법 say [동명 이인 매개 변수 유형 이 다르다] (예 3 의 뜻 은(예 는 작은 문제 가 있 습 니 다. 부모 클래스 와 하위 클래스 의 say 방법의 매개 변수 유형 을 바 꾼 후에 하위 클래스 는 부모 클래스 say 방법의 매개 변수 유형 으로 전 달 됩 니 다. 본 예 는 과부하 방법 을 잡 아야 합 니 다. 하위 클래스 는 부모 클래스 에서 다시 불 러 오 는 방법 을 사용 해 야 합 니 다. [여 기 는 함수 명 이 같 으 면 모두 say 이 고 매개 변수 유형 이 다 릅 니 다]): 장면 에 HashMap 대상 이 들 어 온 후에 부모 클래스 는 자신의 say 방법 을 호출 합 니 다. 하위 클래스 인 스 턴 스 는 HashMap 유형의 매개 변수 가 들 어 오기 때문에 부모 클래스 에서 다시 불 러 오 는 say 방법 을 호출 합 니 다. 자신의 say (매개 변수 유형 이 다 릅 니 다) 가 아 닙 니 다.이렇게 하면 매개 변수 유형 에 따라 재 부팅 방법 을 결정 할 수 있 습 니 다. 그러나 부모 클래스 에서 재 부팅 되 는 방법 say 의 매개 변 수 는 Map 형식 이 고 하위 클래스 는 오히려 그 범위 보다 작은 HashMap 이 라면 f. say (), s. say () 는 결 과 를 얻 을 수 있 습 니 다. "부류 가 호출 되 었 습 니 다.", "부류 가 호출 되 었 습 니 다." 다음 문장 은 부류 유형 (Map) 의 인자 가 들 어 왔 지만 부류 에서 다시 불 러 오 는 방법 을 실행 하 는 것 이 아니 라 자신의 say 를 실행 하 는 것 입 니 다.)
한 마디 로: 재 부팅 방법의 매개 변수 유형 은 > = 부모 클래스 의 매개 변수 유형 이 어야 합 니 다.