3장

03 역할, 책임, 협력

03 역할, 책임, 협력

객체지향 패러다임의 관점에서 핵심은 역할 책임 협력이다. 클래스, 상속, 지연 바인딩이 중요하지 않은 것은 아니지만 구현 측면에서 중요한 것이고 객체지향 패러다임의 본질과는 거리가 멀다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다.

객체지향 원칙을 따르는 어플리케이션의 제어 흐름은 다양한 객체들 사이에 균형있게 분배된다.

협력: 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용
책임: 객체가 협력에 참여하기 위해 수행하는 로직
역할: 객체들이 협력 안에서 수행하는 책임들이 모인 객체가 수행하는 것

협력

두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 메시지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 객체는 오직 메시지 전달을 통해서만 자신의 요청을 전달할 수 있다.

협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것이다. 한 객체는 어떤 것이 필요할 때 다른 객체에게  
전적으로 위임하거나 서로 협력한다. 즉, 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다.  
객체 사이의 협력을 설계할 때는 객체를 서로 분리된 인스턴스가 아닌 협력하는 파트너로 인식해야 한다.

객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화 하는 것이다. 변경의 파급 효과를 제한할 수 있어서 변경에도 자유로워진다.

협력이 설계를 위한 문맥을 결정한다.

객체가 가질 수 있는 상태와 행동을 어떤 기준으로 결정해야 할까? 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력으로 협력이 바뀌면 객체가 제공해야 하는 행동 역시 바뀌어야 한다.

Movie의 행동은 영화 예매를 위한 협력에 의해 결정된다. 영화 상영과는 상관이 없다. 협력이 있기 때문에 객체가 존재한다.
객체의 상태를 결정하는 것은 행동이다. 객체는 스스로 상태를 결정하고 관리하기 때문에 객체가 수행하는 행동에 필요한 상태도 가지고 있어야 한다.
객체가 참여하는 협력이 행동과 상태를 결정하기 때문에 협력은 객체를 설계하는데 필요한 문맥을 제공한다.

책임

협력이 갖춰졌을 때 다음 할 일은 협력에 필요한 행동을 수행할 수 있는 적절한 객체를 찾는 것이다. 협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 부른다.

책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합으로 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장이다.

객체의 책임은 객체가 무엇을 알고 있는가와 무엇을 할 수 있는가로 구성된다. 크레이그 라만은 이런 분류 체계에 따라 하는 것과 아는 것의 두 가지 범주로 나누어 세분화하고 있다.

하는 것
- 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작시키는 것
- 다른 객체의 활동을 제어하고 조절하는 것
- 영화 예매 시스템에서 Screening의 책임은 영화를 예매하는 것이다. Movie는 요금을 계산하는 것이다. Screening은 영화를 예매할 수 있어야 한다.
아는 것
- 사적인 정보에 관해 아는 것
- 관련된 객체에 대해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
- Screening은 자신이 상영할 영화를 알고 있어야 한다. Movie는 가격과 어떤 할인 정책이 적용됐는지 알고 있어야 한다.

객체는 자신이 맡은 책임을 수행하는데 필요한 정보를 알고 있을 책임이 있다. 또한 자신이 할 수 없는 작업을 도와줄 객체를 함께 알아야 할 책임이 있다. 책임은 객체지향 설계의 핵심이다. 객체에게 얼마나 적절한 책임을 할당하느냐가 설계의 전체적인 품질을 결정한다.

CRC 카드는 후보(Candidate), 책임(Responsibility), 협력자(Collaborator)의 첫 글자를 따서 만든 것으로 하나의 CRC 카드는 협력에 참여하는 하나의 후보를 표현한다.

책임 할달

자율적인 객체를 만드는 가장 기본적인 방법은 책임을 수행하는데 필요한 정보를 가장 잘 알고있는 전문가에게 그 책임을 할당하는 것이며 이를 책임 할당을 위한 INFORMATION EXPERT(정보전문가) 패턴이라고 부른다.

일상 생활과 똑같이 객체들 역시 협력에 필요한 지식과 방법을 가장 잘 알고있는 객체에게 도움을 요청한다.

객체에게 책임을 할당하기 위해서는 먼저 협력이라는 문맥을 정의해야 한다.
협력을 설계하는 출발점은 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 바라보는 것이다.
객체지향 설계는 시스템의 책임을 완료하는 데 필요한 더 작은 책임을 찾아내고 이를 객체들에게 할당하는 반복적인 과정을 통해 모양을 갖춰간다.

영화 예매 시스템을 예로 정보 전문가에게 책임을 할당하는 방법을 살펴보자.

시스템이 사용자에게 제공할 기능은 영화 예매이고 이 기능을 시스템이 제공할 책임으로 할당한다. 객체가 책임을 수행하게 하는 유일한 방법은 메시지를 전송하는 것이므로 책임을 할당한다는 것은 메시지의 이름을 결정하는 것과 같다. 예매하라 라는 이름의 메시지로 협력을 시작해보자.

영화를 예매하기 위한 상영시간과 기본요금을 잘 알고 있는 전문가는 Screening이다.

Screening은 예매 전문가여도 가격은 모른다. 외부 객체에게 가격 계산을 요청해야 한다.

적절한 객체는 Movie다.

그 다음은 할인 요금을 계산하기 위한 메시지를 보낼 것이다.

객체지향 설계는 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복과정을 통해 이뤄진다. 어떤 경우에는 응집도와 결합도 괁머에서 전문가가 아닌 다른 객체에게 책임을 할당하는 것이 더 적절할 수도 있지만 기본은 정보 전문가를 찾는 것이다.

책임 주도 설계

지금까지의 요점은 협력을 설계하기 위해서는 책임에 초점을 맞춰야 한다는 것이다. 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방식을 책임 주도 설계라고 부른다. 책임 주도 설계 방법의 과정은 다음과 같다.

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

메시지가 객체를 결정한다.

객체에게 책임을 할당하는데 필요한 메시지를 먼저 식별하고 메시지를 처리할 객체를 나중에 선택했다는 것이 중요하다. 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택한다.

이렇게 하면 장점이 다음과 같다.

객체가 최소한의 인터페이스를 가질 수 있게 된다.
- 필요한 메시지가 식별될 때까지 객체의 퍼블릭 인터페이스에 어떤 것도 추가하지 않기 때문에 객체는 꼭 필요한 크기의 인터페이스를 가질 수 있다.
객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.
- 메시지는 외부의 객체가 요청하는 무엇인가를 의미하기 때문에 메시지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 인터페이스를 얻을 수 있다.

행동이 상태를 결정한다.

객체를 객체답게 만드는 것은 객체의 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다.

객체의 행동이 아니라 상태에 초점을 맞추는 행위는 객체의 내부구현이 객체의 퍼블릭 인터페이스에 노출되게 만들기 때문에 캡슐화를 저해한다. 이런 설계 방법을 데이터 주도 설계라고 한다.

역할

객체의 목적은 협력 안에서 객체가 맡게 되는 책임의 집합으로 표시되며 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.

예매하라 라는 메시지를 처리하기 위해 Screening을 선택하는 과정에는

영화를 예매할 수 있는 적절한 역할이 무엇인지 찾는 것
역할을 수행할 객체로 Screening을 선택하는 것

의 과정이 들어있었다.

우연하고 재사용 가능한 협력

역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다.

AmountDistcountPolicy와 PercentDiscountPolicy 모두 할인 요금 계산이라는 동일한 책임을 수행한다. 객체를 지우고 할인 요금을 계산하라라는 메시지에 응답할 수 있는 대표자를 생각한다면 두 협력을 통일할 수 있다.

여기서의 역할은 두 종류의 구체적인 객체를 포괄하는 추상화다. 따라서 이름은 DiscountPolicy다.

객체 대 역할

역할은 객체가 참여할 수 있는 일종의 슬롯이다. 그럼 한 종류의 객체만 협력에 참여하는 상황에서 역할을 고려해야 할까? 협력에 적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주하고 여러 종류의 객체들이 참여할 수 있다면 역할이라고 부르면 된다.

설계 초반에 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목표여야 하고 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지는 않다. 따라서 애매하다면 단순하게 객체로 시작하고 반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다.