TIL

03 역할, 책임, 협력

• 객체지향 패러다임 관점에서 핵심
  • 역할
  • 책임
  • 협력

01 협력

• 객체지향 원칙을 따르는 애플리케이션의 제어 흐름은 다양한 객체들 사이에 균형 있게 분배된다.
• 객체들이 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다.

협력

• 두 객체 사이의 협력은 메시지 전송을 통해 이루어 진다.
• 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다.
  • 객체는 메시지를 처리할 방법을 스스로 선택한다.
• 객체는 자신의 상태를 직접 관리하고 스스로 결정에 따라 행동한다.
• 객체를 자율적으로 만드는 가장 기본적인 방법은 캡슐화이다.

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

• 객체란 상태와 행동을 함께 캡슐화 해야 하는 실행 단위
  • 객체가 가지는 상태, 행동은 어떻게 결정?

• 애플리케이션에 객체가 필요하다면 그 이유는 단 하나

  → 객체가 협력에 참여하고 있기 때문

• 즉 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력
  • 협력이 바뀌면 행동 역시 변화
• 객체의 상태를 결정하는 것은 행동
  • 행동을 수행하는 데 필요한 정보이기 때문
• 협력은 객체를 설계하는 데 필요한 일종의 문맥(context)를 제공한다.

02 책임

책임이란 무엇인가

• 협력에 참여하기 위해 객체가 수행하는 행동을 책임이라 부른다.
• 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합
  • 객체가 ‘무엇을 알고 있는가’
    • 사적인 정보에 관해 아는 것
    • 관련된 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
  • 객체가 ‘무엇을 할 수 있는가’
    • 객체를 생성하거나 계산을 수행하는 등
    • 다른 객체의 행동을 시작시키는 것
    • 다른 객체의 활동을 제어하고 조절하는 것
• 협력 안에서 객체에게 할당한 책임이 외부 인터페이스와 내부 속성을 결정

책임 할당

• 책임 할당을 위한 INFORMATION EXPERT (정보 전문가) 패턴
  • 자율적인 객체를 만드는 기본적인 방법은 책임 수행에 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것
  • ex) 가격 계산 행동을 수행하기 위해선 가격 정보를 알고 있는 객체에게 맡기는 것이 자연스럽다
• 객체에 책임을 할당하기 위해선 협력이라는 문맥을 정의해야 한다.
• 협력 설계의 출발점은 시스템이 제공해야 하는 기능을 시스템이 담당할 하나의 책임으로 보는 것
  • 필요한 더 작은 책임을 찾아내고 이를 객체들에게 할당, 반복
• 어떤 경우에는 응집도, 결합도 관점에서 정보 전문가가 아닌 객체에게 책임을 할당해야 하는 경우도 있다.
  • 하지만 기본 전략은 정보 전문가를 찾는 것

책임 주도 설계

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

메시지가 객체를 결정한다

• 책임을 할당하는 데 필요한 메시지를 먼저 식별하고 메시지를 처리할 객체는 나중에 선택해야 한다.
  • 메시지가 객체를 선택
• 메시지가 객체를 선택해야 하는 2가지 이유
  • 객체가 최소한의 인터페이스를 가지게 된다.
    • 메시지가 식별될 때까지 객체의 퍼블릭 인터페이스는 추가되지 않는다.
  • 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.
    • 객체 인터페이스는 무엇을 하는지만을 표현
    • 어떻게는 노출되면 안된다.
    • 메시지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추게 된다.

행동이 상태를 결정한다

• 객체를 객체답게 만드는 것은 객체 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다.
• OOP에 갓 입문한 사람이 가장 쉽게 빠지는 실수는 행동이 아니라 상태에 초점을 맞추는 것
  • 상태를 결정하고 상태에 필요한 행동을 결정
  • 상태에 집중하면 캡슐화를 저해한다.
  • 내부 구현을 변경했을 때 퍼블릭 인터페이스가 변경될 수도 있다. → 변경의 전파
  • 데이터-주도 설계(Data-Driven Design)
• 협력이 객체의 행동을 결정하고 행동이 상태를 결정한다.
  • 행동이 바로 객체의 책임

03 역할

역할과 협력

• 객체가 특정 협력 안에서 수행하는 책임의 집합을 역할이라 부른다.
• 협력을 모델링할 때 특정 객체가 아니라 역할에게 책임을 할당한다고 생각하는 것이 좋다.
• ex) 영화 예매 협력의 경우
  • ‘예매하라’라는 메시지를 처리할 객체로 Screening을 선택
  • 위 문장은 실제로 두 개의 독립적인 단계가 합쳐진 것
    • 영화를 예매할 있는 역할 탐색
    • 역할을 수행할 객체로 Screening 인스턴스 선택
  • 역할에 이름은 없지만 실제로는 익명의 역할을 찾고 역할을 수행할 객체를 선택하면서 설계가 진행된 것

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

• 역할이 중요한 이유는 유연하고 재사용 가능한 협력을 얻을 수 있기 때문
• 역할은 다른 것으로 교체할 수 있는 책임의 집합이다.
• 역할을 먼저 생각함으로써 구체적인 객체를 포괄하는 추상화를 적용할 수 있고 이는 interface로 구현할 수 있다.
  • ex) DiscountPolicy와 PercentDiscountPolicy, AmountDiscountPolicy
• 역할을 이용하면 여러 협력을 하나로 통합하고 코드 중복을 줄일 수 있으며 유연한 설계를 할 수 있다.
• 역할과 추상화를 이용한 설계에는 다양한 기술적 메커니즘이 동작한다.
  • 인터페이스 업캐스팅, 다형성, 늦은 바인딩, 상속, 컴파일 시간 의존성, 실행 시간 의존성 등

객체 대 역할

• 역할은 객체가 참여할 수 있는 일종의 슬롯으로 유연하고 재사용 가능한 설계를 제공한다.
• 하지만 오직 하나의 객체만 협력에 참여할 때 역할이라는 개념이 유용할까?
  • 더 복잡해지기만 할 수도 있다.
• 결론부터 말하면 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주한다.

협력 → 역할 → 객체 → 클래스

• 대부분 역할과 객체의 경계가 뚜력하지 않을 수 있다.
  • 특히 설계 초반에는 결정하기 힘들다.
• 설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요
  • 역할과 객체를 구분하는 것은 그렇게 중요하지 않을 수도 있다.
  • 반복적으로 책임과 협력을 정제해가며 필요한 순간 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다.
• 다양한 객체들이 협력에 참여한다는 것이 확실하다면 역할로 시작하고 애매하다면 객체로 시작하라

역할과 추상화

• 추상화를 이용한 설계의 장점
  • 중요한 정책을 상위 수준에서 단순화
    • ex) 비율 할인을 하든, 금액 할인을 하든, 할인을 하지 않은 ‘할인 정책을 적용한다’로 추상화하면 세부 사항을 숨기고 핵심 개념을 강조 가능
  • 설계가 유연해짐
    • OCP
• 역할을 객체의 추상화로 볼 수 있다.
  • 공통 책임을 바탕으로 객체의 종류를 숨기기에

배우와 배역

• ‘배역’은 ‘역할’이며 ‘배우’는 ‘객체’다
• 동일한 배역을 여러 배우가 연기할 수 있다.
  • 역할의 책임은 여러 객체가 수행할 수 있다.
• 배우가 여러 연극에 참여하여 여러 배역을 연기할 수 있는 것처럼 객체 역시 여러 협력에 참여하며 다양한 역할을 수행한다.