[오브젝트 스터디] Chapter 05 책임 할당하기

4장에서는 데이터 중심 설계의 문제점에 대해 알아봤습니다.

문제점을 요약하자면 데이터 중심 설계는 행동보다 데이터를 먼저 결정하고, 협력이라는 문맥을 벗어나 고립된 객체의 상태에 초점을 맞추기 때문에 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려운 문제점들이 있었습니다.

 

책임 주도 설계를 하는데  도움을 주는 GRASP(General Responsibility Assignment Software Pattern) = 일반적인 책임 할당을 위한 소프트웨어 패턴을 이번 챕터에서 배워 볼 것입니다. GRASP 패턴은 객체에게 책임을 할당할때 지침으로 삼을 수 있는 원칙들의 집합을 패턴형식으로 정리한 것입니다.

 

책임 주도 설계 과정 REMIND

1. 시스템이 사용자에게 제공해야하는 기능인 시스템 책임을 파악한다.
2.  시스템 책임을 더 작은 책임으로 분할한다.
3.  분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
4.  객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
5.  해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 된다.

3장에서 무슨 말인지 몰랐던 것이 이제서야 조금씩 무슨 말인지 알겠습니다.

 

이게 과정이 책임주도 설계의 큰 틀이고 GRASP 패턴은 책임을 누구에게 어떻게 할당하고, 어떻게 협력 구조를 맺을지에 대한 구체적인 패턴을 제공합니다. GRASP패턴에 따라 책임 주도 설계를 하려면 아래 순서대로 해봅시다.

1. 도메인 개념에서 출발하기

설계를 시작하기전에 도메인에 대한 개략적인 모습을 그립니다. 이 도메인은 완벽하지 않아도 되고 코드의 구조를 위해 도메인을 바꾸는 경우도 있습니다.

 

2. 정보 전문가에게 책임을 할당하라

챕터3에서 배웠던 정보 전문가 (INFORMATION EXPERT) 패턴에 대해 다시 상기 시켜봅시다.

객체에게 책임을 할당할때는 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것입니다.

 

우리는 영화를 예매하는 애플리케이션을 만든다고 가정해봅시다. 그러면 가장 먼저 예매 하라는 메세지를 전송해야합니다.

 

그런데 예매를 가장 잘 알아서 처리 해줄 객체는 뭘까요? Screening입니다. Screening(상영) 클래스는 영화 정보, 상영시간, 상영 순번등 예매를 위한 정보를 가장 잘 알고 있는 객체에게 예매의 책임을 맡깁니다. 이어서 예매를 하려면 티켓의 가격을 계산해야하는데

Screening은 이것을 잘 알고 있지 않습니다. 다시 Movie에게 계산을 할 책임을 넘깁니다. 이런 반복적인 메세지 전송과 수신을 통해

협력 공동체가 구성되는 것입니다.

 

 

3. 가장 높은 응집도와 낮은 결합도를 가지고 있는 것을 골라라.

그러나 위에 전문가 패턴을 사용하더라도 몇가지 설계 중에 선택해야하는 일이 생깁니다.

 

이럴때는 어떤 것을 결정해야 할까요?

비교해서 가장 높은 응집도와 가장 낮은 결합도를 가지고 있는 것을 고르면 됩니다.

 

 

이를 LOW COUPING 패턴과 HIGH COHESION 패턴이라고 부릅니다.

 

책임을 할당하고 코드를 작성하는 매순간마다 LOW COUPING과 HIGH COHESION의 관점에서 전체적인 설계 품질을 검토하면 단순하면서도 재사용 가능하고 유연한 설계를 얻을 수 있을 것입니다.

 

4. CREATOR 패턴 적용

영화 예매 협력의 최종 결과물은 Reservation 인스턴스를 생성하는 것입니다.

CREATOR(창조자) 패턴은 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공합니다.

 

Reservation을 잘 알고 있거나 긴밀하게 사용하거나 초기화에 필요한 데이터를 가지고 있는 객체는 Screening이기 때문에 Screening을 CREATOR로 선택합니다.

 

 

대략적으로 완성된 모습

 

이하 구현은 생략하겠습니다.

 

책임주도설계는 쉽지않은 것입니다. 위에 처럼 딱딱 설계되면 이상적이겠지만 현실은 그렇지 않죠.

이 책을 쓴 저자 또한 그저 일단 최대한 빠르게 목적한 기능을 수행하는 코드를 작성하고 올바른 위치로 책임들을 이동시키자고 합니다.

 

리팩토링 과정 생략하겠습니다.

 

책임주도설계 방법이 익숙하지 않다면 일단 데이터 중심으로 구현한 후 이를 리팩토링하더라도 유사한 결과를 얻을 수 있다는 것을 말해줍니다.

 

결국 안돌아가지만 잘 설계된 코드보다 잘 설계되진 못했지만 잘 돌아가는 코드가 더 낫다는 것입니다.