GRASP 패턴
General Responsibility Assignment Software Patterns
각 개체에 책임을 부여하는 원칙
- Information Expert Patter
OOD에서 책임을 부여하는 가장 기본적인 원칙은 무엇일까?
책임을 수행하는 데 필요한 정보가 있는 클래스인 Information Expert에게 책임을 할당하는 것이다.
- Creator Pattern
클래스의 새 인스턴스를 만드는 책임은 누구한테 있을까?
다음 중 하나가 참인 경우 클래스 B에 클래스 A의 인스턴스를 생성할 책임을 할당
(A를 생성하는 B)
- A객체는 B의 일부이다.
- B는 A 객체를 포함합니다.
- B는 A 개체의 인스턴스를 기록합니다.
- B는 A 객체를 밀접하게 사용합니다.
- B는 A가 생성될 때 A에게 전달될 초기화 데이터를 가지고 있습니다.
- Low Coupling Pattern
의존성을 낮추고 재사용성을 높이는 방법은 무엇일까?
답은 결합도(Coupling)를 낮추는 것이다.
결합도는 클래스 간의 의존성 정도를 보여주는 것으로 결합도를 낮춤으로써
클래스간의 독립적이고 재사용성을 높인다.
다른 구성요소에의 영향을 덜 받게 되는 것이다.
그렇다면 결합 형태는 어떻게 알 수 있을까?
-
X가 Y를 인스턴스 변수로 갖고 있을 때
*인스턴스변수 : 클래스 내부와 메소드 외부에 정의된 변수를 의미 -
X가 가진 메소드가 Y를 매개변수로 사용할 때, return 값으로 Y를 사용할 때, 지역변수로 사용할 때
-
X가 Y의 직간접 서브 클래스일 때 (X가 Y의 클래스를 상속받음)
-
Y는 인터페이스고 X는 인터페이스의 구현물일 때
- High Cohension Pattern
복잡성을 관리하는 방법은 무엇일까?
답은 하나의 클래스가 한 가지 일을 잘하도록 해서 응집성을 높이는 것이다.
응집력이란 클래스의 책임이 얼마나 밀접하게 관련되어 있고 집중되어 있는지를 의미한다.
응집력이 낮으면 이해하기 어렵고, 재사용성 낮고, 유지관리 어렵고 다른 구성요소에 쉽게 영향을 받는다.
높은 응집도와 낮은 결합도를 유지하는 것은 Envaluative Patterns(평가패턴) 이다.
- Controller Pattern
시스템 이벤트는 누가 처리해야 할까?
시스템 이벤트(사용자의 요청)를 처리할 객체를 만들자. 시스템, 서브시스템으로 들어오는 외부 요청을 처리하는 객체를 만들어 사용하라. 만약 어떤 서브시스템안에 있는 각 객체의 기능을 사용할 때, 직접적으로 각 객체에 접근하게 된다면 서브시스템과 외부간의 Coupling이 증가되고, 서브시스템의 어떤 객체를 수정할 경우, 외부에 주는 충격이 크게 된다. 서브시스템을 사용하는 입장에서 보면, 이 Controller 객체만 알고 있으면 되므로 사용하기 쉽다.
- Polymorphism
유형에 따라 대안을 처리하는 방법은? 플러그처럼 모듈식으로 소프트웨어를 생성하는 방법은 무엇일까?
관련된 대안이나 동작이 유형(클래스)별로 다를 때 다형성 연산을 사용하여 동작에 대한 책임을 유형에 따라 할당하자.
- Pure Fabrication
전문가 패턴 적용시 낮은 결합도와 높은 응집도가 깨지는 경우에 어떡할까?
별도의 인위적이고 편의성을 가진 클래스에 매우 응집력 있는 책임 기능을 할당하자.
예시> 각각의 Sale 인스턴스를 관계형 데이터베이스에 저장해야할 때 그 기능을 Sale이 담당하게 된다면
Low Coupling 원칙이 깨지게 된다. 따라서
별도의 PersistentStorage에 그 역할을 부여하는 것이다.
- Indirection
둘(또는 그 이상) 사이의 직접적인 연결을 피하기 위해 책임을 어디에 할당할까? Low Coupling이면서 재사용 가능성이 더 높게 유지되도록 개체를 분리하는 방법은?
그 사이에 다른 객체를 사용하라. 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다. 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.
