3장: 역할, 책임, 협력

협력

객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없기 때문에 오직 메시지 전송을 통해서만 자신의 요청을 전달할 수 있으므로, 다른 객체에 메시지를 요청하는 것을 협력이라고 한다.
다른 객체에 메시지를 요청하는 대신 다른 객체의 내부 구현을 직접 조작하는 방법은 객체의 자율성을 훼손하고 수동적인 존재로 만들어버리므로 지양해야 한다.
애플리케이션 안에 어떤 객체가 존재하는 이유는 그 객체가 어떠한 협력에 참여하고 있기 때문이고, 협력에 필요한 적절한 행동을 보유하고 있기 때문이다.
객체가 행동하는 데 필요한 정보는 상태로 저장되며, 행동은 협력 안에서 객체가 처리할 메시지로 결정된다.
협력은 객체를 설계하는 데 필요한 일종의 문맥을 제공한다.

객체가 유지해야 하는 정보와 수행 할 수 있는 행동에 대해 개략적으로 서술한 문장
객체의 책임을 크게 ‘하는 것(doing)’과 ‘아는 것(knowing)’의 두 가지 범주로 나누어 세분화한다.
일반적으로 책임과 메시지의 크기는 다르다. 책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에 메시지보다 추상적이고 개념적으로도 더 크다.
단순한 책임이라고 생각했던 것도 막상 설계에 들어가면 여러 메시지로 분할하거나 여러 객체에서 협력해야 할 수 있다.
객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것이다.
CRC 카드
- Candidate Responsibility Collaborator의 약자이다.
- 역할을 식별하고, 책임을 할당하며, 협력을 명시적으로 표현하는 구체적이면서도 실용적인 설계 기법이다.
- 협력에 참여하는 하나의 후보(역할/객체/클래스 등)를 표현한다. 즉, 후보의 목적, 책임, 책임 수행 시 협력할 협력자들을 함께 작성한다.
협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해 객체지향적 설계가 이뤄진다. 이를 통해 최종적으로 얻는 결과물은 시스템을 구성하는 객체들의 인터페이스와 작업 목록이다.

객체가 협력에 적합한지를 결정하는 것 은 그 객체의 상태가 아니라 행동이다.
객체의 상태에 초점을 맞추는 것보다는 행동에 초점을 맞추고 이후에 상태를 결정해야 한다. 이렇게 설계하지 않으면 객체의 내부 구현이 객체의 퍼블릭 인터페이스에 노출되도록 만들기 때문에 캡슐화를 저해한다.

객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 의미한다.
역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있다.
- 예를 들어 가격 할인과 비율 할인이 필요한 경우 각각의 객체를 만들어 책임을 할당하는 것보다는 할인 요금 계산이라는 공통된 책임을 만들어 상황마다 바꿔 끼우도록 역할을 할당할 수 있다.
추상 클래스와 인터페이스는 동일한 책임을 수행하는 다양한 종류의 클래스들을 협력에 참여시킬 수 있는 확장 포인트를 제공하기 때문에 역할을 구현할 때 가장 일반적으로 사용된다.
적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주하고, 여러 종류라면 역할으로 간주해야 한다.
설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목표여야 하고, 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지는 않으므로 후보로 간주하고 설계해야 한다. 책임과 협력을 정제해가면서 협력이 유사한 구조를 보이는 경우 객체를 역할로 대체하는 것이 가장 좋은 방법이다.
역할이 중요한 이유는 동일한 협력을 수행하는 객체들을 추상화할 수 있기 때문이다. 이를 통해 복잡한 클래스 다이어그램을 추상화를 통해 비교적 간단하게 표현할 수 있다.

객체는 협력에 참여할 때 협력 안에서 하나의 역할로 보여진다. 그리고 객체가 참여하는 협력에 따라 다른 역할로 보여지며, 동일한 역할을 수행하는 객체들은 서로 대체 가능하다.

Last updated 3 months ago