[Item18] extends 멈춰

자바에서 extends를 이용해 상위 클래스를 상속 받으면 코드 복붙이 필요 없다

상위 클래스의 private 변수, 메서드를 제외한 모든 속성을 내려주기 때문이다

이런 편리함을 제공하는데도 상속 보다는 합성을 이용하란다, 왜일까?

 

https://www.quora.com/Why-do-people-say-that-implementation-inheritance-in-Java-breaks-encapsulation-as-opposed-to-composition-inheritance-Any-other-alternatives

 

어허어허, 구현 상속은 캡슐화를 깨트려서고만

protected는 내부 구현을 감춰뒀다는 환상을 준다고라

캡슐화의 핵심은 이전에 제공했던 public interface 대로 동작만 가능하면 아무 걱정 없게 해주기 때문이구만

만약 변경이 필요하면 인터페이스를 구현한 클래스에서만 신경 써주면 되니까 편하겠구먼

그런데 상속을 사용해 protected로 내려주면 상속 받은 녀석들까지 모두 신경 써야 하니까 귀찮아지고

이는 캡슐화가 깨졌음을 의미하는 것이로구나

OOP에서 복잡성을 관리하는 핵심은 상위, 하위 클래스가 호환되도록 더 쉽게 구현할 수 있게 만드는 것이로군?!

위 사진의 내용을 간략하게 정리했다

 

특히 Item18에서 문제가 될 수 있는 부분이 책의 예제처럼 상위 클래스의 구현을 정확히 모르고 있을 때 발생한다

HashSet에서 addAll은 add를 자기 사용(self-use)하고 있기 때문에 원하는 결과가 나오지 않는다

자신이 사용하려고 하는 클래스가 third-party 라이브러리거나 구현 내용이 어마무시하게 많으면 더 심각하다

상속은 안 되니 인터페이스를 구현하려고 하면 메서드 구현 노가다가 펼쳐진다

이럴 때 쉽게 해결할 수 있는 방법이 필드로 가지고 위임을 사용해 그 녀석에게 일을 시키는 것이다

이렇게 하면 여전히 그 클래스의 내부 구현은 신경 쓰지 않고 내가 원하는 기능만 쏙쏙 빼먹을 수 있다

 

'상속 보다는 합성을' 이라는 개념은 이펙티브 자바 뿐만 아니라 객체지향에 관한 책이라면 대부분 나와있다

재밌게 봤던 오브젝트에서도 그랬고 스프링 관련 인강들에서도 그랬고

객체지향에 능숙한 개발자라면 당연하게 생각하고 있을 내용이지만 나 같은 병아리는 반복해서 들어도 아리송하다

 

그렇기 때문에 인강이나 책 등 여러 소스에서 다양한 설명을 보는게 중요하다고 느껴진다

같은 개념도 어떻게 표현하느냐에 따라 다가오는 느낌이 다르기 때문이다

그래서 개발자에게는 특히 영어가 중요한 것 같다

개인 프로젝트에서 spring-data-redis cache & hateoas를 접목할 때 한참 헤맸었는데

정말 수많은 검색을 거쳐서 실마리를 찾고 해결했던 경험에서 특히 그렇게 느꼈다

 

난 어떤 설명이든 날 것의 어휘를 써서 내가 이해한 대로 표현해본다

블로그 글의 대부분도 그런 식으로 정제하지 않고 휘갈겨 쓰는 편이다

공식문서나 엄근진한 책을 보면 너무 사전적인 단어를 써서 쉽게 다가오지 않고 때로는 보기가 싫어진다

사실 이해하고 나면 사전적인 단어로 빡빡 써놓은게 간결하고 제대로 된 표현이기는 하다

 

대충 쓰더라도 책에 있는 내용을 고대로 갖다 박은 글이 아니라

이펙티브 자바를 읽고 뻗쳐 나온 궁금증에 대해 더 찾아보고 내가 이해한 개념대로 쓴다

처음엔 마음 먹고 블로그에 정리해야지라는 생각을 갖고 있던게 아니라

궁금했던 내용을 다른 사람들은 어떻게 생각하나 하고 찾아봤는데 이펙티브 자바 구글 검색 결과의 대부분이

코드 따라 치고 중요 내용 옮겨논 거라 아쉬움이 들어 내가 직접 써보는 중이다

혹시 기이한 운명으로 이 글을 읽고 있다면 자바에 대한 궁금한 부분을 얘기 나눠봤으면 좋겠다

 

최근 회사 동료분과 함께 이펙티브 자바 스터디를 하고 있는데 결은 비슷하지만 다른 생각이 나올 때가 있어 재밌다

스터디 감사하다, 코드 리뷰 받을 수 있는 지금 환경 감사하다