GRASPPattern

Assigning Responsibilities

(클래스 설계 시 어떤 클래스에 책임을 부여할 것인가를 결정하는 원칙)

(註) 이 내용은 주로 Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design by Craig Larman 에서 발췌한 것입니다.

(註) GRASP : General Responsibility Assignment Software Patterns

차례

  1. responsibility란 무엇인가?

  2. GRASP

    • Expert

    • Creator

    • High Cohesion

    • Low Coupling

    • Controller

    • Polymorphism

    • Pure Fabrication

    • Indirection

    • Don't talk to Strangers

  3. several OO maxims

    • encapsulate the concept that varies

    • program to an interface, not an implementation

    • favor object composition over class inheritance

1. responsibility란 무엇인가?

a contract or obligation of a type or class (Booch and Rumbaugh)

책임은 행동의 관점에서 객체의 의무와 관련이 있다. 책임은 보통 1. knowing, 2. doing 두 가지 유형으로 나뉜다.

doing

knowing

책임은 메소드와 같지는 않지만 책임을 충족시키기 위해 메소드를 구현한다. 즉, 책임을 구현하기 위해 혼자 동작하는, 혹은 다른 메소드나 객체와 협업하는 메소드들을 사용한다.

2. GRASP 2.1 Expert

사용법

정보 전문가(어떤 일을 수행하는 데 필요한 정보를 가진 클래스)에게 책임을 맡겨라.

적용 영역

객체에게 책임을 부여하는 가장 기본적인 원칙.

유사어

* Place responsibilities with data * That which knows, does. * Animation * Do it Myself * Put Services with the Attributes The Work On

기타

2.2 Creator

사용법

다음 조건들 중 하나라도 만족하면, A 클래스의 인스턴스를 생성할 책임을 B 클래스에게 맡겨라.

적용 영역

누가 어떤 클래스의 인스턴스를 생성할 책임을 질 것인가?

유사어

기타

Low Coupling 참조.

2.3 Low Coupling

사용법

Coupling(결합도)이 low가 되도록 책임을 맡겨라.

적용 영역

어떻게 dependency를 줄이고 재사용을 용이하게 할 것인가?

유사어

기타

Coupling이란 어떤 클래스가 다른 클래스들에 얼마나 강하게 연결되었는지, 많이 알고 있는지, 혹은 의존하고 있는지에 대한 척도이다.

low(혹은 weak) coupling으로 된 클래스는 지나치게 많은 다른 클래스들에게 의존하지 않는다. 의존 정도가 지나치면 다음 문제가 생긴다.

2.4 High Cohesion

사용법

Cohesion(응집도)이 high가 되도록 책임을 맡겨라.

적용 영역

어떻게 복잡한 것을 용이하게 유지할 것인가?

유사어

기타

OO 설계 용어로서 Cohesion(기능적 cohesion)이란 어떤 클래스의 책임들이 얼마나 강하게 연결되어 있는지 그리고 집중되어 있는지에 대한 척도이다.

high cohesion을 가진 클래스는 아주 관련이 큰 책임들로 구성되어 있으며 지나치게 많은 일을 하지 않는 클래스이다.

cohesion이 높지 않은 클래스들은 많은 관련 없는 일들을 하거나 지나치게 많은 일을 하는데 다음 문제들을 안게 된다.

2.5 Controller

사용법

시스템 이벤트 메시지 처리는 다음 중 하나를 나타내는 클래스에게 책임을 맡겨라.

적용 영역

누구에게 시스템 이벤트를 처리하는 책임을 맡길 것인가?

유사어

기타

2.6 Polymorphism

사용법

관련된 대체 기능이나 행위들이 유형(클래스)에 따라 변할 때에는 이 행위들에 대한 책임을 이 행위가 (polymorphic operation에 의해) 변하는 그 유형에 대해 맡겨라.

적용 영역

어떻게 유형에 기반한 대체 행위들을 처리할 것인가? 어떻게 pluggable한 소프트웨어 컴포넌트를 만들 것인가?

유사어

기타

2.7 Pure Fabrication

사용법

매우 응집된 책임들의 집합은 high cohesion, low coupling, reuse를 위해 problem domain의 어떤 것도 나타내지 않는, 인위적으로 만든 클래스에 맡겨라.

적용 영역

절실하게 High Cohesion 과 Low Coupling을 위반하고 싶지 않을 때.

유사어

기타

보통 Pure Fabrication은 관련된 기능들에 기반하여 분리되므로, 좋은 객체 지향 설계는 기능 중심이 아니라 객체 중심이어야 한다는 취지가 훼손되기 쉽다.

2.8 Indirection

사용법

서로 다른 컴포넌트나 서비스들이 직접 couple되지 않도록 중재하기 위해 중간 객체에게 책임을 맡겨라.

적용 영역

유사어

기타

2.9 Don't Talk to Strangers

사용법

클라이언트가 어떤 간접 객체와 협업할 때 클라이언트가 이 간접 객체에 대해 알 필요가 없도록 클라이언트의 직접적인 객체에게 책임을 맡겨라.

이 패턴은 메소드 안에서 메시지를 보낼 수 있는 대상 객체들에 제약을 둔다. 즉, 메소드 안에서 메시지는 다음 객체들에게만 보내야 한다.

적용 영역

간접 객체들의 구조에 대해 아는 것을 피하려면 어떻게 해야 하는가?

유사어

Law of Demeter([그神〕 데메테르. 대지의 생산을 관장하는 여신; 로마 신화의 Ceres에 해당함.)

기타

3. 몇 가지 객체 지향 설계의 격언들