글
Java/Effectice Java 2009/12/20 02:48h16. 가급적 상속보다는 컴포지션을 사용하자.
h16. 가급적 상속보다는 컴포지션을 사용하자.
reference : Effective Java second edition
>>들어가며(여기에서 말하는 상속은 구현 상속이다- 클래스간 상속, not interface상속!)
GoF의 Design Pattern에 도입부에서 강조하던 상속보다는 합성이 좋다는 당부당부가
Effective Java에서도 등장한다.
상속은 코드를 재사용하는 메커니즘으로서, 재활용 측면, 이용이 쉽다는 점, 이해하기 쉽다는 점에서 개발자를 매우 편하게 해주는 기술이지만, 많은 문제점을 야기할 수 있다.
* 캡슐화를 위배한다. - 상위 클래스의 구현에 의존하여 관계가 맺어진 super class - sub class는 나중에 있을 super class의 변경이 있을 시 sub class모두에게 영향을 미친다.
* 메소드 오버라이딩으로 인하여, 예상치 못한 문제가 발생할 수 있다.
* 오버라이딩이 문제를 발생 시킨다 해서, 메소드 확장만 한다고 상속에 문제가 없을까?
결론은 그렇지 않다. (나중에 있을 super클래스의 변동으로 인하여 의도치 못한 오버라이딩이 발생할 지도 모른다.)
위와 같은 문제들은 컴포지션과 포워딩을 통하여 해결할 수 있다.
(래퍼클래스-데코레이션패턴을 이용한 위임 방식으로 . . .)
>>활용
.
.
.
....나중에 적절한 예를 . .
'Java > Effectice Java' 카테고리의 다른 글
| h19. 타입을 정의할 때만 인터페이스를 사용하자. (0) | 2009/12/29 |
|---|---|
| h18. 추상 클래스보다는 인터페이스를 사용하자. (0) | 2009/12/21 |
| h16. 가급적 상속보다는 컴포지션을 사용하자. (0) | 2009/12/20 |
| h15. 가변성을 최소화하자. (0) | 2009/12/20 |
| h14, public 클래스에서는 public 필드가 아닌 접근자(accestor) 메소드를 사용한다. (0) | 2009/12/18 |
| h13, 클래스와 그 맴버의 접근성을 최소화하자. (0) | 2009/12/18 |
RECENT COMMENT