14장: 일관성 있는 협력

변경을 분리하고 캡슐화하기

  • 유사한 요구사항에 대해 각 협력이 서로 다른 패턴으로 구현되어 있다면 전체적인 설계의 일관성이 무너지고 비용이 증가한다.

  • 유사한 기능을 구현하기 위해 일관성 있는 유사한 협력 패턴을 사용하면 시스템을 이해하고 확장하기 위해 요구되는 정신적인 부담을 크게 줄일 수 있다.

  • 일관성 있는 설계를 만드려면 다양한 설계 경험을 익히고 널리 알려진 디자인 패턴을 학습하여 적용해보는 것이 필요하다.

  • 늘 강조해왔듯, 변하는 개념과 변하지 않는 개념을 분리하고 변하는 개념은 캡슐화해야 한다. 여기서 캡슐화란 단순히 데이터를 감추는 것이 아니라 소프트웨어 안에서 변할 수 있는 모든 ‘개념’을 감추는 것이다.

  • 캡슐화에는 클래스 내부 데이터를 캡슐화하는 데이터 캡슐화, 클래스의 내부 행동을 캡슐화하는 메서드 캡슐화, 합성을 사용해 객체를 캡슐화하는 객체 캡슐화, 실행 시점에 어떤 객체가 올 지 확인하도록 하는 서브타입 캡슐화가 존재한다.

  • 서브타입 캡슐화와 객체 캡슐화는 다음과 같은 순서로 적용할 수 있다.

    • 변하는 부분을 분리한 후 공통적인 행동을 추상 클래스/인터페이스로 정의하고 이를 상속받도록 한다.

    • 변하지 않는 부분에 타입 계층을 합성(composite)하여 추상화에 의존하게 만든다.

  • 변경의 이유에 따라 캡슐화할 수 있는 다양한 방법을 디자인 패턴에서 제시하므로 공부해보는 게 좋다.

  • 다형성은 조건 로직을 객체 사이의 이동으로 바꾸기 위해 객체지향이 제공하는 설계 기법이다.

협력 패턴 구현하기

요구사항

  • 여러가지 통화 요금 책정 방식이 존재할 수 있다.

  • 아래는 그 중 한 방식인 시간대별 방식을 그림으로 나타낸 것이다. 1월1일 0시부터 1월3일 24시까지 통화가 이뤄졌고, 이 통화 내역을 시간대별로 분리하여 각각 다른 요금을 부과해야 한다.

설계

  • 모든 작업을 객체의 책임으로 생각하고, 아래와 같이 객체를 설계한다.

    • BasicRatePolicy

      • 사용자로부터 통화 목록이 담긴 핸드폰을 전달받으면 해당 핸드폰의 통화 요금을 반환한다.

    • FeeRule

      • 시간대별로 분리된 통화 내역을 기반으로 가격을 계산한다.

    • FeeCondition

      • 적용 조건을 표현하는 인터페이스

      • 통화 내역을 전달받고 적용 조건을 만족하는 기간만 잘라 DateTimeInterval의 List로 반환하는 메서드가 있다.

    • FeePerDuration

      • 특정 기간만큼의 통화 요금을 계산해 반환한다.

구현

  • BasicRatePolicy

    • 하나의 통화 기록 당 통화 내역을 분리해 각각 요금을 계산하여 전체 요금을 반환하도록 한다.

public class BasicRatePolicy implements RatePolicy {
	private List<FeeRule> feeRules = new ArrayList<>();
	
	public BasicRatePolicy(FeeRule ... feeRules) {
		this.feeRules = Arrays.asList(feeRules);
	}
	
	@Override
	public Money calculateFee(Phone phone) {
		return phone.getCalls()
			.stream()
			.map(call -> calculate(call))
			.reduce(Money.ZERO, (first, second) -> first.plus(second));
	}
	private Money calculate(Call call) {
		return feeRules
			.stream()
			.map(rule -> rule.calculateFee(call))
			.reduce(Money.ZERO, (first, second) -> first.plus(second));
	}
}

  • FeeCondition

    • 하나의 통화 내역을 전달받고 적용 조건을 만족하는 기간만 잘라 DateTimeInterval의 List로 반환한다.

    • 시간대별 정책, 요일별 정책, 구간별 정책 등이 이 인터페이스를 구현하는 방식으로 표현될 것이다.

public interface FeeCondition {
	List<DateTimeInterval> findTimeIntervals(Call call);
}

  • FeeRule

    • 하나의 통화 내역을 구간별로 잘라 적용 조건에 따른 요금을 계산하여 반환한다.

public class FeeRule {
	private FeeCondition feeCondition;
	private FeePerDuration feePerDuration;
	
	public FeeRule(FeeCondition feeCondition, FeePerDuration feePerDuration) {
		this.feeCondition = feeCondition;
		this.feePerDuration = feePerDuration;
	}
	
	public Money calculateFee(Call call) {
		return feeCondition.findTimeIntervals(call)
			.stream()
			.map(each -> feePerDuration.calculate(each))
			.reduce(Money.ZERO, (first, second) -> first.plus(second));
	}
}

  • FeePerDuration

    • 얼마동안 통화할경우 얼마만큼의 요금이 나올 지 정의하여

public class FeePerDuration {
	private Money fee;
	private Duration duration;
	public FeePerDuration(Money fee, Duration duration) {
		this.fee = fee;this.duration = duration;
	}
	public Money calculate(DateTimeInterval interval) {
		return fee.times(Math.ceil((double)interval.duration().toNanos() / duration.toNanos()));
	}
}

요금 부과 정책 구현

  • FeeCondition을 구현하여 요금 부과 정책 클래스를 만든다.

  • 아래는 시간대별 정책의 적용 조건을 구현하는 클래스로, 시작시간과 종료시간을 담아두고 통화 내역이 입력되면 시작시간과 종료시간에 해당하는 구간만 잘라내 반환한다.

public class TimeOfDayFeeCondition implements FeeCondition {
	private LocalTime from;
	private LocalTime to;
	
	public TimeOfDayFeeCondition(LocalTime from, LocalTime to) {
		this.from = from;
		this.to = to;
	}
	
	@Override
	public List<DateTimeInterval> findTimeIntervals(Call call) {
		return call.getInterval().splitByDay()
			.stream()
			.filter(each -> from(each).isBefore(to(each)))
			.map(each -> DateTimeInterval.of(
				LocalDateTime.of(each.getFrom().toLocalDate(), from(each)),
				LocalDateTime.of(each.getTo().toLocalDate(), to(each))))
			.collect(Collectors.toList());
	}
	
	private LocalTime from(DateTimeInterval interval) {
		return interval.getFrom().toLocalTime().isBefore(from) ?from : interval.getFrom().toLocalTime();
	}
	
	private LocalTime to(DateTimeInterval interval) {
		return interval.getTo().toLocalTime().isAfter(to) ?to : interval.getTo().toLocalTime();
	}
}

  • 아래는 구간별 정책의 적용 조건을 구현하는 클래스로, 특정 구간을 담아두고 통화 내역이 입력되면 구간에 만족하는 통화 기록 조각을 반환한다.

    • 개념적 무결성을 무너뜨리는 것보다는 약간의 부조화를 수용하는 편이 더 낫다.

    개념적 무결성: 일관성과 유사한 의미로, 시스템이 일관성 있는 몇 개의 협력 패턴으로 구성된다면 이해, 수정, 확장에 필요한 노력과 시간을 아낄 수 있다. 좋은 기능들이 서로 독립적이고 조화되지 못한 아이디어들을 담고 있는 시스템보다는 여러가지 다양한 기능이나 갱신된 내용은 비록 빠졌더라도 하나로 통합된 설계 패턴을 반영하는 시스템이 훨씬 좋다.

public class DurationFeeCondition implements FeeCondition {
	private Duration from;
	private Duration to;
	public DurationFeeCondition(Duration from, Duration to) {
		this.from = from;
		this.to = to;
	}
	@Override
	public List<DateTimeInterval> findTimeIntervals(Call call) {
		if (call.getInterval().duration().compareTo(from) < 0) {
			return Collections.emptyList();
		}
		return Arrays.asList(DateTimeInterval.of(
			call.getInterval().getFrom().plus(from),
			call.getInterval().duration().compareTo(to) > 0 ?
			call.getInterval().getFrom().plus(to) :
			call.getInterval().getTo()));
	}
}

  • 협력은 고정된 것이 아니다. 만약 현재의 협력 패턴이 변경을 수용하기 어렵다면 변경의 방향에 맞춰 최선의 협력 패턴을 만들도록 리팩토링해야 한다.

  • 유사한 기능에 대한 변경이 지속적으로 발생하고 있다면 변경을 캡슐화할 수 있는 적절한 추상화를 찾아 반복적으로 적용할 수 있는 협력 구조를 도출하고, 이 추상화에 변하지 않는 공통적인 책임을 할당해야 한다.

Previous13장: 서브클래싱과 서브타이핑Next15장: 디자인 패턴과 프레임워크

Last updated