1. 협력
협력은 요청으로부터 시작되며 다수의 요청과 응답으로 구성된다
2. 책임
책임의 분류
1️⃣ 객체가 무엇을 알고 있는가 -> 아는 것(knowing)
- 개인적인 정보에 관해 아는 것
- 관련된 객체에 관해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
2️⃣ 객체가 무엇을 할 수 있는가 -> 하는 것(doing)
- 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작시키는 것
- 다른 객체의 활동을 제어하고 조절하는 것
📍 책임과 메시지
메시지 전송(message-send)
- 객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것
- 협력 안에서 객체는 다른 객체로부터 요청이 전송됐을 경우에만 자신에게 주어진 책임을 수행한다
- 한 객체가 다른 객체에게 전송한 요청은, 그 요청을 수신한 객체의 책임이 수행되게 한다
좋은 객체지향 설계
- 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고, 어떤 객체로부터 메시지를 수신할 것인지를 먼저 결정
- 어떤 클래스나 메서드를 만들 것인지는 책임과 메시지에 대한 윤곽을 잡은 후 시작해도 됨
3. 역할
책임의 집합
- 어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시
예) 왕을 판사로, 모자장수를 증인으로 굳이 역할을 부여하는 이유
- 역할이 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이기 때문
- 나중에 왕 대신 여왕, 모자 장수 대신 앨리스 객체가 역할을 맡아도 됨
역할
- 협력 내에서 다른 객체로 대체할 수 있음을 나타내는 일종의 표식
- 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정됨
예) 판사 역할을 수행할 수 있으려면 판사가 수신할 수 있는 메시지(재판하라)를 동일하게 이해할 수 있어야 함
- 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있게 해준다
- 다양한 객체들이 협력에 참여할 수 있어서 재사용성이 높아진다
4. 객체지향 설계 기법
역할, 책임, 협력의 관점에서 애플리케이션을 설계하는 3가지 기법
1️⃣ 책임 주도 설계(RDD, Responsibility-Driven Design)
2️⃣ 디자인 패턴
3️⃣ 테스트 주도 개발(TDD, Test-Driven Development)
📍 책임 주도 설계
- 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차 제시
- 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션 설계
- 객체가 스스로 처리할 수 없는 정보나 기능이 필요한 경우, 적절한 객체를 찾아 필요한 작업을 요청 → 협력 관계가 만들어짐
- 책임을 여러 종류의 객체가 수행할 수 있다면 협력자는 객체가 아니라 추상적인 역할로 대체됨
- 역할, 책임, 협력에 초점(나머지는 도구일 뿐)
RDD 절차
1️⃣ 시스템이 유저에게 제공해야 하는 기능인 시스템 책임 파악
2️⃣ 시스템 책임을 더 작은 책임으로 분할
3️⃣ 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당
4️⃣ 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우, 이를 책임질 적절한 객체 또는 역할을 찾는다
5️⃣ 해당 객체 또는 역할에게 책임을 할당하여 두 객체가 협력하게 한다
📍 디자인 패턴
- 책임 주도 설계의 결과를 표현
- 반복적으로 발생하는 문제와 해결책을 함께 정의
패턴이란?
- 모범이 되는 설계
- 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험
📍 테스트 주도 개발
- 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후, 리팩토링을 통해 중복 제거 ⇒ 깔끔한 코드 얻을 수 있음