자바 의 계승 과 조합 에 대한 잘못된 예

[TOC]
자바 의 계승 과 조합 에 대한 잘못된 예
절대 다수의 사람들 이 자바 중의 '계승' 과 '조합' 이라는 두 가 지 를 비교적 잘 알 고 있다 고 믿 습 니 다. 이 글 은 주로 이 두 가지 화제 에 대해 이야기 합 니 다.만약 에 제 가 잘못 썼 거나 유치 하고 논증 이 명확 하지 않 으 면 여러분 의 댓 글 에 대한 지적 을 환영 합 니 다.
'조합' 과 '계승' 이 무엇 입 니까?
만약 에 2 개의 class 가 있다 고 가정 하면 A 과 B:

클 라 스 A extends B 가 있 으 면 우 리 는 A 가 B 를 계승 하고 A 는 자 류 이 며 B 는 부 류 라 고 말 하 는데 이런 상황 이 바로 계승 이다.

만약 에 A 에 속성 이 있 는 유형 이 B 라면 우 리 는 이런 상황 이 바로 조합 이 라 고 말한다.

각각 어떤 상황 에서 사용 합 니까?
돌 이 켜 보면 우 리 는 보통 어떤 상황 에서 이 두 가 지 를 고려 합 니까?나 는 대충 생각해 보 니 종종 다음 과 같은 장면 이 있다.

공용 코드

사물 간 의 '공통성' 을 나타 내 거나 '범 형' 만 을 위해 추출 abstract class 또는 interface

가 고 싶 습 니 다. 정말 이 두 가지 상황 만 있 는 것 같 습 니 다. 그러나 이 두 가지 상황 은 특별한 관련 이 있 습 니 다. 예 를 들 어 공용 코드 라 는 일 은 사실 abstract class 과 interface (자바 8 중의 default method) 모두 달성 할 수 있 습 니 다.
좋아, 이렇게 쓸데없는 말 을 많이 했 으 니, 나 는 직접 나의 관점 을 던 져 버 릴 거 야. 벽돌 을 찍 는 것 을 환영 해.

공용 코드 만 생각 하고 이 공용 코드 를 사용 하 는 class 나 method 가 뚜렷 한 연락 이 없다 면 조합 을 사용 하 십시오.

만약 에 몇 개의 class 또는 그 method 가 비교적 뚜렷 한 관 계 를 가진다 면 하나 abstract class 또는 interface

를 추출 하 십시오.

'속성 계승' 의 특성 을 신 중 히 사용 하고 하위 클래스 에 필요 한 부모 클래스 의 속성 을 명 확 히 복사 하 는 것 을 권장 합 니 다.이 점 은 특히 중요 하 다. 나중에 이런 상황 의 불리 한 면 을 설명 하 는 예 가 있 을 것 이다.

반면교사
비교적 흔히 볼 수 있 는 예: 우 리 는 실제 프로젝트 에서 흔히 정 의 된 POJO 또는 model 이 있 는데 이런 model 은 흔히 명사 와 유형 이 같은 속성 이 있다. 예 를 들 어:

// db table primary key
private int id;

흔 하 죠? 하지만 저 는 실제 업무 에서 많은 동 료 를 만 났 습 니 다. 시스템 은 이름 이 BaseModel 또는 RootModel 일 수 있 는 종 류 를 정의 하고 위의 속성 id 을 안에 넣 은 다음 에 전체 프로젝트 의 모든 model 이 이 BaseModel 류 를 계승 합 니 다.당신들 은 이런 동 료 를 만난 적 이 있 습 니까?너 희 는 이렇게 쓰 면 무슨 좋 은 점 과 나 쁜 점 이 있 을 것 이 라 고 생각 하 니?
먼저 좋 은 점 을 말 하 세 요. 굳이 좋 은 점 을 가 져 다 줄 수 있다 면 키 보드 를 몇 번 덜 두 드 리 는 것 외 에 하위 클래스 에서 이런 속성 이 적 다 는 것 외 에 실질 적 인 좋 은 점 을 보지 못 했 습 니 다.하지만 프로젝트 의 후속 유지 에 큰 문 제 를 가 져 왔 다.
그리고 이런 서법 의 잠재 적 인 문 제 를 말 하 자.
어느 날, 몇 가지 이유 로 하위 클래스 A (BaseModel 계승) 의 속성 id 을 프로젝트 의 어느 곳 에서 사용 하고 싶 습 니까?
지혜 로 운 당신 은 IDE 의 find usages 를 능숙 하 게 사용 한 후에 당신 이 찾 은 사용 위치 가 매우 많 고 많은 것 이 당신 의 관심 사가 아니 라 는 것 을 알 게 될 것 입 니 다.하지만 어 쩔 수 없 이 BaseModel 의 클래스 를 계승 한 다른 속성 id 의 사용 위 치 를 찾 았 습 니 다.프로젝트 가 크 지 않 으 면 검색 숙련 이 적 을 수 있 습 니 다. 프로젝트 가 좀 크 면 요?검색 에 50 곳 이 넘 으 면 어떻게 하 시 겠 습 니까?

검색 한 코드 를 하나씩 보고 십 몇, 20 개 를 보고 뿌리 기 시작 한 다음 에 계속 하나씩 찾 아 볼 까요?

바로 뿌리 기 시작 하고 검색 한 코드 를 하나씩 볼 까요?

어떻게 이런 상황 을 피 할 수 있 습 니까? 그것 은 바로 이런 BaseModel 방식 으로 속성 계승 을 사용 하지 않 는 것 입 니 다.물론 엄밀 한 기간 을 위해 저 는 이 뜻 을 상세 하 게 말씀 드 려 야 합 니 다. 저 는 속성 계승 에 완전히 반대 하지 않 았 습 니 다. 명확 하 게 말씀 드 리 겠 습 니 다.
내 가 반대 하 는 것 은 전체 프로젝트 의 모든 model 이 BaseModel 을 계승 한 후에 공용 속성 을 BaseModel 에 두 는 것 이다.
라 는 생각 에 주 의 는 전체 항목 의 것 이다.
후기
위의 반면교사 의 예 는 개인 적 으로 자주 만 나 기 때문에 단독으로 꺼 내 서 말씀 드 리 겠 습 니 다. 여러분 의 프로젝트 에서 이런 상황 이 발생 한 적 이 있 는 지 확실 하지 않 습 니 다.어쨌든 나 는 이미 동료의 이런 서법 에 여러 차례 함정 에 빠 진 적 이 있다.
'조합' 과 '계승' 과 관련 된 흔 한 실 수 는 아직 생각 하지 못 했 습 니 다.