객체지향 패러다임 관점에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration) !
객체지향의 본질은 협력하는 객체들의 공동체를 창조 하는 것 !
협력을 구성하기 위해 적절한 객체를 찾고, 적절한 책임을 할당 하는 과정이 핵심이다.
협력
영화 예매 시스템 돌아보기
객체지향 원칙을 따르는 어플리케이션의 제어 흐름은
특정 한 객체에 의해 통제되지 않고 다양한 객체들 사이에 균형 있게 분배되는 것이 일반적이다.
객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력 이라고 한다.
객체가 협력에 참여하기 위해 수행하는 로직은 책임,
객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할 을 구성한다.
협력
두 객체 사이 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다.
메시지 전송 은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다.
협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것.
한 객체는 어떤 것이 필요할 때 다른 객체에게 전적으로 위임하거나 서로 협력한다.
즉, 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다.
객체 사이의 협력을 설계할 때는 객체를 서로 분리된 인스턴스가 아닌 협력하는 파트너로 인식 !
(Wirfs-Brock03)
메시지를 수신한 객체는 메소드를 실행해 요청에 응답한다.
객체는 메시지를 처리할 방법을 스스로 선택한다는 것이 중요 !
영화 예매 요금을 계산하기 위한 Screening 과 Movie 의 협력을 생각해보자.
Screening 은 Movie 에 calculateMovieFee 메시지를 전송함으로써
예매자 한 명의 요금 계산을 요청한다.
Movie 에게 처리를 위임하는 이유는 요금 계산에 필요한 기본 요금과 할인 정책을
가장 잘 알고 있는 객체가 Movie 이기 때문이다.
자율적인 객체로 만들기 위해서는 필요한 정보와 정보에 기반한 행동을
같은 객체 안에 모아두어야 한다.
Movie 가 자율적인 존재가 되기 위해서는 자신이 알고있는 정보를 이용해
직접 요금을 계산해야 한다. 그래서 Movie 에게 요금 계산을 위임 !
결과적으로 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화 하는 것 !
Movie 가 자신의 정보를 바탕으로 요금을 직접 계산하면 Screening 과 Movie 사이
결합도를 느슨하게 유지 할 수 있다.
협력이 설계를 위한 문맥을 결정한다
객체가 가질 수 있는 상태와 행동을 어떤 기준으로 결정해야 할까?
어플리케이션 안에 어떤 객체가 필요하다면 그 이유는 단 하나다.
그 객체가 어떤 협력에 참여하고 있기 때문 !
그리고 객체가 협력에 참여할 수 있는 이유는 협력에 필요한 적절한 행동을 보유하고 있기 때문 !
→ 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력
영화라는 단어를 들으면 극장에서 상영되는 장면이 상상되고,
자연스럽게 play 하는 행동을 수행할 것이라고 생각할 수 있다.
하지만 영화 예매 시스템 안의 Movie 에는 영화 상영과 관련된 어떤 코드도 없다.
요금 계산과 관련된 행동만 존재한다.
이것은 Movie 가 영화를 예매하기 위한 협력에 참여하고 있고,
그 안에서 요금을 계산하는 책임을 지고 있기 때문 !
객체의 행동을 결정하는 것은 협력이고, 객체의 상태를 결정하는 것은 행동이다.
객체는 자율적인 존재이기 때문에 객체가 수행하는 행동에 필요한 상태도 함께 가지고 있어야 함 !
상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고
행동은 협력 안에서 객체가 처리할 메시지로 결정된다.
→ 객체가 참여하는 협력이 객체를 구성하는 행동과 상태 모두를 결정 !
따라서 협력은 객체를 설계하는 데 필요한 일종의 문맥(context) 을 제공 !
책임
책임이란 무엇인가
객체를 설계하기 위해 필요한 문맥인 협력이 갖춰졌다면 이제 협력에 필요한 행동을 수행할 수 있는
적절한 객체를 찾아야 한다.
이때 협력에 참여하기 위해 객체가 수행하는 행동을 책임 이라고 부름.
객체의 책임은 객체가 ‘무엇을 알고 있는가’ 와 ‘무엇을 할 수 있는가’ 로 구성된다.
하는 것
- 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작시키는 것
- 다른 객체의 활동을 제어하고 조절하는 것
아는 것
- 사적인 정보에 관해 아는 것
- 관련된 객체에 관해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
Screening 은 영화를 예매할 수 있어야 한다. → 하는 것과 관련된 책임
Screening 은 자신이 상영할 영화를 알고 있어야 한다. → 아는 것과 관련된 책임
Movie 는 예매 가격을 계산할 책임을 진다. → 하는 것과 관련된 책임
Movie 는 가격과 어떤 할인 정책이 적용됐는지 알고 있어야 한다. → 아는 것과 관련된 책임
책임은 객체가 수행할 수 있는 행동을 종합적, 간략하게 서술.
메시지보다 추상적이고 개념적으로도 더 크다.
객체는 자신이 맡은 책임을 수행하는 데 필요한 정보를 알고 있을 책임이 있다.
또 자신이 할 수 없는 작업을 도와줄 객체를 알고 있을 책임이 있다.
책임은 객체지향 설계의 핵심 !
크레이그 라만은
“객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것”
이라고 말했다.
협력이 중요한 이유는 객체에게 할당할 책임을 결정할 수 있는 문맥을 제공하기 때문이다.
책임 할당
자율적인 객체를 만드는 가장 기본 방법은 책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는
전문가에게 그 책임을 할당하는 것 → INFORMATION EXPERT 패턴 이라고 부름.
객체에게 책임을 할당하기 위해서는 협력이라는 문맥을 정의해야 한다.
시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 보고,
시스템의 책임을 완료하는 데 필요한 더 작은 책임을 찾아내어
이를 객체들에게 할당하는 반복적인 과정을 통해 모양을 갖춰간다.
객체지향 설계는 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해
이뤄진다. 그리고 이런 메시지가 메시지를 수신할 객체의 책임을 결정하며
객체의 퍼블릭 인터페이스를 구성한다 !
책임 주도 설계
책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법을
책임 주도 설계 (Responsibility-Driven Design, RDD) 라고 부른다.
책임 주도 설계 방법의 과정을 정리하면,
- 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임 파악
- 시스템 책임을 더 작은 책임으로 분할
- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임 할당
- 객체가 책임을 수행하는 도중, 다른 객체 도움이 필요한 경우
이를 책임질 적절한 객체 또는 역할을 찾음 - 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력
책임을 할당할 때 고려해야 하는 두 가지 요소
- 메시지가 객체를 결정
- 행동이 상태를 결정
메시지가 객체를 결정한다
객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택 !
메시지가 객체를 선택하게 해야 하는 두 가지 이유가 있다.
- 객체가 최소한의 인터페이스(minimal interface) 를 가질 수 있게 된다.
- 객체는 충분히 추상적인 인터페이스(abstract interface) 를 가질 수 있게 된다.
행동이 상태를 결정한다
객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법.
객체가 협력에 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.
행동이 아닌 상태에 초점을 맞추게 되면 객체의 내부 구현이
퍼블릭 인터페이스에 노출되도록 만들기 때문에 캡슐화를 저해한다.
이와 같이 객체 내부 구현에 초점을 맞춘 설계 방법을 Data-Driven Design 이라고 부르기도 했다.
개별 객체의 상태와 행동이 아닌 시스템의 기능을 구현하기 위한 협력에 초점을 맞춰야만
응집도가 높고 결합도가 낮은 객체들을 창조할 수 있다.
상태는 단지 객체가 행동을 정상적으로 수행하기 위해 필요한 재료 !
역할
역할과 협력
객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할 이라고 부른다.
실제로 협력을 모델링할 때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하자.
유연하고 재사용 가능한 협력
역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문 !
예를 들어 Movie 가 가격을 계산하기 위해 할인 요금이 필요한 경우를 생각해보자.
“할인 요금을 계산하라” 는 메시지를 전송해서 외부 객체에게 도움을 요청할 때,
금액 할인 정책과 비율 할인 정책이라는 두 종류 할인 정책이 존재하기 때문에
AmountDiscountPolicy 인스턴스와 PercentDiscountPolicy 인스턴스라는 두 객체가
메시지에 응답할 수 있어야 한다.
그렇다면 두 객체가 참여하는 협력을 개별적으로 만들어야 하는가?
하지만 이렇게 두 협력을 구현하면 대부분의 코드가 중복된다.
문제를 해결하기 위해서는 객체가 아닌 책임에 초점을 맞추자.
두 객체 모두 할인 요금 계산이라는 동일한 책임을 수행한다.
따라서 객체라는 존재를 지우고 “할인 요금을 계산하라” 는 메시지에 응답할 수 있는
대표자이자 바꿔 끼울 수 있는 일종의 슬롯으로 생각하자. 이 슬롯이 바로 역할 이다.
역할은 다른 것으로 교체할 수 있는 책임의 집합이다. (Wirfs-Brock03)
여기서 역할은 두 객체를 포괄하는 추상화 이다.
동일한 책임을 수행하는 역할을 기반으로 두 개의 협력을 하나로 통합할 수 있다.
따라서 역할을 이용하면 불필요한 중복 코드를 제거할 수 있고,
협력이 더 유연해진다.
이제 새로운 할인 정책을 추가하기 위해 새로운 협력을 추가할 필요가 없어졌다 !
역할을 구현하는 가장 일반적인 방법은 추상 클래스와 인터페이스를 사용하는 것.
객체 대 역할
역할은 객체가 참여할 수 있는 일종의 슬롯.
하지만 오직 한 종류의 객체만 협력에 참여하는 상황에서는
역할이라는 개념을 생략하고 직접 객체를 이용해 협력을 설계하는 것이 더 좋지 않을까?
Wirfs-Brock 의 말을 인용하면, 협력에 참여하는 후보가 여러 종류의 객체에 의해
수행될 필요가 있다면 그 후보는 역할이 되지만, 단지 한 종류의 객체만이 협력에 참여할 필요가 있다면
후보는 객체가 된다.
- 협력 → 역할 → 객체 → 클래스
중요한 것은 협력을 구체적인 객체가 아닌 추상적인 역할의 관점에서 설계하면
협력이 유연하고 재사용 가능해진다는 것 !
역할의 가장 큰 장점은 설계의 구성 요소를 추상화할 수 있다는 것이다.
역할과 추상화
추상화를 이용한 설계가 가지는 두 가지 장점이 있다.
- 중요한 정책을 상위 수준에서 단순화할 수 있다
- 설계가 좀 더 유연해진다
객체에게 중요한 것은 행동이다.
역할이 중요한 이유는 동일한 협력을 수행하는 객체들을 추상화할 수 있기 때문 !
협력 안에서 동일한 책임을 수행하는 객체들은 동일한 역할을 수행하기 때문에
서로 대체 가능하다.
배우와 배역
연극의 배역과 배우 간의 관계에 다음과 같은 특성이 존재한다.
- 배역은 연극 배우가 특정 연극에서 연기하는 역할
- 배역은 연극이 상영되는 동안에만 존재하는 일시적 개념
- 연극이 끝나면 연극 배우는 배역이라는 역할을 벗어 버리고 원래의 연극 배우로 돌아옴
배우는 동일한 배역을 여러 배우들이 연기할 수 있다.
- 서로 다른 배우들이 동일한 배역을 연기할 수 있음
- 하나의 배우가 다양한 연극 안에서 서로 다른 배역을 연기할 수 있음
연극 안에서 배역을 연기하는 배우는 협력 안에서 역할 을 수행하는 객체와 비슷하다.
역할은 객체의 페르소나다.
배우가 여러 연극에 참여하면서 여러 배역을 연기하는 것처럼
객체도 여러 협력에 참여하면서 다양한 역할을 가질 수 있다.
동일한 객체라고 하더라도 협력에 참여할 때 하나의 역할로 보여진다.
다른 협력에 참여할 때는 다른 역할로 보여진다.
역할은 특정한 객체의 종류를 캡슐화하기 때문에 동일한 역할을 수행하고,
협력의 관점에서 동일한 역할을 수행하는 객체들은 서로 대체 가능하다.
정리
- 자율적인 객체는 도움이 필요한 경우 적절한 객체에게 메시지를 전송해 협력 요청.
- 협력이 존재하기 때문에 객체가 존재한다.
- 협력이 행동을 결정하고, 행동이 상태를 결정한다. (그 행동이 바로 객체의 책임이 된다)
- 객체에게 할당한 책임이 외부 인터페이스와 내부 속성을 결정한다.
- 협력이 책임을 이끌어내고 책임이 협력에 참여할 객체를 결정한다.
- 협력을 구체적 객체가 아닌 추상적인 역할 관점에서 설계하자.