3장 : 역할, 책임, 협력

2장 복습
  • 클래스, 추상 클래스, 인터페이스를 조합해서 객체지향 프로그램을 구조화하는 방법

  • 상속을 이용해 다형성을 구현하는 기법

    • 지연 바인딩 (런타임에 결정)

  • 상속보다는 합성

  • 유연한 객체지향 프로그램 ⇒ 컴파일 시간 의존성과 실행 시간 의존성이 달라야 한다

1. 협력

  • 협력 : 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용

  • 책임 : 객체가 협력에 참여하기 위해 수행하는 로직

  • 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 수행

✔️ 협력

  • 객체 지향 시스템은 자율적인 객체들의 공동체

  • 메시지 전송(message sending) : 객체 사이의 협력을 위해 사용할 수 있는 유일한 수단

  • 협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것

  • 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다. 이 때 메시지 처리 방법은 스스로 선택한다.

  • 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화하는 것이다.

⇒ 객체들 사이의 협력을 구성하는 일련의 요청과 응답 흐름을 통해 애플리케이션의 기능이 구현된다.

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

  • 객체상태와 행동을 함께 캡슐화하는 실행 단위다.

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

  • 객체의 상태를 결정하는 것은 행동이다.

⇒ 상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고 행동은 협력 안에서 객체가 처리할 메시지로 결정된다. 따라서 협력은 객체를 설계하는 데 필요한 일중의 문맥(context)을 제공한다.

협력행동상태

2. 책임

✔️ 책임이란 무엇인가

  • 책임 : 협력에 참여하기 위해 객체가 수행하는 행동

  • 객체의 핵임은 객체가 ‘무엇을 알고 있는가 ?’와 ‘무엇을 할 수 있는가’로 구성된다.

    • 하는 것

      • 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것

      • 다른 객체의 행동을 시작시키는 것

      • 다른 객체의 활동을 제어하고 조절하는 것

    • 아는 것

      • 사적인 정보에 관해 아는 것

      • 관련된 객체에 관해 아는 것

      • 자신이 유도하거나 계산할 수 있는 것에 돤해 아는 것

  • 협력 안에서 객체에게 할당한 책임이 외부의 인터페이스와 내부의 속성을 결정한다.

  • 책임이 메시지보다 추상적이고 개념적으로 더 크다.

⇒ 객체지향 설계에서 가장 중요한 것은 책임이.

✔️ 책임 할당

  • 메지시 선택

    • 객체가 책임을 수행하게 하는 유일한 방법은 메시지를 전송하는 것이므로 책임을 할당하는 것은 메시지의 이름을 결정하는 것과 같다.

    • ex. 예매하라

  • 메시지 처리할 객체 선택

    • 해당 정보의 소유자를 가장 잘 알고 있는 전문가에게 할당

✔️ 책임 주도 설계

  • 책임 주도 설계 : 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계

  • 협력은 객체 설계를 위한 구체적 문맥 제공

  • 객체의 구현이 아닌 책임에 집중할 수 있게 한다. 이는 유연하고 견고한 객체지향 시스템을 이끌어 낸다.

⇒ 책임을 할당할 때 메시지가 객체를 결정하고, 행동이 상태를 결정한다.

✔️ 메시지가 객체를 결정할 경우

  1. 객체가 최소한의 인터페이스를 가질 수 있다.

  2. 객체는 충분히 추상적인 인터페이스를 가질 수 있다.

✔️ 행동이 상태를 결정한다

  • 객체의 내부 구현에 초점을 맞춘 설계 방법을 데이터-주도-설계(Data-Driven-Design)이라고 부른다.

⇒ 협력 → 책임(행동) → 상태

3. 역할

✔️ 역할과 협력

  • 역할 : 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합

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

  • 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있다.

  • 역할은 다른 것으로 교체할 수 있는 책임의 집합니다.

  • 할인 요금 예시에서 역할은 두 종류의 구체적인 객체를 포괄하는 추상화다.

⇒ 요점을 동일한 책임을 수행하는 역할을 기반으로 두 개의 협력을 하나로 통합할 수 있다. 따라서 역할을 이용하면 불필요한 중복 코드를 제거할 수 있다.

✔️ 객체 대 역할

  • 협력에 적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 만주한다. 만약 여러 종류의 객체들이 참여할 수 있다면 역할이라고 부른다.

    • 트리그비 린스타우는 역할을 가리켜 실행되는 동안 협력 안에서 각자의 위치를 가지는 객체들에 대한 별칭이라고 정의하기도 한다.

⇒ 중요한 것은 책임이다. 역할의 가장 큰 장점은 설계의 구성 요소를 추상화할 수 있다는 것이다.

✔️ 역할과 추상화

  • 추상화 설계 장점

    1. 정책을 상위 수준에서 단순화할 수 있다.

    2. 설계가 유연해진다.

  • 역할은 공통 책임을 바탕으로 객체의 종류를 숨기기 때문에 역할을 객체의 추상화로 볼 수 있다.

  • 객체에게 중요한 것은 핵동이고, 역할이 중요한 이유는 동일한 협력을 수행하는데 객체들을 추상화할 수 있기 때문이다.

  • more

    프레임워크나 디자인 패턴과 같이 재사용 가능한 코드나 설계 아이디어를 구성하는 핵심적인 요소가 바로 역할이다.

✔️ 배우와 배역

  • 배역 - 역할

  • 배우 - 객체

Last updated