기록하는 곳

10장. 상속과 코드 재사용

1. 상속과 코드 중복

중복 코드는 두 코드가 중복이긴 한지 비교하는것부터 시간을 낭비하게 만들고 동료들을 의심하게 만든다. 그 외에도 중복 코드를 제거해야 할 결정적인 이유는 따로 있다.

DRY 원칙

중복 코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것이다. 중복 여부를 판단하는 기준은 변경이다.

요구사향이 변경됐을 때 두 코드를 한번에 수정해야 한다면 이 코드는 중복이다. 중복 여부를 결정하는 기준은 코드의 모양이 아닌, 코드가 변경에 반응하는 방식이다.

DRY는 '반복하지 마라'라는 뜻의 Don't Repeat Yourself의 첫 글자를 모아 만든 용어로 간단히 말해 동일한 지식을 중복하지 말라는 것이다.

DRY 원칙

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

DRY 원칙은 한 번, 단 한번(Once and Only Once) 원칙 또는 단일 지점 제어(Single-Point Control) 원칙이라고도 부른다. 핵심은 코드 안에 중복이 존재해서는 안 된다는 것이다.

중복과 변경

중복 코드 살펴보기

가입자별로 전화 요금을 계산하는 간단한 애플리케이션을 개발해 보자.

전화 요금을 계산하는 규칙은 10초당 5원이다.

Call - 개별 통화 기간을 저장
public class Call {
    private LocalDateTime from;  // 통화 시작 시간
    private LocalDateTime to; // 통화 종료 시간

    public Call(LocalDateTime from, LocalDateTime to) {
        this.from = from;
        this.to = to;
    }

    public Duration getDuration() {
        return Duration.between(from, to);
    }

    public LocalDateTime getFrom() {
        return from;
    }
}
Phone - 통화 요금을 계산 (Call의 목록을 관리할 정보 전문가)
public class Phone {
        // ex) 10초당 5원
    private Money amount;  // 단위요금 ex) 5원
    private Duration seconds; // 단위시간 ex) 10초 
    private List<Call> calls = new ArrayList<>(); // 통화 목록

    public Phone(Money amount, Duration seconds) {
        this.amount = amount;
        this.seconds = seconds;
    }

    public void call(Call call) {
        calls.add(call);
    }

    public List<Call> getCalls() {
        return calls;
    }

    public Money getAmount() {
        return amount;
    }

    public Duration getSeconds() {
        return seconds;
    }

        // 전체 통화 요금을 계산함
    public Money calculateFee() {
        Money result = Money.ZERO;

        for(Call call : calls) {
            result = result.plus(amount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
        }

        return result;
    }
}

다음은 Phone을 이용해 통화를 한 경우의 통화 요금을 계산하는 방법을 코드로 나타낸 것이다.

Phone phone = new Phone(Money.wons(5), Duration.ofSeconds(10));
phone.call(new Call(LocalDateTiem.of(2018, 1, 1, 12, 10, 0),  // 1분간 통화(=60초=30원)
										LocalDateTime.of(2018, 1, 1, 12, 11, 0)));
phone.call(new Call(LocalDateTiem.of(2018, 1, 2, 12, 10, 0),  // 1분간 통화(=60초=30원)
										LocalDateTime.of(2018, 1, 2, 12, 11, 0)));

phone.calculateFee(); // 총 2분간 통화 => Money.wons(60)

여기서 '심야 할인 요금제'라는 새로운 요금 방식을 추가하기 위한 가장 쉽고 빠른 방법은 NightlyDiscountPhone이라는 클래스를 만들고 수정하는 것이다.

  • NightDiscountPhone - 심야 할인 요금제 (Phone과 중복되는 코드가 있다.)

    public class NightlyDiscountPhone {
    private static final int LATE_NIGHT_HOUR = 22;  // 22시부터 시작

    private Money nightlyAmount;  // 심야 요금
    private Money regularAmount; // 원래 요금
    private Duration seconds;  // 단위 시간
    private List<Call> calls = new ArrayList<>(); // 통화 목록

    public NightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration seconds) {
        this.nightlyAmount = nightlyAmount;
        this.regularAmount = regularAmount;
        this.seconds = seconds;
    }

    public Money calculateFee() { // phone과 중복되는 코드가 있음(일반 요금)
        Money result = Money.ZERO;

        for(Call call : calls) {
            if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) { // 심야 요금
                result = result.plus(nightlyAmount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
            } else { // 일반 요금
                result = result.plus(regularAmount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
            }
        }

        return result;
    }
}

중복 코드 수정하기

통화 요금에 세금을 부과하는 요구사항을 추가해보자.

Phone과 NightDiscountPhone 양쪽 모두에 통화 요금을 계산하는 로직이 들어있기 때문에 두 클래스를 함께 수정해야 한다. 둘 다 수정해야하기 때문에 한 클래스를 깜빡하고 수정하지 않을 수도 있고, 두 코드를 다르게 수정할 수도 있다.

중복 코드의 양이 많아질수록 버그의 수는 증가하며 그에 비례해 코드를 변경하는 속도는 점점 더 느려진다.

타입 코드 사용하기

두 클래스 사이의 중복 코드를 제거하는 한 가지 방법은 클래스를 하나로 합치는 것이다.

public class Phone {
    private static final int LATE_NIGHT_HOUR = 22;
    enum PhoneType { REGULAR, NIGHTLY }

    private PhoneType type;

		// ..중략..

    public Money calculateFee() {
        Money result = Money.ZERO;

        for(Call call : calls) {
            if (type == PhoneType.REGULAR) {
                result = result.plus(amount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
            } else {
                if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {
                    result = result.plus(nightlyAmount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
                } else {
                    result = result.plus(regularAmount.times(call.getDuration().getSeconds() / seconds.getSeconds()));
                }
            }
        }

        return result;
    }
}

타입 코드를 사용하면 낮은 응집도와 높은 결합도에 시달리게된다.

보다 더 효과적인 중복 제거를 위해 객체지향 프로그래밍 언어에서는 상속을 사용하기도 한다.

상속을 이용해서 중복 코드 제거하기

상속을 이용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 한다. 이것은 자식 클래스의 작성자가 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미한다.

상속은 결합도를 높인다. 그리고 상속이 초래하는 부모 클래스와 자식 클래스 사이의 강한 결합이 코드를 수정하기 어렵게 만든다.

강하게 결합된 Phone과 NightlyDiscountPhone

이번엔 세금을 부과하는 로직을 추가하기 위해 taxRate를 추가하겠다.

public class Phone {
  private double taxRate;
	public Phone(Money amount, Duration seconds, double taxRate) {
			...
			this.taxRate = taxRate;
	}
	
	public Money CalculateFee() {
		...
		return result.plus(result.times(taxRate));
	}
...
}

public class NihgtlyDiscountPhone extends Phone {
		public NightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration secons, double taxRate) {
				super(regularAmount, seconds, taxRate);
				...
		}
		
		@Override
		public Money calculateFee() {
			...
			return result.minus(nightlyFee.times(getTaxRate()));
		}
}

Phone에 taxRate를 추가함으로써, Phone과 유사한 코드를 NightlyDiscountPhone에도 추가해야 했다. 이것은 상속으로 인해 NightlyDiscountphone이 Phone의 구현에 너무 강하게 결합돼 있기 때문에 발생하는 문제다.

따라서 상속을 사용할 때 super 참조를 이용해 부모 클래스의 메서드를 직접 호출할 경우 두 클래스는 강하게 결합된다. super 호출을 제거할 수 있는 방법을 찾아 결합도를 제거하는게 좋다.

이러한 상속 관계로 연결된 자식 클래스가 부모 클래스의 변경에 취약해지는 현상을 가리켜 취약 기반 클래스 문제라고 부른다. 해당 문제는 코드 재사용을 목적으로 상속을 사용할 때 발생하는 가장 대표적인 문제다.

2. 취약한 기반 클래스 문제

위에서 본것처럼 부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상을 취약한 기반 클래스 문제라고 부른다. 이 문제는 상속을 사용한다면 피할 수 없는 객체지향 프로그래밍의 근본적인 취약성이다.

취약한 기반 클래스 문제는 캡슐화를 약화시키고 결합도를 높인다. 자식 클래스가 부모의 구현 세부사항에 의존하도록 만들기 때문에 캡슐화를 약화시킨다.

불필요한 인터페이스 상속 문제

자바의 Stack 클래스는 Vector를 상속받아 구현되어있다.

1.jpeg

Stack은 Vector의 퍼블릭 인터페이스를 상속받기 때문에 add, remove를 통해서 임의의 위치에서 요소를 추가하거나 삭제할 수 있다. 이는 Stack의 규칙을 위반할 수 있다.

이러한 점은 퍼블릭 인터페이스에 대한 고려 없이 단순히 코드 재사용을 위해 상속을 이용하는 것이 얼마나 위험한지를 잘 보여준다. 단순히 고드를 재사용하기 위해 불필요한 오퍼레이션이 인터페이스에 스며들도록 방치해서는 안된다.

따라서 상속을 사용할때는, 상속받은 부모 클래스의 메서드가 자식 클래스의 내부 구조에 대한 규칙을 깨뜨릴 수 있다는 사실을 주의해야 한다.

메서드 오버라이딩의 오작용 문제

public class InstrumentedhashSet<E> extends HashSet<E> {
		private int addCount = 0;

		@Override
		public boolean add(E e) {
				addCount++;
				return super.add(e);
		}
		
		@Override
		public boolean addAll(Collection<? extends E> c) {
				addCount += c.size();
				return super.addAll(c);
		}
}

위의 클래스를 이용하여 리스트를 추가하면

InstrumentedHashsSet<String> languages = new InstrumentedHashSet<>();
languages.addAll(Arrays.asList("Java", "Ruby", "Scala"));

위의 코드를 실행시켜보면 addCount가 3이 된다고 생각하겠지만 6이 나온다.

addAll()을 호출시키면 return할 때 부모메서드의 addAll()도 호출되기 때문이다.

이와 같이 자식 클래스가 부모 클래스의 메서드를 오버라이딩할 경우 부모 클래스가 자신의 메서드를 사용하는 방법에 자식 클래스가 결합될 수 있다.

부모 클래스와 자식 클래스의 동시 수정 문제

음악 목록을 추가할 수 있는 플레이리스트를 구현해보자

Song 클래스에는 가수의 이름과 노래제목을 인스턴스 변수로 포함한다.

Playlist 클래스는 아래와 같이 구현된다.

public class Playlist {
		private List<Song> tracks = new ArrayList<>();
		
		public void append(Song song) {
				getTracks().add(song);
		}

		public List<Song> getTracks() {
				return tracks;
		}
}

삭제기능이 추가된 PersonalPlaylist를 만들면 다음과 같다.

public class PersonalPlaylist extends Playlist {
		public void remove(Song song) {
				getTracks().remove(song);
		}
}

여기에 노래의 목록 뿐 아니라 가수의 이름도 추가로 관리하게 된다면 append, remove 메소드 둘 다 가수이름을 추가,삭제할 수 있도록 수정해주어야 한다.

이 예는 자식 클래스가 부모 클래스의 메서드를 오버라이딩하거나 불필요한 인터페이스를 상속받지 않았어도 함께 수정해야한다는 사실을 보여준다. 상속을 사용하면 자식 클래스가 부모 클래스의 구현에 강하게 결합되기 때문에 이 문제를 피하기는 어렵다.

즉, 클래스를 상속하면 결합도로 인해 자식 클래스와 부모 클래스의 구현을 영원히 변경하지 않거나, 자식 클래스와 부모 클래스를 동시에 변경하거나 둘 중 하나를 선택할 수 밖에 없다.

요약하면 다음과 같다.

  1. super 참조를 이용해 부모 클래스의 메서드를 직접 호출할 경우 두 클래스는 강하게 결합된다.
  2. 상속받은 부모 클래스의 메서드가 자식 클래스의 내부 구조에 대한 규칙을 깨뜨릴 수 있다.
  3. 자식 클래스가 부모 클래스의 메서드를 오버라이딩할 경우 부모 클래스가 자신의 메서드를 사용하는 방법에 자식 클래스가 결합될 수 있다.
  4. 클래스를 상속하면 결합도로 인해 자식 클래스와 부모 클래스의 구현을 영원히 변경하지 않거나, 자식 클래스와 부모 클래스를 동시에 변경하거나 둘 중 하나를 선택할 수 밖에 없다.

3. Phone 다시 살펴보기

추상화에 의존하자

자식과 부모가 함께 변경되는 문제를 해결하는 가장 일반적인 방법은 부모 클래스와 자식 클래스 모두 추상화에 의존하도록 수정해야 한다.

코드 중복을 제거하기 위해 상속을 도입할 때 따르는 두 가지 원칙이 있다.

  1. 두 메서드가 유사하게 보인다면 차이점을 메서드로 추출하라. 메서드 추출을 통해 두 메서드를 동일한 형태로 보이도록 만들 수 있다.
  2. 부모 클래스의 코드를 하위로 내리지 말고 자식 클래스의 코드를 상위로 올려라. 부모 클래스의 구체적인 메서드를 자식 클래스로 내리는 것보다 자식 클래스의 추상적인 메서드를 부모 클래스로 올리는것이 재사용성과 응집도 측면에서 더 뛰어난 결과를 얻을 수 있다.

차이를 메서드로 추출하라

가장 먼저 할 일은 중복 코드 안에서 차이점을 별도의 메서드로 추출하는 것이다.

하나의 call에 대한 통화 요금을 계산하는 로직을 따로 추출하자.

// Phone
private Money calculateCallFee(Call call) {
		return amount.times(call.getDuration().getSeconds() / seconds.getSeconds());
}

// NightlyDiscountPhone
private Money calculateCallFee(Call call) {
		if (call.getFrom().getHour() >= LATE_NIGHT_HOUR) {
				return nightlyAmount.times(call.getDuration().getSeconds() / seconds.getSeconds());
		} else {
				return regularAmount.times(call.getDuration().getSeconds() / seconds.getSeconds());
		}
}

이런식으로 다른부분만 따로 추출하면 calculateFee메서드는 완전히 동일해지므로 부모 클래스로 올리면 된다.

중복 코드를 부모 클래스로 올려라

Phone과 NightlyDiscountPhone이 AbstractPhone을 상속받도록 수정하자

public abstract class AbstractPhone { }

public class Phone extends AbstractPhone { ... }

public class NightlyDiscountPhone extends AbstractPhone { ... }

2

AbstractPhone에 동일한 코드인 calculateFee()를 구현하고 calculateCallFee()를 추상메서드로 구현하자. 이제 우리의 설계는 추상화에 의존하게 된다.

이러한 설계는 실패했더라도 수정하기 쉬운 문제를 발생시킨다. 수정하기 쉬운 문제는 쉽게 고칠 수 있고 결과적으로 코드의 품질이 높아지게 된다.

추상화가 핵심이다.

공통 코드를 상위클래스로 이동시킨 후에 각 클래스는 서로 다른 이유로 변경된다는것에 주목하자.

  • AbstractPhone : 전체 통화 목록을 계산하는 방법이 바뀔 경우
  • Phone : 일반 요금제의 통화 한 건을 계산하는 방식이 바뀔 경우
  • NightlyDiscountPhone : 심야 할인 요금제의 통화 한 건을 계산하는 방식이 바뀔 경우

이 클래스들은 단일 책임 원칙을 준수하기 때문에 응집도가 높다.

의존성 역전 원칙 또한 준수하는데, AbstractPhone이 자식클래스에게 의존하지 않고, 자식클래스들이 추상화인 AbstractPhone에 의존하기 때문이다.

새로운 요금제 또한 추가하기 쉽다. AbstractPhone을 상속받는 새로운 클래스를 추가한 후 calculateCallFee 메서드만 오버라이딩하면 된다. 다른 클래스를 수정할 필요가 없다.

현재의 설계는 확장에는 열려 있고 수정에는 닫혀 있기 때문에 개방-폐쇄 원칙 역시 준수한다.

핵심은, 차이점을 메서드로 추출하고 공통부분은 부모 클래스로 이동시키는 것이다.

의도를 드러내는 이름 선택하기

AbstractPhone → phone

Phone → RegularPhone

위와 같이 변경하는것이 의미전달이 좀 더 명확할것이다.

4. 차이에 의한 프로그래밍

상속이 강력한 이유는 익숙한 개념을 이용해서 새로운 개념을 쉽고 빠르게 추가할 수 있기 때문이다.

이처럼 기존 코드와 다른 부분만을 추가함으로써 애플리케이션의 기능을 확장하는 방법을 차이에 의한 프로그래밍이라고 부른다.

상속은 코드 재사용이라는 측면에서 매우 강력한 도구인 것은 사실이지만 잘못 사용할 경우 애플리케이션을 이해하고 확장하기 어렵게 만든다.

그래서 상속의 단점을 피하면서도 코드를 재사용할 수 있는 합성이 있다.

Last Updated: