3장 - 역할, 책임, 협력
역할, 책임, 협력 ( 객체지향 패러다임의 관점에서 핵심)
애플리케이션의 구현을 위해 어떤 협력이 필요하고,
협력을 위해 어떤 역할과 책임이 필요한지 고민해야한다.
너무 이른 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는다.
다양한 객체들 사이에 균형 있게 분배되는 것이 일반적
객체가 협력에 참여하기 위해 수행하는 로직은 책임
객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할
책임: 협력에 참여하기 위해 객체가 수행하는 행동
책임은 두가지 분류 : 아는 것과 하는것
하는 것
- 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작시키는 것
- 다른 객체의 활동을 제어하고 조절하는 것
아는 것
- 사적인 정보에 관해 아는 것
- 관련된 객체에 관해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
자신이 맡은 책임을 수행하는 데 필요한 정보를 알고 있을 책임.
또한 자신이 할 수 없는 작업을 도와줄 객체를 알고 있을 책임
→ 책임을 능숙하게 소프트웨어 객체에 할당하는 것
CRC 카드 →후보, 책임, 협력자
역할 식별, 책임 할당, 협력을 명시적으로 표현하는 구체적이면서 실용적인 설계 기법
정보 전문가 패턴
책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것
→연쇄적으로 정보 전문가를 찾아서 요청함
책임 주도 설계
협력을 설계하기 위해서는 책임에 초점 → 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계
- 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 할당한다.
- 시스템 책임을 더 작은 책임으로 분할한다.
- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
- 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
- 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.
메시지가 객체를 결정
메시지부터 선택하고, 그것을 처리할 객체를 나중에 선택하는 것이 중요하다.
객체를 먼저선택하는 것이 아니라 메시지가 객체를 선택하게 하자
- 최소한의 인터페이스를 가질 수 있게 된다.
- 추상적인 인터페이스를 가질 수 있게 된다.
행동이 상태를 결정한다
객체 → 협력에 참여하기 위해 존재
State는 행동을 결정하고 나서야 결정할 수 있다.
역할
객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.
→ 유연하고 재사용 가능한 협력을 얻을 수 있기 때문에 중요
새로운 할인 정책을 추가하기 위해 새로운 협력을 추가할 필요가 없어졌음(OCP)
역할을 만들고, 그 역할을 하는 객체들을 계속 만들 수 있음
추상 클래스와 인터페이스 = 구체 클래스들이 따라야 하는 책임의 집합
객체 대 역할
오직 한 종류의 객체만 협력에 참여하는 상황에서 역할이라는 개념을 고려하는 것이 유용할까?
협력이 적합한 책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주한다.
협력 →역할 → 객체 →클래스
다양한 객체들이 협력에 참여한다는 것이 확실하면 역할부터
모든 것이 안개 속에 둘러싸여 있고 정확한 결정을 내리기 어려운 상황이라면 구체적인 객체로 시작
대부분의 객체지향 언어에서 역할을 구현할 수 있는 언어적인 편의 장치를 제공하지는 않음