[디자인패턴] 상속보다는 컴포지션을 사용하자!!!

현업자들이 모여있는 오픈톡방에서 상속과 컴포지션에 대한 이야기가 흘러나왔다.

 

ㅎㅎ ...;;;  정말 난 모르는게 많구나.... 이제라도 알아가면 되지 뭐!!!

 

아래의 블로그포스팅을 쓰신분이 여러블로그와 책을 기반으로 작성하셔서 읽으며 매우 이해가 잘되어

이분의 포스팅을 기반으로 노트필기 느낌으로 포스팅을 작성하려 한다...!!

(베껴쓰지 않고 본인이 연구해서 포스팅하시는 분들이 최고야!!!)

 

상속보다는 컴포지션을 사용하라

 

* 해당 포스팅은 위 블로그의 게시물을 받아쓰기하며 뇌에 다시 한번 넣는 포스팅입니다.

 

 

# 중요 개념

1. 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. (상위클래스의 구현에 따라 하위클래스가 영향을 받아 동작에 이상이 생길 수 있다.)

2. 상속은 Is-A 관계에 쓰나 Is-A 관계더라도 안심하면 안된다. (1번의 위험성은 여전하기 때문)

*상위 클래스가 확장을 고려했고, 문서화도 잘 된 클래스라면 안전하다.
상속의 취약점을 피하려면 상속 대신 Composition과 Forwarding을 사용하자.

Java 기본 라이브러리의 Stack 과 Vector 는 IS-A 관계가 아니나, Stack 이 Vector를 상속하여 구현이 되어있다.
(잘못된 관계이지만, 문제를 바로잡기엔 너무 늦어 바꿀 수 없게 되었다고 한다.)

---

 

# 컴포지션

Has-A 관계이다.
상속으로 구성되지 않았기에 상위클래스의 변화로 하위클래스가 오작동하는일은 사라진다.

 

아래는 상속관계와 컴포지션 관계를 한번에 이해 할 수 있는 예시이다.

 

class Engine {} // The Engine class.

class Automobile {} // Automobile class which is parent to Car class.

class Car extends Automobile { // Car is an Automobile, so Car class extends Automobile class.
  private Engine engine; // Car has an Engine so, Car class has an instance of Engine class as its member.
}

 

* Car Is-A Automobile, Car Has-A Engine.

---

 

# 상속을 사용 할 때 고려해야 할점

1. 확장하려는 클래스의 API에 아무런 결함이 없는가?
2. 결함이 있다면, 이 결함이 여러분 클래스의 API까지 전파돼도 괜찮은가?