TIL

11장 합성과 유연한 설계

• 상속과 합성은 객체지향에서 널리 사용되는 코드 재사용 기법이다.
• 상속
  • 부모 클래스와 자식 클래스를 연결하여 부모 클래스의 코드를 재사용
  • 컴파일 타임에 의존성이 해결됨
  • is-a 관계
  • 상속을 활용하려면 부모의 내부 구현에 대해 상세하게 알아야 하기에 결합이 높아진다.
• 합성
  • 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해 부분 객체의 코드를 재사용
  • 런타임에 의존성이 해결됨
  • has-a 관계
  • 객체의 구현이 아닌 퍼블릭 인터페이스에 의존하여 결합이 약하다.

01 상속을 합성으로 변경하기

• 상속 남용의 세 가지 문제점
  • 불필요한 인터페이스 상속 문제 (ex java.util.Stack)
  • 메서드 오버라이딩의 오작용 문제 (InstrumentedHashMap)
  • 부모 클래스와 자식 클래스의 동시 수정 문제

불필요한 인터페이스 상속 문제: java.util.Properties와 java.util.Stack

public class Properties {
    private HashTable<String, String> properties = new HashTable<>();

    public String setProperty(String key, String value) {
        return properties.put(key, value);
    }

    public String getProperty(String key) {
        return properties.get(key);
    }
}

public class Stack<E> {
    private Vector<E> elements = new Vector<>();

    public E push(E item) {
        elements.addElement(item);
        return item;
    }

    public E pop() {
        if (elements.isEmpty()) {
            throw enw EmptyStackException();
        }
        return elements.remove(elements.size() - 1);
    }
}

• Properties과 Stack 클래스를 상속에서 합성으로 변경했다.
  • 불필요한 부모 클래스 오퍼레이션들이 Properties와 Stack 클래스의 인터페이스를 오염시키지 않는다.
  • 상속과 달리 의존하는 클래스의 내부 구현을 알지 못한다.
  • 단지 퍼블릭 인터페이스를 통해 협력할 뿐이다.

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

public class InstrumentedSet<E> {

	private int addCount = 0;
	private final Set<E> set;

	public InstrumentedSet(Set<E> set) {
		this.set = set;
	}

	public boolean add(E e) {
		addCount++;
		return set.add(e);
	}

	public boolean addAll(Collection<? extends E> c) {
		addCount += c.size();
		return set.addAll(c);
	}

	public int getAddCount() {
		return addCount;
	}
}

• Properties와 Stack과 달리 InstrumentedHashSet은 HashSet의 모든 인터페이스를 그대로 제공해야 한다.
• 그럼에도 합성으로 해결할 수 있는 문제가 있다.
  • 상속의 단점이었던 구현 결합도가 제거하면서 퍼블릭 인터페이스를 유지할 수 있다.

// ...
@Override
public boolean remove(Object o) { return set.remote(o); }

@Override
public void clear() { set.clear(); }
// ...

• 포워딩 메서드 (forwarding method)
  • 위 두 메서드처럼 오버라이딩을 하면서 메서드를 그대로 호출하는 것을 뜻한다.
  • 기존 클래스의 인터페이스를 외부에 그대로 제공하면서 구현에 대한 결합 없이 작동 방식을 변경하고 싶은 경우에 유용하다.

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

• 의존하는 클래스와 의존되는 클래스가 동시에 수정되는 문제는 합성으로도 해결되지 않는다.

public class PersonalPlaylist {
    private Playlist playlist = new Playlist();

    public void append(Song song) {
        playlist.append(song);
    }

    public void remote(Song song) {
        playlist.getTracks().remote(song);
        playlist.getSingers().remote(song.getSinger());
    }
}

• 그럼에도 합성을 이용하면 파급효과를 최대한 캡슐화할 수 있다.

02 상속으로 인한 조합의 폭발적인 증가

• 상속으로 결합도가 높아지면 코드 수정에 작업 양이 과도하게 늘어난다.
• 작은 기능을 조합해 큰 기능을 수행하는 객체의 경우 다음 문제가 발생
  • 한 기능을 추가/수정하기 위해 많은 클래스를 추가/수정해야 한다.
  • 단일 상속만 지원하는 언어에선 상속으로 인해 중복 코드가 늘어날 수 있다.

기본 정책과 부가 정책 조합하기

• 10장의 핸드폰 과금 시스템에 새로운 ‘부가 정책’을 추가해야 한다.
  • 기존엔 일반 요금제와 심야 할인 요금제라는 두 ‘기본 정책’인 요금제가 존재
  • 세금 정책은 ‘부가 정책’이었다.
  • 부가 정책은 통화량과 무관하게 기본 정책에 선택적으로 추가할 수 있는 요금 방식
• 부가 정책의 특성
  • 기본 정책의 계산 결과에 적용
  • 선택적으로 적용 가능
  • 조합 가능
  • 임의의 순서로 적용 가능
• 기본 정책과 부가 정책의 조합 가능 수가 많기에 다양한 조합을 수용하도록 유연한 설계가 필요하다.

상속을 이용해서 기본 정책 구현하기

• 추상 클래스 Phone
  • RegularPhone (일반 요금제)
  • NightlyDiscountPhone (심야 요금제)
  • 위 두 자식 클래스는 부가 정책은 적용되지 않은 기본 정책만으로 요금을 계산한다.

기본 정책에 세금 정책 조합하기

• 우선 기본 정책으로 계산된 요금에 부가 정책을 적용해야 하기에 Phone에 새로 메서드를 추가해야 한다.

public abstract class Phone {
    private List<Call> calls = new ArrayList<>();

    public Money calculateFee() {
        Money result = Money.ZERO;
        for(Call call : calls) {
            result = result.plus(calculateCallFee(call));
        }
        return afterCalculated(result);
    }

    protected abstract Money calculateCallFee(Call call);
    
    protected Money afterCalculated(Money fee) {
        return fee;
    }
}

• 부가 정책이 존재하지 않는 RegularPhone과 NightlyDiscountPhone이 일일이 afterCalculated를 오버라이드 하지 않게 하기 위해 기본 구현을 제공한 것

public class TaxableRegularPhone extends RegularPhone {
    private double taxRate;

    public TaxableRegularPhone(Money amount, Duration seconds, double taxRate) {
        super(amount, seconds);
        this.taxRate = taxRate;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.plus(fee.times(taxRate));
    }
}

public class TaxableNightlyDiscountPhone extends NightlyDiscountPhone {
    private double taxRate;

    public TaxableNightlyDiscountPhone(Money nightlyAmount, Money regularAmount, Duration seconds, double taxRate) {
        super(nightlyAmount, regularAmount, seconds);
        this.taxRate = taxRate;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.plus(fee.times(taxRate));
    }
}

• 다양한 기본 정책과 부가 정책 조합을 사용하려면 각 인스턴스를 생성하면 된다.
  • TaxableRegularPhone: 일반 요금제에 세금 적용
  • TaxableNightlyDiscountPhone: 심야 요금제에 세금 적용
  • 하지만 문제는 위 두 세금 정책을 적용한 클래스의 코드에 중복이 발생한다는 점이다.
  • 단일 상속만 지원하는 상황에서 중복을 해결하기는 쉽지 않다.

기본 정책에 기본 요금 할인 정책 조합하기

• 두 번째 부가 정책인 ‘기본 요금 할인’을 적용해보자.
  • 일반 요금제 + 기본 요금 할인 = RageDiscountableRegularPhone
  • 심야 요금제 + 기본 요금 할인 = RateDiscountableNightlyDiscountPhone

public class RateDiscountableRegularPhone extends RegularPhone {
    private Money discountAmount;

    public RateDiscountableRegularPhone(Money amount, Duration seconds, Money discountAmount) {
        super(amount, seconds);
        this.discountAmount = discountAmount;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.minus(discountAmount);
    }
}

public class RateDiscountableNightlyDiscountPhone extends NightlyDiscountPhone {
    private Money discountAmount;

    public RateDiscountableNightlyDiscountPhone(Money nightlyAmount,
                                                Money regularAmount, Duration seconds, Money discountAmount) {
        super(nightlyAmount, regularAmount, seconds);
        this.discountAmount = discountAmount;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.minus(discountAmount);
    }
}

중복 코드의 덫에 걸리다.

• 상속을 이용한 해결은 모든 조합별로 자식 클래스를 하나씩 추가해야 한다.
  • 일반 요금제 + 세금 + 기본 요금 할인을 추가하려면 TaxableAndRateDiscountableRegularPhone을 추가해야 한다.
  • 일반 요금제에 기본 요금 할인을 적용 후 나중에 세금을 부과하려면 RateDiscountableAndTaxableRegularPhone을 추가해야 한다.
• 상속은 복잡성도 문제지만 이렇게 새로운 정책을 추가하기 어렵다.
  • 상속 계층이 계속 늘어나고 깊어질 것이다.
• 클래스 폭발 (class explosion) 또는 조합의 폭발 (combinational explosion)
  • 상속의 남용으로 기능 추가를 위해 많은 수의 클래스를 추가해야 하는 경우
  • 구현에 강하게 결합되도록 강요하는 상속의 한계로 인한 문제
  • 컴파일타임에 결정된 부모-자식 관계는 변경될 수 없기에 발생하는 문제

03 합성 관계로 변경하기

• 상속 관계는 클래스 폭발 문제를 야기한다.
  • 컴파일타임에 결정된 관계를 런타임에 변경할 수 없기 때문
• 합성 관계는 클래스 폭발 문제를 해결한다.
  • 런타임에 관계를 동적으로 변경할 수 있기 때문
  • 구현 시점에 정책들의 관계를 고정시킬 필요가 없다.
• 컴파일타임 의존성과 런타임 의존성 거리가 멀면 코드를 이해하기 어려워진다.
  • 하지만 설계는 변경과 유지보수를 위해 존재한다.
  • 단순한 설계도 좋지만 변경에 따르는 고통이 복잡성으로 인한 혼란을 넘어선다면 유연성을 지켜라

기본 정책 합성하기

• 각 정책을 별도 클래스로 구현해야 한다.

// 기본 정책과 부가 정책을 포괄하는 인터페이스
public interface RatePolicy {
    Money calculateFee(Phone phone);
}

// 기번 정책 추상 클래스
public abstract class BasicRatePolicy implements RatePolicy {
    @Override
    public Money calculateFee(Phone phone) {
        Money result = Money.ZERO;
        for(Call call : phone.getCalls()) {
            result.plus(calculateCallFee(call));
        }
        return result;
    }

    protected abstract Money calculateCallFee(Call call);
}

// 일반 요금제
public class RegularPolicy extends BasicRatePolicy { ... }

// 심야 할인 요금제
public class NightlyDiscountPolicy extends BasicRatePolicy { ... }

• 이제 Phone을 기본 정책을 이용해 요금을 계산하도록 수정할 수 있다.
  • RatePolicy를 의존하는 부분이 바로 합성이다.
  • 합성하는 객체 타입을 인터페이스 또는 추상 클래스로 선언함으로써 런타임에 의존성을 설정할 수 있게 되었다.

public class Phone {
    private RatePolicy ratePolicy;
    private List<Call> calls = new ArrayList<>();

    public Phone(RatePolicy ratePolicy) {
        this.ratePolicy = ratePolicy;
    }

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

    public Money calculateFee() {
        return ratePolicy.calculateFee(this);
    }
}

부가 정책 적용하기

• 부가 정책의 특성을 지키며 구현하려면 다음 제약이 필요하다.
  • 다른 기본 정책이나 부가 정책 인스턴스를 참조할 수 있어야 한다.
  • Phone 입장에선 자신이 메시지를 전달하는 대상이 기본 정책인지, 부가 정책인지 몰라야 한다.
  • 즉 RatePolicy는 또 다른 RatePolicy를 합성할 수 있어야 한다.

// 부가 정책
public abstract class AdditionalRatePolicy implements RatePolicy {
    private RatePolicy next;

    public AdditionalRatePolicy(RatePolicy next) {
        this.next = next;
    }

    @Override
    public Money calculateFee(Phone phone) {
        Money fee = next.calculateFee(phone);
        return afterCalculated(fee) ;
    }

    abstract protected Money afterCalculated(Money fee);
}

// 세금 정책
public class TaxablePolicy extends AdditionalRatePolicy {
    private double taxRatio;

    public TaxablePolicy(double taxRatio, RatePolicy next) {
        super(next);
        this.taxRatio = taxRatio;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.plus(fee.times(taxRatio));
    }
}

// 기본 할인 정책
public class RateDiscountablePolicy extends AdditionalRatePolicy {
    private Money discountAmount;

    public RateDiscountablePolicy(Money discountAmount, RatePolicy next) {
        super(next);
        this.discountAmount = discountAmount;
    }

    @Override
    protected Money afterCalculated(Money fee) {
        return fee.minus(discountAmount);
    }
}

기본 정책과 부가 정책 합성하기

• 이제 정책들을 조합해서 다양한 요금제 계산을 구현할 수 있다.

// 일반 요금제에 세금 정책 조합
Phone phone = new Phone(
        new TaxablePolicy(0.05, new RegularPolicy(...));

// 일반 요금제에 기본 요금 할인 정책을 조합한 결과에 세금 정책 조합
Phone phone = new Phone(
        new TaxablePolicy(0.05, 
            new RateDiscountablePolicy(Money.wons(1000),
                new RegularPolicy(...)));

// 심야 요금 할인제에 기본 요금 할인 정책을 조합한 결과에 세금 정책 조합
Phone phone = new Phone(
        new TaxablePolicy(0.05, 
            new RateDiscountablePolicy(Money.wons(1000),
                new NightlyDiscountPolicy(...)));

• 순서를 바꾸고 싶으면 의존성 주입 순서를 변경하면 된다.
• 객체를 조합하고 사용하는 방식이 더 예측 가능하고 일관성이 있다.

새로운 정책 추가하기

• 합성 기반 설계에서 새로운 정책을 추가하려면 클래스 ‘하나’만 추가한 후 원하는 방식으로 조합하면 된다.
• 조합의 수만큼 새로운 클래스를 추가해야 했던 상속에 비해 변경이 쉽다.
• 더 중요한 것은 요구사항 변경 시 하나의 클래스만 수정해도 된다.
  • 세금 정책을 변경하려면 TaxablePolicy만 변경하면 된다.

객체 합성이 클래스 상속보다 더 좋은 방법이다

• 코드를 재사용하면서 건전한 결합도를 유지할 수 있는 방법이 바로 합성이다.
  • 상속은 부모의 세부 구현을 자식에 강하게 결합시켜 코드의 진화를 방해한다.
• 상속은 두 가지로 나눌 수 있다.
  • 구현 상속
  • 인터페이스 상속
• 이번 장에서 설명한 상속의 단점은 구현 상속에 국한된다.
  • 13장에서 구현 상속을 피하고 인터페이스 상속을 사용해야 하는 이유를 알게 된다.

04 믹스인

• 믹스인(mixin)
  • 객체 생성 시 코드 일부를 클래스 안에 섞어 재사용하는 기법
  • 합성이 실행 시점에 객체를 조합한다면 믹스인은 컴파일 시점에 코드 조각을 조합해 코드를 재사용한다.
• 믹스인은 상속과 비슷하지만 상속과 달리 결합도 문제를 초래하지 않는다.
• 스칼라 언어의 트레이트(trait)로 믹스인 구현 예제를 살펴보자
  • 이 외에 방법이 무엇이든 코드 안에 다른 코드를 유연하게 섞어 넣을 수 있다면 믹스인이라 부를 수 있다.

기본 정책 구현하기

• 기본 정책 구현은 자바와 거의 유사하다.

abstract class BasicRatePolicy { // 기본 정책
  def calculateFee(phone: Phone): Money = phone.calls.map(calculateCallFee(_)).reduce(_ + _)
  
  protected def calculateCallFee(call: Call): Money;
}

// 표준 요금제
class RegularPolicy(val amount: Money, val seconds: Duration) extends BasicRatePolicy {
  override protected def calculateCallFee(call: Call): Money = ...
}

// 심야 할인 요금제
class NightlyDiscountPolicy(
    val nightlyAmount: Money,  
    val regularAmount: Money,
    val seconds: Duration) extends BasicRatePolicy {   
  
  override protected def calculateCallFee(call: Call): Money = ... 
}

object NightltDiscountPolicy {
  val LateNightHour: Integer = 22
}

트레이트로 부가 정책 구현하기

• 스칼라에서 조합해서 확장할 수 있는 기능을 트레이트로 구현할 수 있다.

// 세금 정책 트레이트
trait TaxablePolicy extends BasicRatePolicy {
  val taxRate: Double
  override def calculateFee(phone: Phone): Money = {
    val fee = super.calculateFee(phone)
    return fee + fee * taxRate
  }
}

• TaxablePolicy 트레이트가 BasicRatePolicy를 확장한다.
  • 이는 상속의 개념이 아니다.
  • 단지 세금 정책이BasicRatePolicy나 BasicRatePolicy 자손에 해당하는 경우에만 믹스인될 수 있다는 것을 의미
  • 부가 정책이 기본 정책에 대해서만 적용 가능하기 원하기 때문에 코드로 이 의미를 명확하게 전달하고 제약할 수 있다.
• 트레이트가 상속을 받으면 자바의 상속과 달리 자식 트레이트가 되는 것이 아니다.
  • 트레이트가 사용될 수 있는 문맥을 제한할 뿐이다.
  • TaxablePolicy는 RegularPolicy나 NightlyDiscountPolicy, 그리고 후에 추가될 BasicRatePolicy의 자식에게만 믹스인될 수 있다.
• 믹스인은 상속과 달리 동적이다.
  • 제약을 둘 뿐 어떤 코드에 믹스인될지 결정하지 않는다.
  • super 호출로 실행되는 메서드 또한 컴파일타임이 아닌 트레이트가 실제로 믹스인되는 시점에 결정된다.

부가 정책 트레이트 믹스인하기

• 스칼라에서 extends와 with 키워드로 믹스인할 수 있다.
  • 믹스인 대상 클래스의 부모 클래스는 extends를 이용해 상속
  • 트레이트는 with로 믹스인
  • 이를 트레이트 조합 (trait composition)이라 부른다.

class TaxableRegularPolicy(
    amount: Money, 
    seconds: Duration, 
    val taxRate: Double) 
  extends RegularPolicy(amount, seconds) // 조합될 클래스
  with TaxablePolicy // 믹스인할 클래스

• 선형화 (linearization)
  • 특정 클래스에 믹스인한 클래스와 트레이트로 어떤 메서드를 호출할지 결정하는 것
  • 클래스 자신, 조상 클래스, 트레이트를 일렬로 나열해 순서를 정한다.
  • super를 통해 다음 단계의 클래스나 트레이트 메서드를 호출
  • TaxableRegularPolicy의 경우 자신 → TaxablePolicy 트레이트 → RegularPolicy
  • 어떤 클래스에 믹스인할지에 따라 동적으로 변경될 수 있다.
• 여러 정책을 조합할 때도 믹스인을 통해 조합할 수 있다.

class RateDiscountableAndTaxableRegularPolicy(
    amount: Money, 
    seconds: Duration, 
    val discountAmount: Money,
    val taxRate: Double)
  extends RegularPolicy(amount, seconds) // 표준 요금제
  with TaxablePolicy // 세금 정책을 적용 후
  with RateDiscountablePolicy // 비율 할인 정책 적용
  
class TaxableAndRateDiscountableRegularPolicy(
    amount: Money, 
    seconds: Duration, 
    val discountAmount: Money,
    val taxRate: Double)
  extends RegularPolicy(amount, seconds) // 표준 요금제에 
  with RateDiscountablePolicy // 비율 할인 정책 적용 후
  with TaxablePolicy // 세금 정책 적용

• 믹스인을 사용하더라도 클래스 폭발 문제는 여전히 남아있다.
  • 클래스 폭발의 단점은 클래스 수의 증가가 아닌 중복 코드 수가 늘어난다는 점
  • 믹스인에선 중복 코드로 인한 단점은 없다.
• 클래스를 추가하는 것이 싫다면 아래처럼 인스턴스 생성 시 트레이트를 믹스인할 수도 있다.
  • 하지만 여러 곳에서 동일한 트레이트를 믹스인해야 한다면 클래스를 정의하는 것이 좋다.

new RegularPlicy(Money(100), Duration.fSeconds(10))
    with RateDiscountPolicy
    with TaxablePolicy {
  val discountAmount = Money(100)
  val taxRate = 0.02
}

쌓을 수 있는 변경

• 믹스인을 추상 서브클래스라 부르기도한다.
  • 믹스인은 상속 계층 안에서 확장한 클래스보다 더 하위에 위치한다.
  • 믹스인은 대상 클래스의 자식 클래스처럼 사용될 용도
• 쌓을 수 있는 변경 (stackable modification)
  • 믹스인을 사용하면 특정 클래스에 대한 변경, 확장을 독립적으로 구현한 후 필요 시점에 차례대로 추가할 수 있다.