[오브젝트: 코드로 이해하는 객체지향 설계/조영호]3장: 역할, 책임, 협력

03 역할, 책임, 협력

객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다.

01 협력

영화 예매 시스템 돌아보기

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

협력

• 객체지향 시스템: 자율적인 객체들의 공동체
• 객체: 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협력하는 사회적인 존재
• 협력: 객체를 구현할 수 있는 유일한 방법, 어떤 객체가 다른 객체에게 무언가를 요청하는 것 (또는 위임)
• 메시지 전송(message sending): 객체들이 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단
• 메서드: 메시지를 수신한 객체가 응답을 위해 실행하는 프로세스

외부의 객체는 오직 메시지만 전송할 수 있다.
메시지를 어떻게 처리할지는 메시지를 수신한 객체가 스스로 결정한다.

요금을 계산하는 작업을 Screening이 수행한다면 Movie의 인스턴스 변수인 fee와 discountPolicy에 직접 접근해야만 한다

• Screening은 Movie의 내부 구현에 결합(의존/간섭)
• Movie의 자율성이 훼손
• Movie는 수동적인 존재로 전락

Movie가 자율적인 존재가 되기 위해서는 자신이 알고 있는 정보를 이용해 직접 요금을 계산해야 한다
객체를 자율적으로 만드는 가장 기본적인 방법 -> 내부 구현을 캡슐화

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

public class Movie {
    private Money fee;
    private DiscountPolicy discountPolicy;

    public Money calculateMovieFee(Screening screening) {
        return fee.minus(discountPolicy.calculateDiscountAmount(screening));
    }
}

• 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다
  • Movie라는 객체가 play라는 행동이 아닌 calculateMovieFee라는 행동만 있는 이유도 영화를 예매하기 위한 협력에 참여하고 있고, 요금을 계산하는 책임을 지고 있기 때문이다.
• 객체가 참여하는 협력이 객체를 구성하는 행동과 상태 모두를 결정한다.
  • 상태: 객체가 행동하는 데 필요한 정보에 의해 결정
  • 행동: 협력 안에서 객체가 처리할 메시지로 결정
• 따라서 협력은 객체를 설계하는 데 필요한 일종의 문맥(context) 을 제공한다.

02 책임

책임이란 무엇인가

책임

• 협력에 참여하기 위해 객체가 수행하는 행동
• 객체에 의해 정의되는 응집도 있는 행위의 집합
• 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장

객체의 책임

• 객체가 ‘무엇을 알고 있는가’
• 객체가 ‘무엇을 할 수 있는가’

크레이그 라만(Craig Larman)의 책임

‘하는 것(doing)’

• 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
• 다른 객체들의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

‘아는 것(knowing)’

• 사적인 정보에 관해 하는 것
• 관련된 객체에 대해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

영화 예매 시스템에서의 책임

Screening: 영화를 예매하는 것

• 자신이 상영할 영화를 알고 있어야 한다.
• 영화를 예매 할 수 있어야 한다

Movie: 요금을 계산하는 것

• 가격과 적용된 할인 정책에 대해 알고 있어야 한다
• 예매 가격을 계산한다.

적절한 협력이 적절한 책임을 제공하고
적절한 책임을 적절한 객체에게 전달해야 한다.

책임 할당

책임을 수행할 정보 전문가를 찾는다.

책임 주도 설계

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

책임을 할당할 때 고려해야 하는 두 가지 요소

• 메시지가 객체를 결정한다
• 행동이 상태를 결정한다

메시지가 객체를 결정한다

1. 객체가 최소한의 인터페이스를 가질 수 있게 된다.
   • 필요한 크기의 퍼블릭 인터페이스를 가질 수 있다.
2. 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.
   • 객체의 인터페이스는 어떻게(how)가 아닌 무엇(what)을 하는지 표현

행동이 상태를 결정한다

• 객체의 본질은 상태가 아니라 행동(책임)
• 행동이 상태를 결정한다, 상태가 행동을 결정하는 게 아니다
  • 상태부터 정하면 내부 구현이 드러나 캡슐화가 깨짐
  • 객체는 협력 속에서 어떤 행동을 해야 하는지로 설계해야 한다
• 협력 → 행동(책임) → 상태 순으로 생각하라

🔺 1. p.85 객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법이다. (객체는 상태와 행동만 있으니까)
객체의 행동은 객체가 협력에 참여할 수 있는 유일한 직접적인 방법이다.
객체는 상태와 행동으로 구성되지만, 협력에 직접 참여하는 것은 행동뿐이다.
다만 객체는 상태, 이벤트, 설정, 조합 등을 통해 협력의 방식이나 결과에 간접적으로 영향을 미칠 수 있다
2. 데이터-주도 설계(Data-Driven Design) VS 도메인 주도 설계 (Domain-Driven, DDD)

• DDD가 Data-Driven Design의 한계를 극복하려고 등장한 개념

03 역할

역할과 협력

역할: 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합
(실제로 협력을 모델링할 때는 역할에게 책임을 할당한다고 생각하는게 좋다)

예매하라는 메시지를 처리하기 위해 수행되는 단계

• 1단계: 영화를 예매할 수 있는 적절한 역할이 무엇인가를 찾는 것
• 2단계: 역할을 수행할 객체를 선택

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

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

역할이라는 개념을 고려하지 않고 객체에게 책임을 할당한다면

• 코드가 중복

할인 요금 계산이라는 동일한 책임을 수행 -> 객체라는 존재를 지우고 할인 요금을 계산하는 대표 즉 역할 역할: 두 종류의 구체적인 객체를 포괄하는 추상화 -> DiscountPolicy

구분	추상 클래스 (Abstract Class)	인터페이스 (Interface)
공통점	둘 다 협력의 관점에서 역할(Role)을 정의할 수 있는 구현 방법
차이점	책임의 일부를 구현할 수 있음	구현 없이 책임의 집합만 나열

객체 대 역할

역할: 객체가 참여할 수 있는 일종의 슬롯이다.
여러 종류의 객체들이 참여할 수 있다면 역할이지만 협력에 적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주한다.
-- 레베카 워프스브록 --

역할과 추상화

추상화의 장점

• 세부 사항에 억눌리지 않고도 상위 수준의 정책을 쉽고 간단하게 표현할 수 있다.
  • 협력이라는 관점에서는 세부적인 사항을 무시하고 추상화에 집중하는 것이 유용하다.
• 설계를 유연하게 만들 수 있다.
  • 협력 안에서 역할이라는 추상화를 이용하면 기존 코드를 수정하지 않고도 새로운 행동을 추가할 수 있다.

배우와 배역

연극 안에서 배역을 연기하는 배우 -> 협력안에서 역할을 수행하는 객체

• 역할은 특정한 객체의 종류를 캡슐화하기 때문에 동일한 역할을 수행하고 계약을 준수하는 대체 가능한 객체들은 다형적이다.