PATTERNS & PRINCIPLES

INTENTION-REVEALING INTERFACE

MoneyTest.java
@Test

public void equals() {

  Money won200 = Money.wons(200);

  assertEquals(Money.wons(200), won200);

  Money dollar200 = Money.dollars(200);

  assertFalse(won200.equals(dollar200));

}

private static final RoundingMode DEFAULT_ROUNDING = RoundingMode.HALF_EVEN;

public static Money valueOf(long amount, Currency currency,
    RoundingMode rounding) {

  return valueOf(BigDecimal.valueOf(amount), currency, rounding);

}

public static Money valueOf(double amount, Currency currency,
    RoundingMode rounding) {

  return valueOf(BigDecimal.valueOf(amount), currency, rounding);

}

public static Money valueOf(BigDecimal amount, Currency currency,
    RoundingMode rounding) {

  return new Money(amount, currency, rounding);

}

Money(BigDecimal amount, Currency currency) {

  this(amount, currency, DEFAULT_ROUNDING);

}

Money(BigDecimal amount, Currency currency, RoundingMode rounding) {

  this.amount = amount.setScale(currency.getDefaultFractionDigits(), rounding);

  this.currency = currency;

}

PATTERN & PRINCIPLE

STANDALONE CLASS

소프트웨어에서 발생하는 문제의 원인은 대부분 의존성(dependency)과 관련 있다. 단위 테스트를 작성하려고 하는데 테스트 대상 객체가 데이터베이스에 의존하고 있다면 테스트를 작성하기가 어려워 진다. 공용 인터페이스를 수정하려고 하는데 인터페이스에 의존하고 있는 클래스들이 많다면 인터페이스를 수정하기 어려워 진다. 라이브러리의 버전을 변경하려고 하는데 라이브러리에 의존하는 코드가 애플리케이션 여기 저기에 흩어져 있다면 변경하기가 어려워 진다.

낮은 결합도와 높은 응집도라는 소프트웨어 설계 구호는 의존성의 딜레마를 잘 보여준다. 결합도가 높아지면 소프트웨어를 이해하고 유지보수하기 어려워진다. 따라서 낮은 결합도를 유지하는 것이 좋다. 그러나 응집도를 높이기 위해서는 어느 정도의 결합도는 유지해야할 필요가 있다.

따라서 문제의 초점을 적절한 의존성과 부적절한 의존성을 구별하는 방법으로 옮기는 것이 적절할 것이다. 의존성이 많아지면 객체를 이해하기가 어려워진다. 의존성이 많다는 것은 한 번에 생각해야 하는 개념의 수가 증가한다는 것을 의미한다. 인지 과부하를 초래하는 모든 의존성은 공공의 적이다. 얽히고 설킨 의존성 더미 속에서 핵심 개념을 찾기 위해 동시에 생각해야할 경우의 수에 압도당하고 있다고 느낀다면 의존성이 너무 많다는 증거다.

소프트웨어 개발은 저글링(juggling)과 유사하다. 한 번에 여러 개의 공을 공중에 띄워 놓기 위해 발버둥치지만 그 수가 한계치를 넘어서는 순간 모든 공이 땅에 떨어지고 만다. 한 번에 다룰 수 있는 공의 개수를 조절하는 것이 의존성 관리의 핵심이다.

STANDALONE CLASS 패턴의 목적은 극적으로 낮은 결합도를 유지하는 것이다. 만약 어떤 개념을 이해하는데 다른 개념이 불필요하다면 이를 제거하라. 불필요한 인지 과부하의 요인을 제거함으로써 개발자가 문제의 핵심을 효과적으로 다룰 수 있도록 하라.

STANDALONE CALSS가 외부 의존성을 완전히 제거한다는 것을 의미하는 것은 아니다. 핵심은 불필요한 개념을 없앰으로써 한 번에 처리할 수 있는 개념의 수를 극적으로 낮춘다는 것이다. 따라서 표준 정수형이나 문자열과 같은 기본 타입이나 JDK에서 제공하는 표준 라이브러리에 대한 의존성은 정신적 부담을 지우지 않기 때문에 제거할 필요가 없다.

STANDALONE CALSS가 다루는 의존성이 물리적인 의존성이 아니라 개념적인 의존성을 의미한다는 점에 주의해야 한다. Money에 있어 반올림 모드는 통화를 처리하기 위한 핵심 개념이다. 따라서 만약 표준 라이브러리에서 RoundingMode를 제공하지 않는다면 기존의 방식대로 Rounding이라는 개념을 만들고 Money가 Rounding에 의존하도록 만드는 것은 문제가 되지 않는다. 오히려 Rounding을 명시적인 개념으로 만들지 않을 경우 모델 내에 반올림이라는 개념이 암시적으로 존재하게 되어 암시적인 개념을 찾기 위한 개발자의 정신적 부담이 증가하게 된다.

Money는 Currency나 RoudningMode와 같이 표준 라이브러리에 속하는 클래스들에만 의존하도록 함으로써 Money를 이해하는데 필요한 개념의 수를 줄인다. Money를 통해 STANDALONE CLASS 패턴의 장점을 느껴보기 바란다. 

이 문제를 해결할 수 있는 가장 좋은 방법은 반올림 모드를 표현하는 새로운 타입을 추가하는 것이다. 즉, int형 대신 Rounding 타입을 정의하여 이 타입을 받도록 메소드 시그니처를 변경하는 것이다. 매개변수로 Rounding 타입을 사용하도록 변경할 경우 의도를 더 명확하게 드러내고 내부 구현을 깔끔하게 캡슐화할 수 있다.

먼저 BigDecimal 상수를 사용하던 테스트 케이스를 Rounding을 사용하도록 변경하자.

MoneyTest.java

@Test

public void roundingDollarEquals() {

  Money dollar20_75 =
      Money.valueOf(20.7576, Currency.getInstance("USD"), Rounding.DOWN);

  assertEquals(Money.valueOf(20.75, Currency.getInstance("USD")),
      dollar20_75);

  Money dollar20_76 =
      Money.valueOf(20.7512, Currency.getInstance("USD"), Rounding.UP);

  assertEquals(Money.valueOf(20.76, Currency.getInstance("USD")),
      dollar20_76);

}

핸드폰 과금 시스템의 핵심 요구사항 중 하나는 다중 통화(Currency)의 지원과 환율에 따른 요금 변환이다. 출장 차 미국에 간 핸드폰 가입자가 로밍 서비스를 사용하고 있다고 가정하자. 가입자가 로밍 서비스를 사용할 경우 사용 요금이 미달러화로 통지된다. 시스템은 통지 시점의 환율에 맞춰 미달러화를 원화로 변환한 후 사용자에게 요금을 청구한다. 따라서 시스템은 다중 통화와 환율, 환전이라는 3가지 도메인 개념을 처리할 수 있어야 한다.

자, 심호흡을 크게 하고 테스트 주도 개발(Test-Driven Development) 방식에 몸을 맡겨 보자. 어떤 테스트 케이스부터 작성해 볼까? 아니 질문을 바꿔야겠다. 어떤 테스트 케이스를 가장 쉽게 통과시킬 수 있을까?

가장 먼저 떠오르는 테스트 케이스는 특정 시점의 환율에 따라 미달러화를 원화로 환전한 결과를 테스트하는 것이다. 하지만 이 테스트 케이스를 통과시키기가 그리 녹록하지만은 않을 것 같다. 원화를 달러로 바꾸려면 환율 개념이 필요하고 금액에 환율을 곱하는 부분도 필요하다. 음... 동시에 두 가지를 다 해결하기는 어려워 보인다. 한 가지씩 해결하도록 하자.

환율 개념의 구현과 금액의 곱셈 중 곱셈 쪽이 더 간단해 보인다. 우선 금액의 곱셈 문제부터 해결한 후 환율에 따른 통화 변환 문제를 해결하도록 하자. 지금 당장 통과 시킬 수 있는 가장 간단한 작업으로 시작하는 것이 TDD의 기본 전략이다. 과도한 사전 설계(big up front design)에 익숙한 사람들에게는 조금 생소하게 들릴지도 모르지만 지금 당장 필요한 아주 작은 부분에 초점을 맞추면서 점점 시스템을 성장시켜 나가는 접근 방법을 취할 것이다.