GRASP 패턴

응집도와 결합도, 캡슐화처럼 구체적인 기준에 따라 책임을 할당하고 트레이드오프할 수 있는 기준

지금까지 주요 과정

2장: 책임 중심 코드의 대략적인 모양
3장: 객체지향 프로그래밍에서 역할, 책임, 협력의 역할
4장: 역할, 책임,협력이 아닌 데이터(상태)에 초점을 맞출 때의 문제점

1. 책임 주도 설계를 향해

• 데이터보다 행동을 먼저 결정하라
• 협력이라는 문맥 안에서 책임을 결정하라

데이터보다 행동을 먼저 결정하라

객체에게 중요한 것은 외부에 제공하는 행동(책임)이다.

협력이라는 문맥 안에서 책임을 결정하라

객체에 할당된 책임은 협력에 적합해야한다. 책임이 조금 어색해보이더라도 협력에 적합하다면 괜찮다.
책임은 객체의 입장이 아니라 협력에 적합해야 한다.

Metz12
메세지를 전송해야 하는데 누구에게 해야하지? 라 질문하는 것이 메시지 기반(책임 주도) 설계로 향하는 첫걸음이다.

메세지를 먼저 결정하기 때문에 수신자에 대한 어떤 가정도 할 수 없다.

책임 주도 설계

• 사용자에게 제공해야하는 책임을 파악한다.
• 책임을 더 작은 책임으로 분할한다.
• 적절한 객체에게 할당한다.
• 책임을 수행하기 위해 도움이 필요한 경우 관계된 클래스 혹은 역할을 찾는다
• 해당 객체 또는 역할에게 책임을 할당하여 두 객체가 협력하게 한다.

2. 책임 할당을 위한 GRASP 패턴

General Responsibility Assignment Software Pattern

일반적인 책임 할당을 위한 소프트웨어 패턴

도메인 개념에서 출발하기

도메인 개념을 정리하는 데 많은 시간을 들이지 말고 설계와 구현을 진행하라.
올바른 구현을 이끌어낼 수만 있다면 올바른 도메인 모델이다.

정보 전문가에게 책임을 할당하라

사용자에게 제공할 책임은 영화를 예매하는 것이다.
메세지는 정했으니 수신하기에 적합한 객체를 정한다.

어떻게 정할까?

객체는 상태와 행동을 통합한 캡슐화의 단위다.
따라서 책임(행동)을 수행할 정보(상태)를 가지고 있는 객체에게 할당한다.
GRASP에서는 이를 정보 전문가 패턴(INFORMATION EXPERT)이라고 부른다.

정보 전문가 패턴을 따르면 정보와 가장 가까운 곳에 책임을 할당하기 때문에 다른 외부 객체들은 해당 정보가 은닉되어 있어도 해당 객체와의 협력을 통해 캡슐화를 유지하고 책임을 수행할 수 있다.