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

www.notion.so/2-GRASP-c485daef91e74ae1925641406f126b7c

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

• General Responsibility Assignment Software Pattern (일반적인 책임할당을 위한 소프트웨어 패턴)

도메인 개념에서 출발하기

• 설계 시작전 도메인에 대한 개략적인 모습을 그려보는것이 유용하다.
• 어떤 책임을 할당할때 가장 먼저 고민해야하는 유력한 후보가 바로 도메인

 

• 설계를 시작할때 완벽할 필요는 없다.
• 도메인 개념을 정리하는데 너무 많은 시간을 들이지말고 빠르게 설계와 구현을 진행하라.
• 올바른 도메인 모델이란 존재하지 않는다
• 실용적이면서 유용한 모델이 정답이다

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

• 책임을 애플리케이션에 대해 전송된 메시지로 간주하고 이 메시지를 책임질 첫번째 객체를 선택하는 것으로 설계를 시작한다.
• 책임을 수행하는데 필요한 메시지를 결정해야 한다.
• 메시지는 메시지를 수신할 객체가 아니라 메시지를 전송할 객체의 의도를 반영해서 결정해야 한다.

메시지를 전송할 객체는 무엇을 원하는가 ?

• 우선 첫번째는 바로 영화를 예매하는 것이다.
• 메시지의 이름은 예매하라가 절절한것 같다.

메시지를 수신할 적합한 객체는 누구인가 ?

• 객체가 상태와 행동을 통합한 캡슐화의 단위 이므로 스스로 처리해야하는 자율적인 존재여야만 한다.
• 객체의 책임과 책임을 수행하는데 필요한 상태는 동일한 객체 안에 존재해야 한다.
• 따라서 객체에게 책임을 할당하는 첫 번째 원칙은 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이다.
• GRASP에서는 이를 INFORMATION EXPERT (정보 전문가) 라고 한다.
• 여기서 이야기하는 정보는 데이터와 다르다
• 책임을 수행하는 객체가 정보를 알고 있다고 해서 그 정보를 저장하고 있을 필요는 없다.
• 객체는 해당 정보를 제공 할수 있는 다른 객체를 알고 있거나 필요한 정보를 계산해서 제공할 수도 있다.
• 어떤 방식이건 정보 전문가가 데이터를 반드시 저장하고 있을 필요는 없다.
• 이제 예매하라 메시지를 수신했을 때 Screening이 수행해야 하는 작업의 흐름을 생각해보자, 이제부터는 외부의 인터페이스가 아닌 Screening의 내부로 들어가 메시지를 처리하기 위해 필요한 절차와 구현을 고민해보는 것이다.
• 지금은 개략적인 수준에서 객체들의 책임을 결정하는 단계이기 때문에 너무 세세한 부분까지 고민할 필요는 없다.
• 단지 Screening이 책임을 수행하는 데 필요한 작업을 구상해보고 스스로 처리할 수 없는 작업이 무엇인지를 가릴 정도의 수준이면 된다.
• 만약 스스로 처리할수 없다면 외부에 도움을 요청해야 한다. 이요청이 외부로 전송해야하는 새로운 메시지가 되고, 최종적으로 이 메시지가 새로운 객체의 책임으로 할당된다. 이같은 연쇄적인 메시지 전송과 수신을 통해 협력 공동체가 구성되는 것이다.

예매에 필요한 것은 영화의 가격이다 Screening은 스스로 처리할수 없고 이 정보는 Movie가 들고 있다.

• movie는 영화가격을 계산할 책임을 가지게 됬다.

Movie는 스스로 할인여부를 판단할수 없다. 메시지를 전송해 외부에 요청하자.

• DiscountCondition이 이 책임을 할당받을수 있다.
• 이 친구는 스스로 처리할수 있기에 외부에 요청하지 않는다.
• 이렇게 Information Expert 패턴은 객체에게 책임을 할당할 때 가장 기본이 되는 책임할당 원칙이다.
• Information Expert 패턴은 객체란 상태와 행동을 함께 가지는 단위라는 객체지향의 가장 기본적인 원리를 책임할당의 관점에서 표현한다.
• Information Expert패턴을 따르는것만으로도 자율성 높은 객체들로 구성된 협력 공동체를 구축할 가능성이 높아지는것이다.

높은 응집도와 낮은 결합도

• 설계는 트레이드오프 란것을 기억하자.
• 올바른 책임 할당을 위해 Information Expert 패턴 이외의 다른 책임 할당 패턴들을 함께 고려할 필요가 있다.
• 위에서 보면 Moive가 DiscountCondition에 할인여부를 묻는데 이건 Screening에서도 물어봐도된다. 하지만 왜 Moive가 물어보게 했을까 ?
• 그 이유는 응집도와 결합도에 있다
• 책임을 할당할 때 항상 고려해야되는 기본 원리다.
• 다양한 대안들이 존재한다면 응집도와 결합도의 측면에서 더 나은 대안을 선택하는 것이 좋다.
• 다시말해 두 협력 패턴중에서 높은 응집도와 낮은 결합도를 얻을수 있는 설계가 있다면 그것을 선택해야 한다는 것이다.
• GRASP에서는 이를 low Coupling ( 낮은 결합도 ) 패턴과 High Cohesion ( 높은 응집도 ) 패턴 이라고 부른다.
• 도메인을 보면 Moive는 이미 DiscounCondition을 가지고 있다 낮은 결합도를 위해 Moive에서 하는것이 더 좋다.
• 이를 높은 응집도 측면에서 본다면 Screening의 책임은 예매하는것이다.
• 하지만 요금계산과 관련된 책임을 일부 떠안을 경우 요금계산식이 변경되면 Screening이 변경되고 서로 다른 이유로 변경되는 책임을 짊어지게 된다. 그러므로 응집도가 낮아질수 밖에 없다

창조자에게 객체 생성 책임을 할당하라.

• 영화예매 협력의 최종 결과물은 Reservation 인스턴스를 생성하는 것이다.
• 이것은 어떤 객체에게 Reservation 인스턴스를 생성할 책임을 할당해야 한다는 것을 의미한다.
• GRASP의 CREATOR ( 창조자 ) 패턴은 이같은 경우에 어떤 객체에게 할당할지 지침을 제공하는 패턴이다.
  1. B가 A객체를 포함하거나 참조한다.
  2. B가 A객체를 기록한다.
  3. B가 A객체를 긴밀하게 사용한다.
  4. B가 A객체를 초기화하는데 필요한 데이터를 가지고 있다 ( 이 경우 B는 A에 대한 정보전문가다 )
  • CREATOR 패턴의 의도는 그 객체를 사용해야 하는 객체는 어떤 방식으로든 생성될 객체와 연결될 것이기 때문에 잘알고 있어야한다.
  • 다시 말해 두 객체는 서로 결합한다.
  • 이미 결합돼 있는 객체에게 생성 책임을 할당하는 것은 추가적인 결합도가 생성되지 않으므로 결합도에 영향을 끼치지 않는다.
• Screening이 Moive도 알고 예매정보를 생성하는 것에 대한 정보도 정보전문가이므로 Screening이 CREATOR로 적당하다