# 책임 할당을 위한 GRASP 패턴

* GRASP(General Responsibility Assignment Software Patterns) 패턴
  * 객체에게 `책임을 할당`할 때 지침으로 삼을 수 있는 원칙들의 집합을 `패턴`형식으로 정리

## 책임 할당을 위한 GRASP 패턴

* `정보 전문가`에게 `책임을 할당`하라
  * `INFORMATION EXPERT(정보전문가)` 패턴
    * 객체에게 책임을 할당할 때 가장 기본이 되는 책임 할당 원칙
    * 책임을 수행할 정보를 알고있는 객체에게 책임을 할당
    * 정보와 행동을 최대한 가까운 곳에 위치시키기 때문에 캡슐화를 유지
    * 필요한 정보를 가진 객체들로 책임이 분산되기 때문에 더 응집력 있고, 이해하기 쉬워진다.
* `창조자`에게 `객체 생성 책임을 할당`하라
  * `CREATOR(창조자)` 패턴
    * 객쳬를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공
    * 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것
    * 생성될 객체에 대해 잘 알고 있어야 하거나 그 객체를 사용해야 하는 객체는 어떤 방식으로든 생성될 객체와 연결될 것
    * 이미 존재하는 객체 사이의 관계를 이용하기 때문에 설계가 낮은 결합도를 유지할 수 있게 한다.
* Controller
  * 시스템 이벤트(사용자의 요청)를 처리할 객체를 만들자.
  * 시스템, 서브시스템으로 들어오는 외부 요청을 처리하는 객체를 만들어 사용하라
* `높은 응집도`와 `낮은 결합도`
  * `LOW COUPLING(낮은 결합도)` 패턴
    * 어떻게 하면 의존성을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킬 수 있을까?
    * 불필요한 연결을 줄이도록 책임을 할당한다.
  * `HIGH COHESION(높은 응집도)` 패턴
    * 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인가?
    * 응집도가 높아지도록 책임을 할당한다.
* `POLYMORPHISM(다형성)`
  * 객체의 타입에 따라 변하는 로직이 있을 때 변하는 로직을 담당할 책임을 어떻게 할당해야 하는가?
  * 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하라.
  * `전략 패턴(Strategy Pattern)`
  * 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고한다.
  * 대신 다형성을 이용해 새로운 변화를 다루기 쉽게 확장하라고 권고한다.
* `PURE FABRICATION(순수 조립)`
  * Information Expert 패턴을 적용하면 Low Coupling과 High Cohesion의 원칙이 깨어진다면, 기능적인 역할을 별도로 한 곳으로 모으자.
  * 공통적인 기능을 제공하는 역할을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.
* `INDIRECTION(간접 참조)`
  * 두 객체 사이의 직접적인 `Coupling`을 피하고 싶으면, 그 사이에 다른 객체를 사용하라.
  * 두 개의 서비스나 컴포넌트를 연결하지 말고, 중간 매개체에 책임을 할당하라.
  * 중재자 패턴(Mediator Pattern)
  * 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다.
* `PROTECTED VARIATIONS(변화에 대한 보호)` 패턴
  * 책임 할당의 관점에서 캡슐화를 설명한다.
  * 설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화하라
  * 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 `인터페이스를 형성하도록 책임을 할당`하라
  * 하나의 클래스가 여러 타입의 행동을 구현하고 있는 것처럼 보인다면 클래스를 분해하고 POLYMORPHISM 패턴에 따라 책임을 분산
  * 예측 가능한 변경으로 인해 여러 클래스들이 불안정해진다면 PROTECTED VARIATIONS 패턴에 따라 안정적인 인터페이스 뒤로 변경을 캡슐화


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://seokrae.gitbook.io/sr/book/object/_3.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
