소프트웨어 디자인 7 대 원칙

소프트웨어 디자인 에서 시스템 의 유지 가능성 과 재 활용 성 을 어떻게 향상 시 키 는 지 는 대상 디자인 을 대상 으로 해결 해 야 할 핵심 문제 중 하나 이다.대상 을 대상 으로 디자인 하 는 원칙 은 유지 가능성 과 재 활용 성 을 실현 하 는 기초 로 모든 원칙 은 대상 을 대상 으로 디자인 하 는 사상 을 포함 하고 서로 다른 시각 에서 소프트웨어 구조의 디자인 수준 을 향상 시 킬 수 있다.이런 원칙 은 많은 디자인 모델 을 포함 하고 우리 가 디자인 모델 의 사용 효 과 를 평가 하 는 중요 한 기준 중 하나 이다.
1. 개방 폐쇄 원칙
확장 에 대한 개방 이 고 수정 에 대한 폐쇄 입 니 다.그것 은 모든 대상 지향 원칙 의 핵심 이다.소프트웨어 디자인 이 추구 하 는 것 은 재 활용 을 확대 하고 포장 이 디 테 일 을 실현 하 며 결합 도 를 낮 추 는 것 이다. 개방 폐쇄 원칙 은 이 목 표를 실현 하 는 가장 직접적인 표현 이다.(1) 개방, 기능 이나 수요 에 대한 확장 개방, 새로운 수요 나 변화 가 있 을 때 기 존의 프로그램 코드 에 따라 확장 하여 새로운 요구 에 적응 할 수 있 습 니 다.(2) 폐쇄 는 일단 설계 가 완성 되면 독립 적 으로 일 할 수 있 고 그 어떠한 수정 도 할 수 없다 는 것 을 의미한다.
2, 단일 직책 원칙
한 가지 직책 만 맡 는 다 는 것 은 이해 하기 쉽다.한 가지 유형 에 대해 맡 은 직책 이 많 을 수록 재 활용 될 가능성 이 적다.만약 에 이런 직책 이 많다 면 이런 직책 이 결합 되 었 다 는 것 을 의미한다. 만약 에 그 중의 한 직책 이 변화 하면 다른 직책 의 처리 에 영향 을 줄 수 있다.
3. 리 식 교체 원칙
리 씨 대리 교체 원칙 은 2008 년 투 령 상 수상자, 미국 최초의 컴퓨터 과학 여 박사 인 바 바라 리 스 코 프 교수 와 카 네 기 메 론 대 제 안 넷 윙 교수 가 제시 한 것 이다. 각 유형 이 S 인 대상 o1 이면 유형 이 T 인 대상 o 2 가 있 고 T 로 정 의 된 모든 프로그램 P 가 모든 대상 o 1 에서 o 2 를 교체 할 때프로그램 P 의 행동 은 변 하지 않 았 습 니 다. 그러면 유형 S 는 유형 T 의 하위 유형 입 니 다.이런 묘 사 는 이해 하기 어렵다. 다시 말 하면 더욱 통속 적 이 고 이해 하기 쉬 운 해석 은 모든 기본 클래스 가 나타 나 는 곳 은 하위 클래스 로 교체 할 수 있 고 하위 클래스 는 부모 클래스 의 기능 을 확장 할 수 있 으 나 부모 클래스 의 원래 기능 을 바 꿀 수 없다 는 것 이다.기본 대상 이 나타 나 는 곳 은 하위 대상 이 반드시 나타 날 수 있 지만 반대로 는 안 된다 는 것 이다.예 를 들 어 내 가 차 를 좋아 한 다 는 것 은 내 가 자전 거 를 좋아 한 다 는 것 을 의미 하지만 반대로 꼭 그렇지 는 않다. 왜냐하면 내 가 자전 거 를 좋아한다 고 해서 모든 차 를 좋아 하 는 것 은 아니 기 때문이다.
4, 인터페이스 격 리 원칙
두 가지 의미 가 있다. (1) 고객 이 어떤 인 터 페 이 스 를 필요 로 하 는 지, 어떤 인 터 페 이 스 를 제공 하 는 지, 필요 하지 않 은 것 은 삭제 하 는 것 이다.(2) 클래스 간 의 의존 관 계 는 최소 인터페이스 에 세 워 야 한다.인터페이스 에 있 는 방법 은 최대한 적 게 하고 인터페이스 기능 은 최대한 세분 화해 야 한 다 는 것 이다.
5, 거꾸로 원칙 에 의존
역전 원칙 에 의존 하 는 것 은 추상 에 의존 하고 실현 에 의존 하지 않 는 것 이다.고 층 모듈 은 바 텀 모듈 에 의존 하지 않 고 이들 은 모두 추상 에 의존한다.추상 은 세부 사항 에 의존 하지 않 고 세부 사항 은 추상 에 의존 해 야 한다.(Abstractions should not depend upon details. Details should depend uponabstractions.) 인 터 페 이 스 를 대상 으로 프로 그래 밍 을 해 야 합 니 다. 프로 그래 밍 을 실현 하지 마 십시오.(Program to an interface, not an implementation.) 즉, 인터페이스 와 추상 류 를 사용 하여 변수 유형 성명, 매개 변수 유형 성명, 방법 반환 유형 설명, 데이터 형식의 변환 등 을 해 야 한다.구체 적 인 클래스 로 변수의 유형 성명, 매개 변수 유형 성명, 방법 반환 유형 설명, 데이터 형식의 전환 등 을 하지 마 십시오.이 를 위해 구체 적 인 유형 은 인터페이스 와 추상 류 에서 밝 힌 방법 만 실현 하고 불필요 한 방법 을 제시 하지 말 아야 한다.
전통 적 인 과정 적 시스템 의 디자인 방법 은 높 은 차원 의 모듈 을 낮은 차원 의 모듈 에 의존 시 키 고 추상 적 인 차원 은 구체 적 인 차원 에 의존 하 는 경향 이 있다.반전 원칙 은 바로 이 잘못된 의존 관 계 를 반전 시 키 는 것 이다.
대상 을 대상 으로 디자인 하 는 중요 한 원칙 은 추상 화 를 만 들 고 추상 화 에서 구체 화 를 도 출하 며 구체 화 는 서로 다른 실현 을 하 는 것 이다.계승 관 계 는 추상 화 에서 구체화 까지 의 도 출 이다.
추상 층 에 포 함 된 것 은 응용 시스템 의 비 즈 니스 논리 와 거시적인 것 이 고 전체 시스템 에 있어 중요 한 전략 적 결정 이 며 필연 적 인 표현 이다.구체 적 인 차원 은 일부 부차적인 실현 과 관련 된 알고리즘 과 논리, 그리고 전술 적 결정 을 포함 하고 상당 한 우연성 선택 을 가진다.구체 적 인 차원 의 코드 는 자주 변동 되 기 때문에 오류 가 발생 하 는 것 을 피 할 수 없다.
재 활용 의 측면 에서 볼 때 고 차원 의 모듈 은 재 활용 해 야 하 는 것 이 고 재 활용 의 중심 이다. 왜냐하면 응용 시스템 의 가장 중요 한 거시적인 비 즈 니스 논 리 를 포함 하고 비교적 안정 적 이기 때문이다.한편, 전통 적 인 과정 적 디자인 에서 재 활용 은 구체 적 인 차원 모듈 의 재 활용 에 중심 을 둔다.
반전 원칙 에 의존 하 는 것 은 전통 적 인 과정 적 디자인 방법 에 대한 '반전' 이 고 고 차원 모듈 의 재 활용 과 유지 가능성 에 대한 효과 적 인 규범 이다.
특례: 대상 의 설립 과정 은 '개 - 폐' 원칙 과 반전 원칙 에 위배 되 지만 공장 모델 을 통 해 대상 의 설립 과정 에서 의 의존 반전 문 제 를 잘 해결 할 수 있다.

        ：http://www.cnblogs.com/temptation/archive/2008/03/10/1098351.html

6, 디 미트 의 법칙
디 미트 의 법칙 은 최소 지식 원칙 이 라 고도 할 수 있다.자신 이 의존 하 는 유형 에 대해 아 는 것 이 적 을 수록 좋다. 의존 하 는 유형 에 대해 논 리 를 실현 하 는 것 이 어떻든 간 에 이런 논 리 를 자신의 범위 에 밀봉 하고 대외 적 으로 Public (proctected 는 하위 클래스 방문) 방법 으로 서 비 스 를 제공 할 수 있다. 그렇지 않 으 면 외부 에서 어떠한 정보 도 누설 하지 않 는 다. 이것 은 데이터 의 비밀 성 을 나타 낸다.
7, 조합 / 집합 복용 원칙
쉽게 말 하면 대상 의 조합 / 취 합 을 최대한 사용 하 는 것 이지 계승 이 아 닌 재 활용 의 목적 을 달성 하 는 것 이다.
조합 과 집합 은 모두 대상 모델 링 에서 관련 관계 의 일종 이다.취 합 은 전체 와 부분의 관 계 를 나타 내 고 '포함' 을 나타 내 며 전 체 는 일부 조합 으로 이 루어 지고 일 부 는 전체 에서 벗 어 나 독립 된 개체 로 서 존재 할 수 있다.조합 은 더욱 강 한 집합 으로 일부 가 전 체 를 구성 하고 분할 할 수 없 으 며 일 부 는 전체 에서 벗 어 나 단독으로 존재 할 수 없다.합성 관계 에서 부분 은 전체적인 생명주기 와 마찬가지 로 조합의 새로운 대상 은 그들의 창설 과 폐 기 를 포함 하여 그 구성 부분 을 완전히 지배한다.하나의 합성 관계 에서 성분 대상 은 다른 합성 관계 와 공유 할 수 없다.

     /                   ，            /  ，     。                  ，                     ，               ，         。



                   ；                    ；                 ，                 ；                ，      ；             ，                    ，       ；      ，      /                。

디자인 원칙 에 대한 소개 가 많 습 니 다. 다음 링크 를 추천 합 니 다.
개폐 원칙:http://blog.csdn.net/lovelion/article/details/7537584
단일 직책 원칙:http://blog.csdn.net/lovelion/article/details/7536542
내부 교체 원칙:http://blog.csdn.net/lovelion/article/details/7540445
인터페이스 격 리 원칙:http://blog.csdn.net/lovelion/article/details/7562842
후진 원칙 에 의존:http://blog.csdn.net/lovelion/article/details/7562783
디 미트 의 법칙:http://blog.csdn.net/lovelion/article/details/7563445
조합 / 집합 원칙:http://blog.csdn.net/lovelion/article/details/7563441
디자인 모델 6 대 원칙:http://www.uml.org.cn/sjms/201211023.asp
저자: lixg 888888 출처: CSDN 원문:https://blog.csdn.net/lixg88888888/article/details/78932142 저작권 성명: 본 고 는 블 로 거들 의 오리지널 글 입 니 다. 블 로 거들 링크 를 동봉 해 주 십시오!