일관성 있는 협력
- 객체들은 협력하기 위해 존재함
- 일관성 있는 협력 패턴을 사용하면 코드를 이해하기 쉽고 직관적이며 유연하도록 만듦
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. 일관성 있는 기본 정책 구현하기
변경 분리하기
- 일관성 있는 협력을 만들기 위한 첫 번째 단계는 변하는 개념과 변하지 않는 개념을 분리하는것