자바 디자인 모델-7 대 원칙 상세 설명

디자인 모드
소프트웨어 디자인 모델(Design pattern)은 디자인 모델 이 라 고도 부 르 는데 반복 적 으로 사용 되 고 대부분 사람들 이 알 고 분류 목록 을 거 친 코드 디자인 경험 에 대한 정리 이다.디자인 모델 을 사용 하 는 것 은 코드 를 다시 사용 할 수 있 고 코드 가 다른 사람 에 게 쉽게 이해 되 고 코드 의 신뢰성,프로그램의 재 활용 성 을 확보 하기 위해 서 이다.
예 를 들 어 빌딩 과 오 두 막 을 짓 는 것 처럼 기능 이 간단 하고 함수 와 코드 가 적 을 때 우 리 는 비교적 쉽게 직접 시작 할 수 있다.그러나 빌딩 처럼 기능 이 복잡 하고 수요 가 변화 할 수 있 으 며 코드 의 양 이 많 을 때 우 리 는 직접 올 수 없고 건축 도면 처럼 미리 계획 하고 디자인 해 야 한다.그 디자인 모델 은 소프트웨어(프로그램)의 건축 도면 과 같다.
디자인 모델 의 목적 은 소프트웨어(프로그램)가 더욱 좋 은 것 을 가지 도록 하 는 것 이다.
1.코드 재 활용 성
같은 기능 의 코드 는 여러 번 작성 하지 않 아 도 되 고 번 거 로 움 을 줄 일 수 있 습 니 다.
2.가 독성
프로 그래 밍 규범 성 은 다른 프로그래머 들 의 읽 기와 이해 에 편리 하 다.
3.확장 성
새로운 기능 을 추가 해 야 할 때 매우 편리 하고 유지 가능성 이 라 고도 부른다.
4.신뢰성
우리 가 새로운 기능 을 증가 시 킨 후,원래 의 기능 에 영향 을 주지 않 는 다.
5.프로그램 으로 하여 금 높 은 내부 집적,낮은 결합 특성 을 나타 내 게 한다.
모듈 내부 가 긴밀 하지만 모듈 간 의존 이 적 고 한 사람 이 잘못 하면 다른 사람 에 게 영향 을 주지 않 습 니 다.
단일 직책 원칙
단일 직책 원칙(Single responsibility principle),즉 한 가지 직책 만 맡아 야 한 다 는 것 이다.예 를 들 어 A 는 두 가지 서로 다른 직책 을 책임 진다.직책 1,직책 2.직책 1 의 수요 가 변경 되 어 A 를 바 꿀 때 직책 2 의 집행 오류 가 발생 할 수 있 기 때문에 클래스 A 의 입 도 를 A1,A2 로 분해 해 야 한다.
단일 직책 원칙 주의사항 및 세부 사항
4.567917.유형의 복잡 도 를 낮 추고 한 가지 직책 만 책임 진다류 의 가 독성 을 높이 고 유지 가능성 을 높 인 다변경 으로 인 한 위험 을 낮추다.
4.567917.일반적인 상황 에서 우 리 는 단일 직책 원칙 을 지 켜 야 한다.논리 가 충분 하고 간단 해 야 코드 급 에서 단일 직책 원칙 을 위반 할 수 있다.유형 중의 방법 수량 만 충분 하고 방법 등급 에서 단일 직책 원칙 을 유지 할 수 있다
인터페이스 격 리 원칙
인터페이스 격 리 원칙(Interface Segregation Principle),즉 클 라 이언 트 는 필요 하지 않 은 인터페이스 에 의존 해 서 는 안 된다.즉,다른 클래스 에 대한 의존 은 최소 인터페이스 에 세 워 져 야 한다.
예 를 들 어 클래스 A 는 인터페이스 I I I 의존 클래스 B,클래스 C 는 인터페이스 I I I 의존 클래스 D 를 통 해 인터페이스 I I I 가 클래스 A 와 클래스 C 에 있어 최소 인터페이스 가 아니라면 클래스 B 와 클래스 D 는 그들 이 필요 로 하지 않 는 방법 을 실현 해 야 한다.

격 리 원칙 에 따라 이렇게 처리 해 야 한다.인터페이스 I I I 를 독립 된 몇 개의 인터페이스 로 나 누고 그들 이 필요 로 하 는 인터페이스 와 의존 관 계 를 맺 는 다.즉,인터페이스 격 리 원칙 을 사용한다.

역전 원칙 에 의존 하 다
역 전 원칙(Dependence Inversion Principle)에 의존 하고,역 전(거꾸로)에 의존 하 는 중심 사상 은 인 터 페 이 스 를 향 한 프로 그래 밍 이 며,이른바'역 전'은 추상 이 디 테 일 에 의존 하지 말고 디 테 일 은 추상 에 의존 해 야 한 다 는 것 을 말한다.즉,고 층 모듈 은 저층 모듈 에 의존 해 서 는 안 되 고 둘 다 추상 에 의존 해 야 한 다 는 것 이다.디 테 일의 다 변성 에 비해 추상 적 인 것 이 안정 적 이 어야 하기 때문이다.
예 를 들 어 Person 류 는 Email,QQ,위 챗 의 소식 을 받 아들 일 수 있 습 니 다.만약 모두 그 에 게 전문 적 인 방법 을 제공한다 면 코드 는 매우 번 거 로 울 것 이다.

Person 클래스 가 이 인터페이스 에 의존 하도록 IReceiver 인 터 페 이 스 를 도입 할 수 있 습 니 다.이렇게 QQ,위 챗,Email 이 각각 IReceiver 의 방법 을 실현 하면 됩 니 다.

리 씨 교체 원칙
리 씨 교체 원칙(Liskov Substitution Principle)은 모든 기본 클래스 를 참조 하 는 곳 에서 하위 클래스 의 대상 을 투명 하 게 사용 해 야 한다 고 요구 했다.즉,상속 관계 에서 자 류 는 가능 한 한 부 류 를 다시 쓰 지 않 는 방법 이다.계승 은 실제 적 으로 두 가지 결합 성 을 강화 시 켰 다.특히 다 중 운행 이 비교적 빈번 할 때 전체 계승 체계의 재 활용 성 이 비교적 떨어진다.예 를 들 어 극단 적 인 상황:한 종 류 는 다른 종 류 를 계 승 했 지만 모든 방법 을 다시 썼 다.그러면 계승의 의 미 는 무엇 입 니까?재 활용 하기 로 했 는데?

해결 방법 은 원래 의 부류 와 자 류 를 모두 더욱 통속 적 인 기 류 를 계승 하 는 것 이다.적당 한 상황 에서 집합,조합,의존 등 을 통 해 대체 할 수 있다.

개폐 원칙
개폐 원칙(Open Closed Principle)은 클래스 와 같은 소프트웨어 실체 입 니 다.모듈 과 함 수 는 확장(제공 자 에 게)을 열 고 수정 을 닫 아야 합 니 다(사용 자 에 게).즉,소프트웨어 가 변화 가 필요 할 때 소프트웨어 실 체 를 확장 하 는 행 위 를 통 해 변 화 를 실현 하 는 것 이지 기 존의 코드 를 수정 함으로써 변 화 를 실현 하 는 것 이 아니다.추상 적 으로 프레임 워 크 를 구축 하여 확장 디 테 일 을 실현 합 니 다.개폐 원칙 은 프로 그래 밍 에서 가장 기초 적 이 고 가장 중요 한 설계 원칙 이다.프로 그래 밍 에서 다른 원칙 과 디자인 모델 을 사용 하 는 목적 은 바로 개폐 원칙 을 따 르 는 것 이다.
개폐 원칙 을 위반 한 예 를 들다.
직사각형 Retangle 과 원형 Circle 은 도형 류 Shape(제공 자)를 계승 하고 그림 류 GraphicEditor(사용 자)는 관련 속성 을 호출 합 니 다.

그러나 삼각형 을 하나 더 추가 하면 사용 자 GraphicEditor 에 대응 하 는 방법 을 추가 하고 수정 하 는 곳 이 많아 개폐 원칙 에 위배 된다.

개선:Shape 를 추상 적 인 유형 으로 만 들 고 추상 적 인 방법 draw 를 제공 하여 하위 클래스 를 실현 하면 됩 니 다.도형 종 류 를 추가 할 때 새로운 도형 류 가 Shape 를 계승 하고 draw 방법 을 실현 하면 된다.사용자 의 코드 는 수정 할 필요 가 없 이 개폐 원칙 을 만족시킨다.

디 미트 의 법칙
디 미트 법칙(Demeter Principle)은 최소한 의 원칙,즉 자신 이 의존 하 는 클래스 에 대한 아 는 것 이 적 을 수록 좋 고 핵심 은 클래스 간 의 결합 을 낮 추 는 것 이다.의존 되 는 클래스 에 대해 서 는 아무리 복잡 하 더 라 도 논 리 를 클래스 내부 에 밀봉 하 는 것 이다.대외 적 으로 제공 하 는 Public 방법 외 에 어떠한 정보 도 누설 하지 않 습 니 다.비 직접적인 친구 와 의 결합 을 피하 고 직접적인 친구 와 만 통신 합 니 다.이른바 직접적인 친 구 는 구성원 변수,방법 매개 변수,방법 반환 값 의 클래스 입 니 다.부분 변수 에 나타 난 종 류 는 직접적인 친구 가 아니다.즉,낯 선 종 류 는 국부 변수의 형식 으로 클래스 내부 에 나타 나 지 않 는 것 이 좋다.
예 를 들 어 학원 직원 류 와 학교 직원 류 가 있 고 각각 하나의 관리 류 는 모든 직원 을 얻 을 수 있 으 며 학교 직원 관리 류 는 모든 직원 을 인쇄 하 는 방법 이 있다.

구체 적 인 코드:

void printAllEmployee(CollegeManager sub) {
		//       
		List<CollegeEmployee> list1 = sub.getAllEmployee();
		System.out.println("---    ---");
		for (CollegeEmployee e : list1) {
			System.out.println(e.getId());
		}
		//         
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("---    ---");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}

SchoolManager 클래스 를 분석 한 결과 Employee 와 CollegeManager 는 모두 그의 직접적인 친구(매개 변수 와 반환 값 에 나타 나 는 것)인 것 으로 나 타 났 으 나 CollegeEmployee 는 직접적인 친구 가 아니 라 국부 변수의 형식 으로 디 미트 원칙 에 위배 되 었 다.
개선:CollegeEmployee 에 의존 하지 않 고 CollegeManager 에 밀봉 하여 대외 적 으로 Public 방법 을 제공 하면 됩 니 다.

void printAllEmployee(CollegeManager sub) {
		sub.printEmployee();
		//         
		List<Employee> list2 = this.getAllEmployee();
		System.out.println("---    ---");
		for (Employee e : list2) {
			System.out.println(e.getId());
		}
	}

합성 복용 원칙
합성 재 활용 원칙(Composite Reuse Principle)은 가능 한 한 합성/취 합 방식 을 사용 하 는 것 이지 계승 을 사용 하 는 것 이 아니다.




총결산
설계 원칙 핵심 사상
인터페이스 프로 그래 밍 에 대해 서 는 응용 에 변화 가 필요 할 수 있 는 코드 와 변화 가 필요 없 는 코드 를 분리 하여 독립 시킨다.모두 상호작용 대상 간 의 결합 을 풀기 위해 신경 을 쓴다.
이 글 은 여기까지 입 니 다.당신 에 게 도움 을 줄 수 있 기 를 바 랍 니 다.또한 당신 이 우리 의 더 많은 내용 에 관심 을 가 져 주 실 수 있 기 를 바 랍 니 다!