[오브젝트] 38일차. 483-493pg | 일관성 있는 협력

 

 

38일차.

오브젝트: 코드로 이해하는 객체지향 설계[7주차_화요일]
483-493pg

 
 

#요약

 **Chapter 14. 일관성 있는 협력**

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

1) 기본 정책 확장

2) 고정요금 방식 구현하기

3) 시간대별 방식 구현하기

4) 요일별 방식 구현하기

5) 구간별 방식 구현하기

- 현재 구현의 가장 큰 문제는 이 클래스들이 유사한 문제를 해결하고 있음에도 불구하고 설계에 일관성이 없다는 것.

- 이 클래스들은 기본 정책을 구현한다는 공통의 목적이 있지만 정책을 구현하는 방식은 완전히 다르다.

- 개념적으로는 연관돼 있지만 구현 방식에 있어서는 완전히 제각각

- 유사한 기능을 서로 다른 방식으로 구현해서는 안된다.

- 유사한 기능은 유사한 방식으로 구현해야 한다.

 

 

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

- 일관성 있는 설계를 만드는 데 가장 훌륭한 조언은 다양한 설계 경험을 익히라는 것 그리고 널리 알려진 디자인 패턴을 학습하고 변경이라는 문맥 안에서 디자인 패턴을 적용해 보라는 것.

- 협력을 일관성 있게 만들기 위해 1. 변하는 개념을 변하지 않는 개념으로부터 분리하라. 2. 변하는 개념을 캡슐화하라.

 

1) 조건 로직 대 객체 탐색

- 절차지향 프로그램에서 변경을 처리하는 전통적인 방법은 조건문의 분기를 추가하거나 개별 분기 로직을 수정하는 것.

- 객체지향에서 변경을 다루는 전통적인 방법은 조건 로직을 객체 사이의 이동으로 바꾸는 것.

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

- 조건 로직을 객체 사이의 이동으로 대체하기 위해서는 커다란 클래스를 더 작은 클래스들로 분리해야 한다. 그러면 분리하기 위한 기준은? - 변경의 이유와 주기

- 클래스는 명확히 단 하나의 이유에 의해서만 변경돼야 하고 클래스 안의 모든 코드는 함께 변경돼야 한다.

- 따라서. 단일책임 원칙을 따르도록 클래스를 분리해야 한다는 것.

 

- 일관성 있는 협력을 위한 지침1 : 변하는 개념을 변하지 않는 개념으로부터 분리하ㅏ.

- 일관성 있는 협력을 위한 지침2 : 변하는 개념을 캡슐화하라. 핵심은 훌륭한 추상화를 찾아 추상화에 의존하도록 만드는 것.