GRASP

OOAD에서의 software 구성 단계

1. requirement들을 식별
2. domain model 생성
3. design model 생성
   1. attributes와 methods을 추가
   2. object들 간의 상호작용 정의

하지만 design model을 어떻게 생성할 것인가?

-> GRASP : responsibility을 어떻게 배정할 지 결정

Responsibilities

class의 의무

• Knowing responsibilities
  • 어떤 attribute가 어느 class에 들어가야 하는지 알아야 한다.
  • 관계되는 객체를 알고 있어야 한다. (모든 객체를 알고 있으면 좋지 않다.)
  • 어느 class로부터 무언가를 끌어오거나 계산할 수 있다. (Sale은 total을 알고 있을 책임이 있다.)
• Doing Responsibility
  • 무언가를 수행해야 한다.
  • 다른 객체에서 행동을 초기화 해야 한다.
  • 다른 객체에서 contolling 하거나 coordination 해야 한다. (Sale이 SalesLineItems을 만드는 것이 좋다.)

responsibility는 method가 아니다. 하지만 responsibilities는 여러개의 method로 구현 가능하다.

Modularity

design의 목표

system을 module들로 나누고 responsibility를 할당한다.

 

Modularity가 좋으면 감내해야 하는 복잡도를 감소 시켜준다.

• 유사한 기능이 있다면, 공통된 모듈로 모으는 것이 좋다. (관심사의 분리)
• Information Hiding

Modularity의 측정 방법

• Coupling(결합도) : 모듈들의 상호 의존성을 측정한다. (coupling 상승 => 안 좋음)
• Cohesion(응집도) : 한 모듈 안에 요소가 얼마나 강하게 관련성이 있는가? (cohesion 상승 => 좋음)

 

Coupling

class(module)간의 상호 의존성 측정

만약 독립적은 element가 변화하면 다른 독립적인 것도 영향을 끼친다.

한 모듈을 다른 모듈에서 끌어다 쓸때 불편하다.

Cohesion

하나의 class(module)안에 얼마나 관련성이 있는가 측정

Single Responsibility Principle (SRP) (단일 책임의 원칙)와 관련이 있다.

- 객체는 단 하나의 책임만 가져야 한다는 원칙

Creator Pattern

문제 정의 : A 객체를 누가 만드는가?

해결 방안

다음 중 하나라도 만족할 때, class B를 class A가 생성하도록 할당한다.

• B는 A를 포함하거나, aggregates 관계이다.
• B는 A를 기록되어 있어야 한다.
• B는 A를 밀접하게 사용한다.
• B는 A를 초기화 하는 data를 가지고 있다.

다음에서 SaleLineItem 인스턴스를 만들 책임이 누구한테 있는가?

Sale은 SalesLineItem를 contains 하므로 Sale이 생성해야 한다.

Information Export

문제 정의 : responsibilities를 어느 객체에게 부여하는 것이 좋은가?

해결 방안

responsibilities을 이행하는데 필요한 정보를 가지고 있는 class에 responsibilities을 할당한다.

 

다음에서 Sale의 total을 해주는 대상을 누구에게 부여할 것인가?

Sale은 여러개의 SalesLineItem의 정보를 가지고 있으므로 Sale에 할당을 해준다.

Controller Pattern

문제 정의 : UI layer을 받고, system operation을 control하는 객체는 무엇인가?

문제 해결

다음 선택 중 하나를 선택하여 responsibility를 할당한다.

• root object가 위임한다 (facade controller)
• System operation이 일어나는 Use case scenario을 사용한다. (use case, session controller)

 

다음에서 enterItem과 endSale이 일어나는 controller가 무엇인가?

option1로는 register에 할당을 하고 option2로는 usecase 상의 ProcessSaleHandler에 할당한다.

Low Coupling Pattern

문제 정의 :  어떻게 변화의 영향이 낮아지게 할 수 있는가?

문제 해결

불필요한 coupling이 낮아지는 방향으로 responsibilities를 할당한다.

evaluate alternatives 원리를 사용한다.

 

우리는 Payment instance를 만들고, Sale과 연관을 시키고 싶다. 무슨 class에게 할당해야 하는가?

Option1)

Register가 Payment를 생성한다.

Option2)

Sale이 Payment를 생성하고 연관시킨다.

Hign Cohesion Pattern

문제 정의 : 어떻게 object를 Low Coupling이 되는 방향으로 만들 수 있는가?

해결 방안

cohesion이 상승하는 방향으로 responsibilities를 할당한다.

evaluate alternatives를 사용한다.

 

Payment를 만드는데 어디에 responsibility를 줘야 하는가?

Option1)

Register에 할당한다. => Register가 커질 수 도 있다.

Option2)

Sale에 위임한다.

Pure Fabrication Pattern

문제 정의 : high cohesion과 low coupling을 위반하고 싶지 않을 때 누구한테 responsibilities를 줘야 하는가?

해결 방안

 

나중에 다시 작성..