[객체지향의 사실과 오해] 04장 : 역할, 책임, 협력

협력

객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 서술한 문장
객체가 '무엇을 알고 있는가(knowing)'와 '무엇을 할 수 있는가(doing)'으로 구성됨
- 아는 것 (knowing) : 외부에 제공해줄 수 있는 정보
  - 개인적인 정보에 관해 아는 것
  - 관련된 객체에 대해 아는 것
  - 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
- 하는 것 (doing) : 외부에 제공해 줄 수 있는 서비스
  - 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
  - 다른 객체의 행동을 시작시키는 것
  - 다른 객체의 활동을 제어하고 조절하는 것
책임은 객체의 공용 인터페이스 (public interface)를 구성 ⇒ 캡슐화 (공용 인터페이스에 대해서는 5장에 자세히 나옴)
다른 객체로부터 요청이 전송됐을 경우에만 자신에게 주어진 책임 수행
- 메시지 전송 : 책임을 수행하도록 요청을 보내는 것
- 메시지 : 협력을 위해 한 객체가 다른 객체로 접근할 수 있는 유일한 방법

어떤 객체가 수행하는 책임의 집합
역할을 이용해 협력을 추상화했기 때문에
역할을 수행할 수 있는 어떤객체라도 협력에 참여할 수 있음 (동일한 메시지 수신 및 동일한 책임 수행 가능)
⇒ 설계의 단순성(simplicity) ↑, 협력의 유연성(flexibility) ↑, 재사용성(reusability) ↑
협력의 추상화
- 하나의 협력 안에 여러 종류의 객체가 참여 가능
- 협력의 개수를 줄이고 구체적인 객체를 추상적인 역할로 대체함으로써 협력의 양상 단순화 가능
대체 가능성
- 역할 = 협력의 추상화 ⇒ 여러 객체가 동일한 책임 수행 가능 ⇒ 행위 호환성 ⇒ 역할 대체 가능

오류 1 : 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다.
- 반박 : 데이터는 객체가 행위를 수행하는 데 필요한 재료일 뿐이고, 중요한 것은 객체의 행동 즉, 책임이다.
오류 2: 객체지향이 클래스와 클래스 간의 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다.
- 반박 : 클래스는 단지 시스템에 필요한 객체를 표현하고 생성하기 위해 프로그래밍 언어가 제공하는 구현 메커니즘일 뿐이고,
  중요한 것은 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지를 결정하는 것이다.

객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차 제시
협력에 필요한 책임들을 식별하고 적합한 객체에 책임을 할당하며 시스템을 구축하는 설계 방법
시스템의 책임을 객체의 책임으로 변환하고,
각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아
해당 협력자에게 책임을 할당하는 순차적인 방식으로 객체들의 협력 공동체 구축
객체지향 시스템을 설계하는 절차
1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임 파악
2. 시스템 책임을 더 작은 책임으로 분할
3. 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임 할당
4. 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할 탐색
5. 해당 객체 또는 역할에게 책임을 할당 (⇒ 두 객체가 협력하게 됨)

테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해나가는 방식
테스트 작성이 핵심이 아니고, 구체적인 코드를 작성해나가면서 역할•책임•협력이 적합한지를 피드백 받는 것이 목적
테스트라는 안전장치를 통해 좀 더 빠르고 견고한 방법으로 책임-주도 설계의 목적지에 도달할 수 있게 해줌
객체가 어떤 메시지를 수신할 때 어떤 객체와 협력하고 어떤 결과를 반환할 것인지에 대한 기대를 코드의 형태로 작성하는 것
테스트-주도 개발의 흐름
1. 실패하는 테스트 작성
2. 테스트를 통과하는 가장 간단한 코드 작성 (중복이 있어도 무방)
3. 리팩터링을 통해 중복 제거
테스트-주도 개발을 통해 응집도가 높고 결합도가 낮은 클래스로 구성된, '깔끔한 코드'를 얻을 수 있음