GRASP Pattern

GRASP Pattern

객체지향 설계에서 우리는 항상 ‘이 책임은 누가 가져야 할까?’ 라는 질문에 직면하게 된다.

GRASP(General Responsibility Assignment Software Patterns) 패턴은 Craig Larman이 제안한 책임 할당 기법으로, 총 9가지 패턴으로 구성되어 있으며, 각 패턴은 다음과 같다.

---

Information expert

책임을 정보 전문가, 즉, 책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 할당하라.

책임을 필요한 정보를 가장 잘 알고 있는 객체에게 할당함으로써 객체가 자율적인 존재여야 한다는 사실을 다시 한번 상기시킨다.

정보를 알고 있는 객체만이 책임을 어떻게 수행할지 스스로 결정할 수 있기 때문이다.

Information expert 패턴을 따르면 정보와 행동을 최대한 가까운 곳에 위치시키기 때문에 캡슐화를 유지할 수 있다.

필요한 정보를 가진 객체들로 책임이 분산되기 때문에 더 응집력 있고, 이해하기 쉬워진다.

따라서 높은 응집도가 가능하다. 결과적으로 결합도가 낮아져서 간결하고 유지보수하기 쉬운 시스템을 구축할 수 있다.

Creator

객체를 생성할 책임은 누가 가져야할까? 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여하자.

아래 조건을 최대한 많이 만족하는 B에게 객체 생성 책임을 할당하라.

• B가 A 객체를 포함하거나 참조한다.
• B가 A 객체를 기록한다.
• B가 A 객체를 긴밀하게 사용한다.
• B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다(이 경우 B는 A에 대한 정보 전문가다)

Creator 패턴의 의도는 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것이다.

생성될 객체에 대해 잘 알고 있어야 하거나 그 객체를 사용해야 하는 객체는 어떤 방식으로든 생성된 객체와 연결될 것이다.

다시 말해서 두 객체는 서로 결합된다.

이미 결합돼 있는 객체에게 생성 책임을 할당하는 것은 설계의 전체적인 결합도에 영향을 미치지 않는다.

결과적으로 CREATOR 패턴은 이미 존재하는 객체 사이의 관계를 이용하기 때문에 설계가 낮은 결합도를 유지할 수 있게 한다.

Controller

시스템 이벤트를 처리할 책임을 시스템의 경계에 있는 객체에 할당하라.

Controller 패턴은 사용자의 입력이나 외부 시스템으로부터의 이벤트를 처리할 객체를 선택할 때 사용하는 책임 할당 지침이다.

시스템 경계에 위치한 객체는 다음 중 하나로 구성될 수 있다:

• UI Layer와 도메인 로직 사이에 위치한 객체 (예: ApplicationService, Facade)
• 유스케이스를 나타내는 객체

Controller는 사용자의 요청을 해석하고 그 요청을 수행하기 위해 필요한 도메인 객체에게 메시지를 전달하는 역할을 한다.

비즈니스 로직을 직접 처리하지 않고, 책임을 도메인 객체로 위임하는 구조를 통해 관심사의 분리를 유지하고, UI와 도메인 계층 사이의 결합도를 낮출 수 있다.

결과적으로 Controller는 단일 진입점 역할을 하며, 시스템의 유연성과 확장성을 높인다.

Indirection

두 객체 간의 직접적인 연결을 피하고, 중개 객체를 통해 간접적으로 상호작용하도록 책임을 할당하라.

Indirection 패턴은 객체 간의 결합도를 낮추고 유연성을 높이기 위한 설계 전략이다.

이 패턴을 적용하면 다음과 같은 장점이 있다:

• 변화에 유연하게 대응할 수 있다.
• 모듈 간의 영향을 최소화할 수 있다.
• 테스트가 쉬워지고, 코드 재사용성이 높아진다.

예를 들어, 서비스 레이어나 이벤트 버스, 인터페이스를 통한 의존성 주입 등이 Indirection의 대표적인 사례다.

객체 간의 관계가 너무 직접적이라면, 그 중간에 추상화 계층이나 브로커 역할을 수행하는 객체를 두는 것을 고려하자.

Low coupling

객체 간의 전체적인 결합도가 낮게 유지되도록 책임을 할당하라.

객체가 너무 많은 다른 객체에 의존하면 변경에 매우 취약해진다 반대로 결합도가 낮으면 각 객체는 독립적으로 존재할 수 있고, 수정이 다른 곳에 미치는 영향도 줄어든다.

현재의 책임 할당을 검토하거나 여러 설계 대안들이 있을 때 낮은 결합도를 유지할 수 있는 설계를 선택하라.

High cohesion

높은 응집도를 유지할 수 있게 책임을 할당하라.

객체가 하나의 책임에 집중할 수 있도록 설계함으로써 다음과 같은 장점을 가질 수 있다.

• 하나의 명확한 목적을 갖는다.
• 내부 구성요소들이 서로 밀접하게 관련되어 있다.
• 변경 사유가 명확해진다.

객체 하나에 여러 역할이 섞여 있다면, 응집도를 높이기 위해 클래스를 분리하거나 책임을 조정하는 것을 고려하라.

Polymorphism

타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하라.

조건에 따른 변화는 프로그램의 기본 논리다.

프로그램을 if ~ else 또는 Switch ~ case 등의 조건 논리를 사용해서 설계한다면 새로운 변화가 일어난 경우 조건 논리를 수정해야 한다.

이것은 프로그램을 수정하기 어렵고 변경에 취약하게 만든다.

Polymorphism 패턴은 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고한다.

대신 다형성을 이용해 새로운 변화를 다루기 쉽게 확장하라고 권고한다.

Protected variations

변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라.

책임 할당의 관점에서 캡슐화를 설명한 것으로, 조건문 대신 다형성을 활용하여 유연한 구조를 만든다.

‘설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화하라’라는 객체지향의 오랜 격언은 Protected variations 패턴의 본질을 잘 설명해준다.

우리가 캡슐화해야 하는 것은 변경이다. 변경이 될 가능성이 높다면 캡슐화하라.

Pure fabrication

행동을 책임질 마땅한 도메인 개념이 존재하지 않는다면, 도메인 개념과 관련 없는 인위적으로 만든 객체에 객체에 책임을 할당하라.

Pure fabrication 패턴은 응집도나 결합도 측면에서 더 나은 설계를 만들기 위해, 현실 세계의 개념과 무관하지만 논리적으로 필요한 클래스를 만드는 것을 권장한다.

즉, 이 패턴은 응집도를 높이고 결합도를 낮추기 위해 도메인 모델 외의 객체를 도입하라는 것이다.

대표적인 예로는 Repository, DAO, Service, Validator 등이 있다.

이러한 객체는 현실 세계에서 직접 대응되는 개념이 없지만, 소프트웨어 내부적으로는 책임을 적절히 분산시키고, 관심사를 분리하는 데 매우 효과적이다.

Pure fabrication 을 적절히 활용하면 시스템을 더 테스트하기 쉬운 구조로 만들 수 있고, 모듈화 수준도 높아진다.

Links

• 오브젝트 - 조영호
• GRASP (object-oriented design) - Wikipedia
• GRASP 패턴 - 한빛+