일관성 있는 협력

  • 객체들은 협력하기 위해 존재함
  • 일관성 있는 협력 패턴을 사용하면 코드를 이해하기 쉽고 직관적이며 유연하도록 만듦

01. 핸드폰 과금 시스템 변경하기

기본 정책 확장

  • 11장에서 구현한 핸드폰 과금 시스템의 요금 정책을 수정
  • 새로운 4가지의 기본 정책들
    • 고정요금 방식 (FixedFeePolicy)
    • 시간대별 방식 (TimeOfDayDiscountPolicy)
    • 요일별 방식 (DayOfWeekDiscountPolicy)
    • 구간별 방식 (DurationDiscountPolicy)

고정요금 방식 구현하기

  • 요금측정 방식
    • A초당 B원
  • 기존의 일반요금제와 동일하기 때문에 이름만 변경

시간대별 방식 구현하기

  • 요금측정 방식
    • A시부터 B시까지 C초당 D원
    • E시부터 F시까지 C초당 H원
  • 시간대별을 포함하는 클래스(DateTimeInterval)를 추가
    • 통화(Call) 클래스는 DateTimeInterval를 가짐
  • 전체 통화시간 다음과 같이 두 단계로 구현
    • 통화 기간을 일자별로 분리
    • 일자별로 분리된 기간을 시간대별로 분리하고 각 기간에 대한 요금 계산
  • 두 작업을 객체의 책임으로 할당하면?
    • DateTimeInterval에 통화를 일자별로 분리하는 책임을 할당하고 Call이 DateTimeInterval에에게 분할 요청하도록 협력을 설계하는것이 적절
    • 시간대별 요금정책을 위한 TimeOfDayDiscountPolicy 클래스가 시간대별로 분리하는 책임을 가짐
    • 4개의 리스트를 갖는 Policy 클래스 구현

요일별 방식 구현하기

  • 정책
    • 평일에슨 A초당 B원
    • 공휴일에는 A초당 C원
  • 요일별 방식을 구성하는 규칙이 포함된 DayOfWeekDiscountRule 클래스를 구현
  • 시간대별 방식에서는 4개의 리스트를 가지고 규칙을 정의했지만 요일별 방식은 위 클래스로 규칙을 표현

구간별 방식 구현하기

  • 정책
    • 초기 A분 동안 B초당 C원
    • A분 ~ D분까지 B초당 D원
    • D분 초과 시 B초당 E원
  • 지금까지의 방식을 살펴보면 요금 계산, 응집도와 결합도 측면에서 특별히 문제는 없어보임
  • 클래스들을 각각 보면 그럭저럭 괜찮아 보이지만 함께 모아놓고 보면 그동안 보이지 않던 문제점이 보이기 시작함
  • 가장 큰 문제는 비슷한 문제를 해결하고 있음에도 불구하고 설계에 일관성이 없음
  • 비일관성은 두 가지 상황에서 발목을 잡음
    • 새로운 구현을 추가해야할때
    • 기존 구현을 이해해야하는 상황

02. 설계에 일관성 부여하기

  • 일관성 있는 설계를 만드는데 있어 두 가지 조언
    • 가장 훌륭한 조언은 다양한 설계 경험을 익히라는 것
    • 두 번째 조언은 널리 알려진 디자인 패턴을 익히라는 것
  • 협력을 일관성 있게 만드는 기존 지침
    • 변하는 개념을 변하지 않는 개념으로 부터 분리
    • 변하는 개념을 캡슐화

조건 로직 대 객체 탐색

캡슐화 다시 살펴보기

  • 캡슐화는 데이터 은닉(data hiding) 그 이상을 의미

[그림]

  • 다양한 종류의 캡슐화
    • 데이터 캡슐화
    • 메서드 캡슐화
    • 객체 캡슐화
    • 서브타입 캡슐화

03. 일관성 있는 기본 정책 구현하기

변경 분리하기

  • 일관성 있는 협력을 만들기 위한 첫 번째 단계는 변하는 개념과 변하지 않는 개념을 분리하는것

변경 캡슐화하기

협력 패턴 설계하기

추상화 수준에서 협력 패턴 구현하기

구체적인 협력 구현하기

협력 패턴에 맞추기