[Objects] Chapter3. 역할, 책임, 협력

03. 역할, 책임, 협력

• 객체 지향 패러다임의 관점에서의 핵심은 역할(role), 책임(responsibility), 협력(collaboration)
• 협력하는 객체들의 공동체를 만드는 것이 핵심.

01. 협력

영화 예매 시스템 돌아보기

• 이러한 객체지향의 원칙을 따르는 애플리케이션의 제어 흐름은 어떤 하나의 객체에 의해 통제되지 않는다.
  • 오히려 균형적으로 분배되어 있다.
• 각 객체들이 메시지를 주고 받으며 상호작용한다.
  • 이러한 상호작용이 협력
• 객체가 협력에 참여하기 위해 수행하는 로직 책임
• 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할

협력

• 메시지 전송: 객체 사이의 협력에 사용할 수 있는 유일한 커뮤니케이션 수단
  • 객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없다.
• 메시지를 수신한 객체는 메서드를 수행해 요청에 응답한다.
  • 이 메서드는 수신한 객체가 스스로 선택한다.
  • 자율적이다.
• 그림에서 Screening 은 Movie 에 calculateMovieFee() 라는 메시지를 전송한다.
  • 처리를 위임하는 이유는 요금에 대한 것은 Movie가 제일 잘 알기 때문에
  • 만약 Screening 이 수행한다면?
    • 다른 객체 내부 상태에 접근해야한다.
    • 이는 결합성을 높이고, 자율성을 저해한다.
  • 객체를 가장 자율적으로 만드는 것은 캡슐화
• 캡슐화로 객체를 자율적으로 만든다면 파급효과를 제한 할 수 있다.
• 만약 Screening이 Movie 내부 구현에 직접 접근한다면?
• Movie의 내부 구현을 바꿀 때마다 Screening도 영향을 받는다.
• 자율적인 객체는 자신의 책임을 수행하다 필요한 정보를 모르거나 외부의 도움이 필요하다면
  • 적절한 객체에게 메시지를 보내 협력을 요청한다.
  • 메시지를 수신한 객체 또한 마찬가지
• 협력을 구성하는 일련의 응답과 요청 흐름을 통해 애플리케이션의 기능이 구현된다.

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

• 객체는 상태와 행동을 캡슐화 한 실행 단위.

  • 그렇다면 어떤 행동과 상태를 객체에 할당 해야 하는가?

• 어떤 객체도 섬이 아니다.

  • 객체가 필요하다면 그 이유는 객체가 어떠한 협력에 참여하고 있기 때문에

• 객체의 행동은 객체가 참여하고 있는 협력이 결정한다.

• Movie 객체를 예로 들어보자

• 자연스럽게 영화를 상영하는 장면을 상상 하겠지만, 실제로는 영화 예매를 위한 협력에 참여한다.

• 그 안에서 영화 요금을 계산하는 책임을 수행한다.

• 객체의 행동을 결정하는 것은 협력, 상태를 결정하는 것은 행동

• 결과적으로

  협력은 상태와 행동을 결정한다.

  • 즉 협력은 일종의 객체를 설계를 필요한 문맥을 제공한다.

02. 책임

책임이란 무엇인가

• 우선 협력이 갖춰졌다.

  • 다음은 협력에 필요한 행동을 수행할 수 있는 적절한 객체
  • 그 객체가 수행하는 행동이 바로 책임

• 책임:

  객체가 유지해야 하는 정보와 수행할 수 있는 행동

  • 하는 것(doing)
    • 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
    • 다른 객체의 행동을 시작시키는 것
    • 다른 객체의 활동을 제어하는 것
  • 아는 것(knowing)
    • 사적인 정보에 관해 아는 것
    • 관련된 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

CRC Card

• 책임 > 메시지
  • 책임은 객체가 수행할 수 있는 행동을 종합적으로 서술한다.
  • 한 책임은 다수의 메시지로 분할 되기도 한다.
• 객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 객체에 할당하는 것
• 객체 디자인에서 가장 기본이 되는 것 중의 하나(원칙은 아닐지라도)는 책임을 어디에 둘지를 결정하는 것이다. 나는 십년 이상 객체를 가지고 일했지만 처음 시작할 때는 여전히 적당한 위치를 찾지 못한다. 늘 이런 점이 나를 괴롭혔지만... "리펙토링", 마틴 파울러

책임 할당

• 책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것.
  • INFORMATION EXPERT 패턴
• 시스템이 사용자에게 제공하는 기능을 하나의 책임으로 바라보자
  • 이 책임을 수행할 때 나눌 수 있다면 더 작은 책임으로 나눈다.
• 영화 예매 시스템에서의 기능은 "예매하라"
  • "예매"를 위한 정보를 잘 아는 전문가는 Screening
  • 하지만, 영화 예매 가격은 모른다. 가격 전문가는 Movie
  • 이런 형태로 협력에 필요한 메시지를 찾고, 메시지에 적절한 객체를 선택하는 반복적인 과정.

책임 주도 설계

• 책임을 갖고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 설계 하는 것.

책임주도 설계의 과정

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

• 책임을 할당할 때 고려할 두 가지
  1. 메시지가 객체를 결정한다.
  2. 행동이 상태를 결정한다.

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

• 책임을 할당할 때, 필요한 메시지를 식별하고 메시지를 처리할 역할 혹은 객체를 선택했다.
• 메시지가 객체를 선택해야 하는 중요한 두가지 이유
  1. 객체가 최소한의 인터페이스를 가질 수 있게 된다.
     • 객체는 꼭 필요한 크기의 퍼블릭 인터페이스를 가질 수 있다.
  2. 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.
     • 인터페이스는 무엇을 하는지 표현해야 하지, 어떻게 하는지는 노출해서는 안 된다.
• 결과적으로 객체의 인터페이스는 추상적인 동시에 최소한 작은 크기를 유지할 수 있다.

행동이 상태를 결정한다.

• 객체의 존재 이유는 협력하기 위해서
  • 따라서 필요한 행동을 제공한다.
• 객체의 행동은 협력에 참여할 수 있는 유일한 방법
  • 객체의 협력을 결정하는 것은 상태가 아닌 행동이다.
  • 만약 상태에 초점을 맞춘다면 상태에 필요한 행동을 만들게 된다.
    • 이것은 구현을 노출시켜 캡슐화를 위반.
  • 이러한 상태 중심 설계는 Data-Driven Design 이라 한다.

03. 역할

역할과 협력

• 역할: 객체가 특정 협력 안에서 수행하는 책임의 집합
• 협력 안에서 책임을 수행할 주체를 찾을 때 처음은 역할을, 그 다음 역할에 맞는 객체를
• Q> 왜 역할이라는 개념을 활용해 설계 과정을 어렵게 만들까?

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

• 역할은 유연하고 재사용 가능한 협력을 얻게 한다.
• 만약 역할이라는 개념이 없다면?
  • 영화 도메인에서 할인 정책은 두 가지가 존재한다.
    • 그렇다면 두 정책에 따른 협력을 따로 만들어야한다
    • 이렇게 한다면 중복되는 코드가 많다.
• 이를 위해 책임에 초점을 맞추면, 모두 할인 요금 계산이라는 동일한 책임을 수행한다.
  • 메시지에 응답 가능한 대표자를 생각해 두 협력을 하나로 통일한다.
  • 이것이 바로 역할
  • 역할은 두 종류의 구체적인 객체를 포괄하는 추상화
• 이렇게 하면 협력이 더 유연해진다.

객체 대 역할

• Q> 만약 오직 한 종류의 객체만 협력에 참여하는 상황에서의 역할이라는 개념은 도움이 될까?
  • 단 한 종류의 객체만 협력에 참여한다면 간단하게 객체로 간주하면 된다.
  • 여러 종류의 객체가 참여한다면 역할로 부르면 된다.
• 어떤 것이 역할이고 어떤 것은 객체인지 설계 초반에는 확인하기 어렵다
  • 설계 초반에는 적절한 책임과 협력의 큰 그림을 그리는 것이 가장 중요하다
  • 따라서 처음엔 객체로 시작해서 반복하고, 필요하다면 역할로 분리해내는 것이 좋다.

역할과 추상화

• 역할은 공통의 책임을 바탕으로 객체의 종류를 숨긴다.
  • 역할은 객체의 추상화
• 협력의 단계에 역할을 사용하면 더욱 추상화된다.