상위 클래스의 기능을 재사용하기 위해 상속을 많이 사용하는 모습이다.
하지만, 상속에는 아래와 같은 문제점이 뒤따른다.
단점 1. 상위 클래스의 변경이 어려움
하위 클래스가 많아질수록 상위 클래스의 변경이 어려움.
게다가 상위 클래스들의 동작을 이해해야 하위 클래스를 사용할 수 있음.
즉, 이는 하위 클래스의 캡슐화를 저하함.
단점 2. 클래스가 많아짐
압축과 암호화 기능을 제공하는 스토리지가 필요해지면,
CompressedStorage와 EncryptedStorage 클래스를 상속해서 구현한다.
근데, 압축, 암호, 캐시 기능까지 제공하는 스토리지도 필요해지면??
--> 클래스 3개를 모두 상속받아야 하나? 등 새로운 조합이 발생할 때마다
클래스가 증가하게 됨.
단점 3. 상속 오사용(실수 발생)
ArrayList를 상속받고 새로 정의한 Container 클래스.
put, extract, canContain 메소드가 정의되어 있다.
따라서, 개발자는
Container c = new Container(5);
if (c.canContain(size2Luggage)) {
c.put(size2Luggage);
}
위와 같이 코드를 작성했다. 
수하물을 추가하는 코드다.
하지만 객체 이후 닷(.)을 타이핑하면 IDE는
해당 객체가 상속하고 있는 메소드들도 전부 보여준다.
상속받는 베이스 객체를 제대로 이해하지 못하면 충분히 발생할 수 있는 문제다.
Container 클래스를 정의한 사람의 잘못이다.
암호화 기능이 필요하다면
해당 기능을 제공하는 클래스를 상속하지말고,
필드나 메소드에서 해당 객체를 생성.
(= 필요한 시점에 생성)
--> 클래스 증식 방지
상속이 아니라 조립(생성)
서명 기능을 제공하는 객체를 내가 정의하려는 Storage 클래스 내에서 생성.
위의 우측과 같이 바꾸면, ArrayList가 제공했던 add메소드를 더 이상 제공하지 않는다.
(즉, Container 클래스(상속받은 클래스)의 put 메소드와 헷갈리지 않는 구조가 된다.)
클래스 상속하기 전에 반드시
조립방식으로 구현할 순 없는 건지 충분히 검토하기.
단순히 기능 재사용을 위해 상속을 맹목적으로 사용하지 말 것!
