10장 상속과 코드 재사용 1. 상속과 중복코드

DRY 원칙 

= Don't Repeat Yourself

= Once and Only Once 원칙

= 모든 지식은 시스템 내에서 단일하고, 애매하지 않고 정말로 믿을 만한 표현 양식을 가져야 한다.

 

중복 코드는 코드 수정에 필요한 노력을 몇 배로 증가시킨다.

 

중복과 변경

Call에는 통화의 시작시간, 끝 시간을 저장하는 LocalDateTime 변수가 두개 있고

Phone은 List<Call> calls를 가지며 전화요금을 계산해야 하는 상황을 고려해보자.

 

가장 간단한 구현 방법은 위와 같은 Class 구조이다.

 

1. 밤 10시 이후의 통화에 대해 요금을 할인 해주는 방식을 추가해야 한다는 요구사항이 접수됐다.

 

a. 클래스 도입

이를 위와 같은 방식으로 구현하는 것은 옳지 않다.

Phone과 NightlyDiscountPhone은 많은 코드를 중복으로 가지게 된다.

 

b. 타입코드 도입

또한 Enum PhoneType {REGULAR,NIGHTLY}와 같은 TypeCode를 도입하여 하나의 클래스로 합치는 방식은

코드의 중복문제는 제거하지만 하나의 클래스가 너무 많은 책임을 가지게 되어 낮은 응집도와 높은 결합도라는 문제를 가진다.

 

c. 상속

위와 같은 구현도 문제가 있다.

NightlyDiscountPhone과 Phone이 강하게 결합되어 있다.

NightlyDiscountPhone은 부모 Class인 Phone의 정보를 지나치게 알고 있다.

 

전화요금에 세금을 부과하는 로직을 추가해야 한다고 하면 결국 부모 클래스와 자식 클래스 모두의 수정이 발생한다.

중복이 있다.

 

section 3. phone 다시 살펴보기, section 4. 차이에 의한 프로그래밍

추상화에 의존하라!

다음과 같은 추상화 클래스를 도입하면 RegPhone과 NDPhone의 공통 부분인 요금을 합치는 부분의 로직을 추상 클래스에 작성 할 수 있다.

또한 차이가 있는 부분인 Call당 Fee를 계산하는 로직은 자식 클래스가 구현하게 할 수 있다.

이 경우 전화요금에 세금을 부과하는 로직을 추가해야 한다고 하면 추상 클래스인 Phone의 calculateFee만 수정하면 된다. (혹은 ApplyTax Method를 Phone에 만들어서 해결 가능하다.)

 

 

상속은 코드 재사용의 측면에서 강력한 도구이지만 그만큼 경계해서 활용해야 한다.