3. 상속은 언제 하면 좋은가?

 

 

장점: 중복되는 코드가 줄어든다.

단점: depth가 깊어지면 복잡하다.

 

짬에서 나오는 철학이 필요하다.

 

1. Single Responsibility (단일 책임): 각 클래스는 한 개의 고려사항만 있으면 된다. -> 여러 책임을 다 가지려하면 복잡해진다.
2. Type Safety (타입이 분명해야 할 때): 클래스 간의 명확한 구분이 필요한 경우 -> 학교 축구동아리에서 축구선수를 뽑으려고 하는데 미술부, 과학부 같이 너무 아무나 들어오게 하고 싶지 않아서 운동부 애들로 제한을 두고 싶어서 상속을 한다.
3. Shared Base Classes(다자녀가 있다!): 기본 동작이 다양하게 구분되어야 하는 경우 -> 학생이 학습을 하는 기능이 있다면, 미술학생은 미술공부를 학습하고 체육학생은 운동공부를 학습하는 것과 같이 Overriding이 되면 효율적인 경우 상속을 한다.
4. Extensibility(확장성이 필요한 경우): 상속을 받으면 확장성이 좋은 경우 -> 학생의 경우 미술학생, 체육학생, 과학학생 등 다양하게 확장이 되기에 상속에 효율적이다.
5. Identity(정체를 파악하기 위해): 어떤 클래스, 어떤 객체인지를 파악하기 위해 상속을 사용하기도 한다. -> 상속받은 클래스를 싸악 보면 "미술학생은 학생인데 미술을 하는구나~" 정도로 Identity를 명확하게 알기 쉽다.