학습 노트 1 - 7 대 대상 디자인 원칙

머리말
이번 학습 계획 에 따라 디자인 모델 을 체계적으로 학습 하기 전에 디자인 원칙 을 체계적으로 학습 하고 이해한다.대상 을 대상 으로 설계 하 는 원칙 은 다음 과 같은 몇 가지 가 있다.
원칙 1: 단일 직책 원칙
이것 은 대상 을 대상 으로 하 는 가장 간단 한 원칙 이다. 정의 에 대해 서 는 책 에서 말 한 것 을 인용 한다.
단일 직책 원칙 (Single Responsibility Principle, SRP): 한 가지 유형 은 하나의 기능 분야 에서 해당 하 는 직책 만 담당 하거나 한 가지 유형 에 있어 변 화 를 일 으 키 는 원인 만 있어 야 한다 고 정의 할 수 있다.
여기 서 가장 중요 한 것 은 개인 적 으로 라 는 말 이 라 고 생각 합 니 다.디자인 의 전 제 는 생각 하 는 것 이다. 생각 을 해 야 디자인 이 라 고 할 수 있 기 때문에 실제 디자인 과정 에서 가장 중요 한 것 은 도대체 어떤 것 이 인지 생각 하 는 것 이다. 이것 을 확정 해 야 단일 직책 원칙 을 진정 으로 지 킬 수 있다.
이 원칙 은 최근 에 재 구성 한 기능 디자인 의 문 제 를 떠 올 리 게 한다. 처음에 디자인 이 단일 한 직책 원칙 을 따 르 지 않 았 음 이 분명 하 다.이 기능 은 세 개의 서브 시스템 A, B, C 와 관련 되 어 있 습 니 다. 우 리 는 A 시스템 에서 B 시스템 에 http 요청 을 보 내야 합 니 다. 보 내 는 과정 에서 두 개의 매개 변 수 를 가 져 왔 습 니 다. 하 나 는 구체 적 인 대상 데이터 obj 이 고 하 나 는 동적 으로 얻 은 B 시스템 이 C 시스템 에 요청 한 요청 url 등 관련 정 보 를 보 내 는 것 입 니 다.우 리 는 A 시스템 에 httpService 를 써 서 B 시스템 에 요청 을 보 냈 고 한 방법 에서 이런 세 가지 일 을 동시에 했다.

obj 데이터 대상 봉인;

B 가 C 에 요청 한 요청 정 보 를 동적 으로 가 져 옵 니 다.

B 에 게 정식으로 요청 하기;

분명 한 것 은 이런 방법 은 발송 요청 과 관련 된 일 을 하 는 것 처럼 보이 지만 자세히 분석 해 보면 이 방법 이 바 뀌 는 원인 은 적어도 세 가지 가 있 기 때문에 적어도 이 세 가지 일 을 세 가지 방법 으로 나 누 어 처리 해 야 한다.
원칙 2: 개폐 원칙
개폐 원칙 인용 서 의 정 의 는 다음 과 같다.
개폐 원칙 (Open - Closed Principle, OCP): 하나의 소프트웨어 실 체 는 확장 에 개방 하고 수정 에 대해 닫 아야 합 니 다.즉, 소프트웨어 실 체 는 가능 한 한 기 존 코드 를 수정 하지 않 고 확장 해 야 한 다 는 것 이다.
여기 서 가장 중요 한 것 은 네 글자 이다. 소프트웨어 실체 가 무엇 인지 정확하게 이해 해 야 개폐 원칙 을 잘 사용 할 수 있다. 책 에서 소프트웨어 실체 에 대한 정 의 는 다음 과 같다.
개폐 원칙 의 정의 에서 소프트웨어 실 체 는 하나의 소프트웨어 모듈, 여러 가지 로 구 성 된 부분 구조 또는 독립 된 종 류 를 말 할 수 있다.
개폐 원칙 에 대해 저 는 개인 적 으로 어떤 종 류 를 계승 하거나 실현 할 수 있 고 이런 종 류 를 바탕 으로 기능 을 추가 할 수 있 지만 이런 종 류 를 직접 고 칠 수 없다 는 것 을 이해 합 니 다.그러나 실제 실시 하 는 과정 에서 쉽 지 않 은 것 이 분명 하 다. 이것 은 보통 일정한 개발 공력 이 필요 하고 다른 원칙 을 먼저 지 켜 야 이 원칙 이 실현 가능 할 수 있다.예 를 들 어 위 에서 말 한 단일 직책 원칙 이 단일 직책 원칙 을 잘 따 르 지 않 으 면 각종 기능 이 한데 융합 되 지 않 으 면 후기 에 확대 하 는 과정 에서 잘 개폐 되 기 어 려 울 것 이다.이 럴 때 개방 을 확대 할 수 있 지만 수정 을 닫 을 수 있 는 것 은 아니 며 원래 의 종 류 를 수정 해 야 하 는 경우 가 많 을 수 있 습 니 다.
마찬가지 로 위 에서 예 를 들 어 그 기능 은 단일 직책 원칙 에 따라 우 리 는 세 가지 일 을 세 가지 방법 으로 나 누 어 실현 하 였 으 나 여전히 다른 문제 가 존재 하고 있다.예 를 들 어 패 키 징 데이터 대상 이라는 일 은 여러 업무 가 하나의 요청 을 공용 하기 때문에 매개 변수 개수 가 고정된 상황 에서 서로 다른 업무 데이터 에 사용 되 는 데이터 대상 패 키 징 은 반드시 다 를 것 이다.우리 가 하나의 방법 으로 이 데이터 패 키 징 을 처리 할 때 반드시 몇 개의 if / else 와 같은 판단 문 구 를 사용 해 야 한다. 그러면 나중에 새로운 업무 가 가입 하거나 낡은 업 무 를 수정 해 야 한다 면 반드시 이 방법 과 이런 유형 을 바 꿔 야 하기 때문에 더 좋 은 방법 은 서로 다른 업무 의 서로 다른 데이터 에 대해 서로 다른 방법 이나 유형 을 사용 하여 처리 해 야 한다.
원칙 3: 리 씨 교체 원칙
리 씨 교체 원칙 인용 서 의 정 의 는 다음 과 같다.
리 씨 대체 원칙 (Liskov Substitution Principle, LSP): 모든 참조 기본 클래스 (부모 클래스) 는 하위 클래스 의 대상 을 투명 하 게 사용 해 야 합 니 다.
내 가 현재 기록 하고 있 는 세 가지 원칙 중에서 이것 은 아마 내 가 가장 잘 이해 하고 가장 쉽게 할 수 있 을 것 이 라 고 생각한다. 왜냐하면 평소에 개발 하 는 과정 에서 거의 시시각각 인터페이스 와 실현 류 를 쓰 고 있 기 때문이다.이 원칙 은 간단하게 이해 해 야 한다. 즉, 인터페이스 나 다른 유형의 부모 클래스 로 호출 하 는 모든 방법 은 반드시 이 부모 클래스 의 모든 하위 클래스 로 호출 할 수 있어 야 한다.부모 클래스 를 매개 변수 로 하 는 모든 곳 에서 모든 하위 클래스 를 매개 변수 로 할 수 있 습 니 다.리 씨 교 체 는 부 류 를 자 류 로 대체 하 는 것 으로 이해 할 수 있다.
원칙 4: 반전 원칙 에 의존
반전 원칙 인용 서 의 정 의 는 다음 과 같다.
반전 원칙 에 의존 (Dependency Inversion Principle, DIP): 추상 은 디 테 일 에 의존 해 서 는 안 되 고 디 테 일 은 추상 에 의존 해 야 합 니 다.프로 그래 밍 이 아니 라 인터페이스 프로 그래 밍 을 해 야 한 다 는 얘 기다.
이 원칙 은 이전 원칙 과 언뜻 보기 에는 비슷 한 것 같 지만 자세히 분석 해 보 니 그렇지 않다.리 씨 교체 원칙 은 더욱 구체 적 으로 이해 할 수 있다. 아버지 류 와 자 류 는 각 사용자 정의 에서 지 켜 야 할 원칙 으로 아버지 류 와 자 류 의 정의 에 중점 을 둔다.반전 원칙 에 의존 하 는 것 은 부계 와 자 류 를 어떻게 합 리 적 으로 사용 하 느 냐 에 중점 을 두 고 있다.그러나 이 두 가지 원칙 은 모두 부 류 와 자 류 의 문 제 를 말 하기 때문에 필연 적 인 관계 도 있다. 리 씨 교체 원칙 에 따라 부 류 와 자 류 를 합 리 적 으로 정의 해 야 의존 반전 원칙 을 더욱 합 리 적 으로 따 를 수 있다.따라서 이것 도 하나의 문제 와 관련된다. 자 류 는 문법 적 으로 자신 만 의 대외 개방 방법 이 있 을 수 있 지만 이런 방법 을 제공 해 야 하 는가?분명 한 것 은 후진 원칙 에 완전히 의존 하려 면 자 류 는 자신의 대외 개방 방법 을 정의 해 서 는 안 된다. 그렇지 않 으 면 인터페이스 프로 그래 밍 을 할 때 그 자 류 는 대외 개방 의 독특한 방법 이 장식 이 된다.
원칙 5: 인터페이스 격 리 원칙
인터페이스 격 리 원칙 인용 서 의 정 의 는 다음 과 같다.
인터페이스 격 리 원칙 (Interface Segregation Principle, ISP): 단일 한 총 인 터 페 이 스 를 사용 하지 않 고 여러 개의 전문 인 터 페 이 스 를 사용 합 니 다. 즉, 클 라 이언 트 는 필요 하지 않 은 인터페이스 에 의존 해 서 는 안 됩 니 다.
이 원칙 에 대해 나 는 오히려 그 가 단일 직책 원칙 의 보충 이나 더욱 작은 차원 의 단일 직책 원칙 이 라 고 생각한다. 왜냐하면 인 터 페 이 스 는 실제 적 으로 단일 직책 원칙 에서 말 한 것 으로 이해 할 수 있다 고 생각 하기 때문이다.한편, '하나의 전체 인터페이스 가 아 닌 여러 개의 전문 인 터 페 이 스 를 사용한다' 는 것 은 단일 한 직책 을 직접적 으로 나타 낸다. 다만 여 기 는 더욱 작은 차원 의 단일 한 직책 일 수 있다. 그 목적 은 하나의 인터페이스 에 너무 많은 기능 이 그의 클 라 이언 트 에 의존 하여 불필요 한 일 을 하 는 것 을 피하 기 위해 서 이다.그러면 앞의 두 가지 원칙 을 결합 하면 저 는 그들 이 하나의 전체 라 고 생각 합 니 다. 먼저 리 씨 교체 원칙 은 아버지 류 와 자 류 가 어떤 관계 로 정 의 를 내 려 야 하 는 지 요약 한 다음 에 반전 원칙 에 의존 하여 아버지 류 와 자 류 를 어떻게 사용 해 야 하 는 지 설명 한 다음 에 이곳 의 인터페이스 격 리 원칙 은 아버지 류 인터페이스 가 어떻게 더 좋 은 정 의 를 내 려 야 하 는 지 구체 적 으로 설명 합 니 다.
원칙 6: 합성 복용 원칙
합성 복용 원칙 인용 서 의 정 의 는 다음 과 같다.
합성 재 활용 원칙 (Composite Reuse Principle, CRP): 계승 이 아 닌 대상 조합 을 사용 하여 재 활용 의 목적 을 달성 하도록 한다.
제 이해 에 따 르 면 재 활용 은 보통 자신 이 갖 추 지 못 한 방법 을 말 하지만 가 져 와 서 사용 할 수 있 고 실현 방식 은 조합, 집적 과 계승 을 말 합 니 다.계승 이란 부계 에 쓰 인 방법 이 자 류 에 의 해 계승 되면 자 류 는 이 방법 을 다시 한 번 쓰 지 않 아 도 자 류 의 대상 을 호출 할 수 있다 는 것 을 말한다.조합 이란 한 종 류 를 성명 할 때 다른 종 류 를 속성 적 인 방식 으로 성명 한 다음 에 이런 유형의 대상 에 그 유형의 대상 을 포함 한 다음 에 이런 유형의 대상 에서 그 유형의 방법 을 호출 하여 자신 이 정의 하지 않 고 특정한 기능 을 실현 할 수 있다 는 것 을 말한다.취 합 은 보통 다른 유형의 대상 을 매개 변수 로 전달 한 다음 에 이런 대상 의 방법 에서 도 매개 변수 대상 을 호출 하 는 방법 을 말한다. 그러면 자신 이 정의 하지 않 지만 특정한 기능 을 실현 할 수 있다.상기 세 가지 방식 은 모두 코드 와 기능 을 실현 할 수 있 는 복 영 으로 중복 코드 를 줄 일 수 있 으 나 계승 은 클래스 의 패 키 징 성 을 파괴 하고 부모 류 의 실현 디 테 일 을 하위 클래스 에 노출 시 킬 수 있다. 또한 부모 류 가 계승 할 수 없다 고 성명 하면 재 활용 할 수 없다. 이런 것들 은 모두 필요 하지 않 고 계승 재 활용 을 권장 하지 않 는 이유 이다.반면 조합 과 취 합 은 더욱 유연 하고 구체 적 인 실현 도 다른 조합의 유형 에 노출 되 지 않 기 때문에 조합 과 취 합 을 이용 하여 코드 와 기능 의 재 활용, 즉 합성 재 활용 원칙 을 실현 하 는 것 을 권장 한다.
원칙 7: 디 미트 법칙
디 미트 법칙 인용 서 의 정 의 는 다음 과 같다.
디 미트 법칙 (Law of Demeter, LoD): 하나의 소프트웨어 실 체 는 가능 한 한 다른 실체 와 상호작용 을 적 게 해 야 한다.
디 미트 법칙 은 최소 지식 원칙, 최소 알 기 원칙 이 라 고도 부른다. 말하자면 하나의 유형 에서 정 의 된 속성, 방법 등 은 방문 권한 을 엄 격 히 정의 하고 반드시 드 러 내야 하 는 것 만 드 러 내야 하 며 사유 가 드 러 날 필요 가 없다.이렇게 해 야 하 는 이 유 는 한 가지 내용 이 외부 에 너무 많이 노출 될 때 한편 으로 는 그의 변 화 를 일 으 키 는 요소 가 많아 지고 상황 이 복잡 해 지 며 다른 한편 으로 는 이런 유형 을 사용 할 때 선택 하 는 어려움 을 초래 하기 때문이다.