03. 역할, 책임, 협력

3장은 영화 예매 시스템을 다시 바라보면서 객체지향 설계의 본질을 역할(Role), 책임(Responsibility), 협력(Collaboration)의 관점에서 설명한다.

클래스, 상속, 인터페이스보다도 먼저 고려해야 하는 설계의 출발점이 이 세 가지라는 점을 강조한다.

1. 협력 — 시스템이 동작하기 위한 객체들의 상호작용

객체는 혼자서는 일을 완수할 수 없으며, 메시지를 주고받으며 협력을 통해 기능을 완성한다.

• 영화 예매 과정은 여러 객체들이 역할에 따라 메시지를 주고받는 협력 시나리오로 이해된다
• 협력이 설계를 이끄는 출발점이며, 협력 안에서 객체들의 역할과 책임이 드러난다

객체 간 협력 흐름을 파악한 다음에야 클래스나 상속 여부가 결정된다는 점을 강조한다.

2. 책임 — 객체에게 부여되는 행위와 의무

책임은 객체가 수행해야 하는 행동과 정보의 조합이며 두 종류가 존재한다.

책임의 유형

객체가 무엇을 알고 있어야 하는가 (knowing)

객체가 무엇을 해야 하는가 (doing)

• 책임을 잘못 부여하면 캡슐화·응집도·결합도 문제가 발생한다
• 책임을 중심으로 객체를 설계하면 변경에 유연한 구조를 자연스럽게 얻게 된다

메시지가 객체를 결정한다 — 먼저 객체를 정하는 것이 아니라, 필요한 메시지를 정하면 그 메시지를 수행할 객체가 선택된다는 원칙도 소개된다.

3. 역할 — 유연하고 확장 가능한 설계를 위한 추상화

협력 속에서 객체가 수행하는 책임의 집합을 역할이라고 부른다.

• 여러 객체가 같은 역할을 수행할 수 있다
• 역할을 사용하면 협력이 구체 객체에 묶이지 않아 확장성과 변경 용이성이 증가한다

예) 할인 조건을 판단하는 역할

→ SequenceCondition, PeriodCondition은 서로 다른 객체지만 같은 역할을 수행한다.

따라서 협력은 “특정 객체”가 아니라 “역할을 수행할 객체”를 선택하는 형태가 된다.

4. 역할 · 책임 · 협력 기반 설계의 특징

이 관점으로 설계할 경우 다음 장점이 생긴다.

• 도메인 규칙과 코드 구조의 정렬
• 변경 가능성 증가 (할인 조건/정책 변경에 강함)
• 재사용성 향상 (서로 다른 객체가 동일 역할 수행 가능)

결론

3장이 주는 핵심 메시지는 다음 한 문장으로 요약된다.

좋은 객체지향 설계는 클래스보다 협력, 구조보다 책임, 구체 객체보다 역할이 먼저다.

따라서 객체지향 설계 절차는 다음 순서를 따른다.

1. 협력을 설계한다 (시스템이 수행해야 하는 기능 흐름 결정)
2. 협력 안에 필요한 책임을 찾는다
3. 책임을 수행할 적절한 역할을 정의한다
4. 마지막에야 그 역할을 수행할 객체/클래스가 결정된다