Chaper 2 - 언제 Extends(상속)을 사용해도 좋은가?

1. 구현 상속을 사용하여 클래스를 정규화하고 동일한 코드의 반복 구현을 피할 수 있다.

 => 동적 모델링으로 부터 클래스 다이어그램을 도출하라. 이렇게 하면 실제 필요한 연산과 관계만이 포함되기 때문에

      정적 모델이 현실적이 되고 가벼워진다.

 

 * 올바른 OO 디자인을 다음과 같은 과정을 밟는다.

 

1. Learn the "problem domain" (accounting, order processing, and so on).
2. Talk to your users to figure out the problems they need to solve.
3. Identify use cases—stand-alone tasks performed by an end user that have some
    useful outcome—that cover all these problems.
4. Figure out the activities you need to do to accomplish the goals established in theuse case.
5. Create a "dynamic model" that shows how a bunch of objects will send messages
    to one another at runtime to perform the activities identified in the previous step.

 

 

2. 'Is - a'는 클래스 계층 구조를 검증할 때는 유용할지 모르지만 디자인 시에는 그리 유용한 도구가 아니다.

    우리가 평상시 사용하는 자연어에 휘둘리지 말고, 문제의 본질이 무엇인지를 파악하자.

 

Employee & Manager

* Employee와 Manager가 동일한 연산을 동일한 방식으로 수행한다.

   : 같은 클래스로 구현한다.

* Employee와 Manager가 동일한 연산을 다른 방식으로 수행한다.

   : 두 클래스가 공통의 인터페이스를 구현한다.

* Employee와 Manager에 공통된 연산이 없다.

  : 별도의 클래스로 구현한다.

* Manager가 Employee에 약간의 연산을 추가한다.

  : Manager가 Employee를 extends하도록 한다.

 

 

 

3. 단순한 구조는 만들고 유지 보수하기 쉽다. implements와 extends를 사용했을 때의 복잡도를 분석해 본 후 단순한 방법을 사용하자.

 

4. 상속한 메소드에서 예외를 던지지 말라, 즉 리스코프 대체 원칙(LSP)를 지키라. LSP를 어기면 다형성을 이용한 코딩을 할 수 없고,  

  결과적으로 개방 폐쇄의 원칙(OCP)도 지킬 수 없게 된다.

 

Holub on 실용주의 디자인패턴의 책 내용을 공부하며 정리한 내용입니다.

저자나 역자에게 문제를 일으킨다면 삭제하겠습니다.