C\#대상 을 향 한 기본 원칙

C\#대상 을 대상 으로 하 는 기본 원칙 1.인 터 페 이 스 를 대상 으로 하 는 것 이지[Code to an interface rather than to an implementation.]을 실현 하 는 것 이 아니 라[Favor Composition Over Inheritance.]3.SRP:The single responsibility principle 단일 직책 시스템 의 모든 대상 은 하나의 단독 직책 만 있어 야 한다.모든 대상 이 주목 하 는 것 은 자신의 직책 의 완성 이다.Every object in your system should have a single responsibility,and all the object s services should be focused on carrying out that single responsibility.]모든 직책 은 디자인 의 원인 이 고 수요 가 변화 할 때 수요 변 화 는 직책 의 변화 로 반영 된다.시스템 의 대상 이 하나의 변화 원인 만 있 을 때,당신 은 이미 SRP 원칙 을 잘 따 랐 습 니 다.한 가지 직책 이 너무 많 으 면 이런 직책 을 결합 시 키 는 것 과 같다.하나의 직책 의 변 화 는 이러한 다른 직책 의 능력 을 약화 시 키 거나 억제 할 수 있다.이런 디자인 은 취약 한 디자인 을 초래 할 수 있다.변화 가 발생 할 때 디자인 은 예상 치 못 한 파 괴 를 당 할 것 이다.SRP 는 모든 문제 가 한데 얽 힌 것 이 아니 기 때문에 이 시스템 을 더욱 쉽게 관리 하고 유지 할 수 있 습 니 다.내부 집합[Cohesion][사실은 SRP 원칙 의 또 다른 이름 입 니 다.당신 은 내부 집합 소프트웨어 를 썼 습 니 다.사실은 SRP 원칙 을 잘 응용 했다 는 것 입 니 다.4.DRY:Don't repeat yourself Principle 코드 중복 방지 원칙 은 공공 부분 을 추출 하여 한 곳 에 배치 하여 코드 중복 을 피한다.[avoid duplicate code by abstrating out things that are common and placing those thing in a single location.]DRY 는 간단 하지만 우리 코드 가 쉽게 유지 되 고 재 활용 되도록 하 는 관건 이다.중복 코드 를 피 하려 고 노력 하 는 것 은 실제 적 으로 모든 수요 와 기능 이 시스템 에서 한 번 만 실현 되 는 것 을 확보 하 는 것 입 니 다.그렇지 않 으 면 낭비 가 있 습 니 다!시스템 용례 에 교 집합 이 존재 하지 않 기 때문에 우리 의 코드 는 더욱 중복 되 어 서 는 안 된다.이런 측면 에서 볼 때 DRY 는 코드 만 말 하 는 것 이 아니다.DRY 가 주목 하 는 것 은 시스템 내 정보 와 행동 이 단일 하고 뚜렷 한 위치 에 놓 여 있다 는 것 이다.정규 표현 식 이.net 에 있 는 위 치 를 알 수 있 듯 이 합 리 적 이기 때문에 알 아 맞 힐 수 있 습 니 다.DRY 원칙:시스템 기능 에 대해 어떻게 좋 은 분할 을 합 니까?직책 이 뚜렷 한 경 계 는 어느 정도 코드 의 단일 성 을 보장 했다.5.OCP:Open-close Principle 개방 폐쇄 원칙 류 는 수정 에 대해 닫 고 확장 에 대해 열 어야 합 니 다.[Classes should be open for extension,and closed for modification.]OCP 는 유연성 을 주목 합 니 다.변경 은 기 존의 코드 를 변경 하 는 것 이 아니 라 코드 를 추가 하여 진행 합 니 다.OCP 의 응용 은 발생 할 수 있 는 변화 에 한정 되 어 있 습 니 다.추상 적 인 생 성 을 통 해 나중에 발생 할 수 있 는 같은 변화 OCP 원칙 을 격 리 시 켜 이런 사상 을 전달 합 니 다.일 할 수 있 는 코드 를 쓰 면 이 코드 가 계속 작 동 할 수 있 도록 노력 해 야 합 니 다.이것 은 밑줄 이 라 고 할 수 있다.조금 만 요 구 를 높 여 라.일단 우리 의 코드 품질 이 한 수준 에 이 르 면 우 리 는 코드 품질 이 되 돌아 오지 않도록 최선 을 다 해 야 한다.이러한 요 구 는 우리 로 하여 금 한 문제 에 직면 할 때 그럭저럭 해결 하 는 방법 을 사용 하지 않 게 하거나,한 문 제 를 방임 하 는 방식 으로 해결 하 게 한다.예 를 들 어 코드 는 수많은 특정한 데이터 에 대한 처 리 를 추 가 했 고 특 화 된 코드 가 점점 많아 지면 서 코드 의 도 는 모호 해 지고 퇴화 되 기 시작 했다.OCP 뒤의 메커니즘:패키지 와 추상;폐쇄 는 추상 을 바탕 으로 하 는 것 이 고 추상 을 사용 하여 표 시 된 폐쇄 를 얻 는 것 이다.계승 은 OCP 의 가장 간단 한 예 다.하위 화 와 방법 을 제외 하고 우 리 는 더욱 우아 한 방법 으로 조합 을 실현 할 수 있다.어떻게 원본 코드 를 바 꾸 지 않 고 행동 을 바 꿉 니까?답 은 추상 이다.OCP 뒤의 체 제 는 추상 과 다 형 이다.모든 상황 에 적응 할 수 있 는 적절 한 모델 이 없다!반드시 변화 가 있 을 것 이다.완전히 폐쇄 할 수 없다.프로그램의 모든 부분 에 대해 제멋대로 추상 화 하 는 것 은 좋 은 생각 이 아니다.정확 한 방법 은 개발 자가 빈번 한 변화 부분 에 대해 추상 화 하 는 것 이다.미숙 한 추상 을 거부 하 는 것 은 추상 자체 만큼 중요 하 다.OCP 는 OOD 의 많은 설법 의 핵심 이다.만약 에 이 원칙 이 효과적으로 응용 되면 우 리 는 더욱 강 한 유지 가능성 을 얻 을 수 있다.유연성 과 건장 성 LSP 는 OCP 가 가능 한 주요 원칙 중 하나 가 되 는 것 이다.6.LSP:The Liskov substitution principle 리 씨 교체 원칙 자 류 는 반드시 기 류 를 교체 할 수 있어 야 한다.[Subtypes must be substitutable for their base types.]LSP 는 계승 을 어떻게 잘 사용 하 는 지 에 관심 이 있 습 니 다.Method 를 사용 하 는 지 확장 하 는 지 알 아야 합 니 다.하지만 절대 바 꾸 지 않 습 니 다.LSP 는 OOD 의 IS-A 관 계 는 행위 방식 에 있어 행위 방식 은 합 리 적 인 가설 을 할 수 있 고 고객 프로그램 이 의존 하 는 것 이 라 고 분명하게 지적 했다.LSP 는 하나의 모델 이 고립 적 으로 보면 진정한 의미 의 유효성 을 가지 지 못 한 다 는 중요 한 결론 을 내 렸 다.모델 의 유효성 은 클 라 이언 트 프로그램 을 통 해서 만 표현 할 수 있다.디자인 된 사용자 가 내 놓 은 합 리 적 인 가설 에 따라 그것 을 살 펴 봐 야 한다.만약 에 예측 하기 어 려 운 것 이 라 고 가정 하면 디자인 악취 가 날 때 까지 처리 할 수 있다.LSP 위반 에 대해 서도 잠재 적 으로 OCP 위반 이 있 었 다.7.DIP:후진 원칙 에 의존 하 는 고 층 모듈 은 바 텀 모듈 에 의존 해 서 는 안 되 고 추상 은 디 테 일 한 부분 에 의존 하지 말고 추상 에 의존 해 야 한다.무엇이 고 층 모듈 입 니까?고 층 모듈 은 응용 프로그램의 중요 한 전략 선택 과 업무 모델 을 포함한다.이 고 층 모듈 들 은 그 가 있 는 응용 프로그램 을 다른 것 과 구별 시 켰 다.고 층 모듈 이 바 텀 모듈 에 의존 하면 서로 다른 문맥 에서 고 층 모듈 을 다시 사용 하 는 것 이 어려워 진다.그러나 고 층 모듈 이 바 텀 모듈 에 독립 하면 고 층 모듈 은 쉽게 재 활용 된다.이 원칙 은 프레임 디자인 의 핵심 원칙 이다.이곳 의 역 치 는 의존 관계 의 역 치 뿐만 아니 라 인터페이스 소유권 의 역 치 이기 도 하 다.DIP 를 사용 하면 우 리 는 흔히 고객 이 추상 적 인 인 인 터 페 이 스 를 가지 고 서비스 자 는 이런 추상 적 인 인터페이스 에서 파생 된 것 을 발견 할 수 있다.이것 이 바로 유명한 Hollywood 원칙 이다."Don't call us we'll call you."바 텀 모듈 은 고 층 모듈 에서 설명 하고 고 층 모듈 에 의 해 호출 된 인 터 페 이 스 를 실현 했다.역 치 를 통 해 우 리 는 더욱 유연 하고 오래 지속 되 며 쉽게 바 뀌 는 구 조 를 만 들 었 다.DIP 의 간단 한 계발 규칙:추상 에 의존한다.이것 은 간단 한 진술 이다.이 규칙 은 구체 적 인 유형 에 의존 해 서 는 안 된다.즉,프로그램 이 모든 의존 을 추상 적 인 유형 이나 인터페이스 에 재배 해 야 한 다 는 것 이다.만약 한 종류 가 매우 안정 적 이 라면,그것 에 의존 하 는 것 은 상 처 를 주지 않 을 것 이다.그러나 우리 자신의 구체 적 인 유형 은 대부분이 불안정 하 다.그들 을 추상 적 인 인터페이스 뒤에 숨 기 면 불안정 성 을 격 리 할 수 있다.후진 에 의존 하면 다른 유형 에 메 시 지 를 보 내 는 모든 곳 에 응용 할 수 있다.후진 원칙 에 의존 하 는 것 은 대상 을 대상 으로 하 는 기술 이 많이 발표 하 는 장점 을 실현 하 는 기본 적 인 바 텀 체제 이 고 대상 을 대상 으로 하 는 표지 이다.8.ISP:인터페이스 격 리 원칙 은 고객 프로그램 이 필요 하지 않 은 사용 방법 에 의존 하도록 강요 해 서 는 안 된다.인 터 페 이 스 는 높 은 내부 집적 이 아니 라 하나의 인터페이스 가 N 조로 나 눌 수 있 으 므 로 이 인 터 페 이 스 는 ISP 로 처리 해 야 한다.인터페이스의 구분 은 그 를 사용 하 는 클 라 이언 트 프로그램 에 의 해 결정 되 고 클 라 이언 트 프로그램 은 분 리 된 인터페이스 도 분리 되 어야 한다.하나의 인터페이스 에 너무 많은 행 위 를 포함 할 때 그들의 클 라 이언 트 프로그램 간 에 비정상적인 의존 관 계 를 형성 합 니 다.우리 가 해 야 할 일 은 인 터 페 이 스 를 분리 하여 디 결합 을 실현 하 는 것 입 니 다.ISP 를 사용 한 후에 클 라 이언 트 프로그램 은 여러 개의 내 장 된 인 터 페 이 스 를 보 았 다.