GRASP

GRASP

 

※ GRASP

- General Responsibility Assignemnt Software Patterns

- Craig Larman's 9 principles

- OOAD를 사용하여 소프트웨어를 구성하는 일반적인 작업을 의미함

• 도메인 모델을 만들다
• 디자인 모델을 만든다
  • 소프트웨어 클래스에 attribute 및 method 를 추가한다
  • 객체들 간의 interaction 을 정의한다

 

※ Modularity

- 시스템을 모듈로 분할하고 컴포넌트 간에 책임을 할당함

- 모듈화는 프로그래머가 한 번에 처리해야 하는 전체 복잡성을 줄여줌

- 유사한 기능을 함께 그룹화하는 방식으로 모듈에 기능을 할당함 (Separation of Concerns)

- 모듈 사이에 작고 단순하며 잘 정의된 인터페이스가 있음 (Information Hiding)

 

※ Coupling

- 클래스 간의 상호 의존성 측정

- 커플링이 높은 클래스는 다른 많은 클래스에 의존하게 됨 => 독립 요소 변경시, 종속 요소에 영향 미침

- 낮은 커플링을 추구해야 함

• 클래스에 따른 변경으로 인한 강제 변경이 없어짐
• 의존이 적어질수록 이해가 쉬워짐
• 코드 재사용이 높아짐

 

※ Cohesion

- 클래스의 요소가 얼마나 강하게 관련되어 있는지 측정

- 관련 책임은 관리 가능한 하나의 단위에 배치되어짐

- SR.P 와 관련되어 있음 (Single Responsibility Principle)

- 높은 응집력을 추구해야 함

• 쉽게 이해할 수 있으며 유지 관리 가능
• 코드 재사용이 높아짐
• 커플링이 낮음

 

※ Craig Larman's 9 principles

1. Creator
2. Information Expert
3. Controller
4. Low Coupling
5. High Cohesion
6. Pure Fabrication
7. Polymorphism
8. Indirection
9. Protected variations

위 9 가지 원칙들을 살펴보려고 한다.

 

Creator Pattern

 

클래스 B에 클래스 A의 객체를 생성할 책임을 할당할 때,

- B는 A를 포함하거나 집계- B는 A를 기록- B는 A를 밀접하게 사용- B는 A에 대한 초기화 데이터를 보유

 

위 내용들이 여러 개 만족한다면 좋다.

 

※ Creator Pattern

- 생성 책임들을 할당하는 가이드

- 낮은 커플링을 지원

- 관련 패턴으로 Abstract Factory, Singleton 이 있음

 

Information Expert Pattern

 

※ Information Expert Pattern

- 책임 할당에 있어서 가장 많이 사용되는 원칙

- 정보는 여러 객체에 걸쳐 퍼짐 (객체 별 상호작용 필요)

- 데이터베이스 로직을 여러 클래스에 분산함

- 낮은 응집력 및 커플링을 지원

 

Controller Pattern

 

UI 계층을 넘어서 시스템 작업을 수신하고 조정하는 첫 번째 객체는 무엇일까?

아래 두 옵션 중 하나를 나타내는 객체에 책임을 할당하면 된다.

(1) 전반적인 시스템, 루트 객체, 소프트웨어가 실행 중인 장치 또는 주요 하위 시스템 (facade controller)

(2) 시스템 작동이 발생하는 Use case 시나리오 (use case 또는 session controller)

 

※ Controller Pattern

- 너무 많은 책임으로 과부하가 걸릴 경우 해결책으로 아래와 같음

• 컨트롤러를 추가함 (Facade -> use-case controllers)
• 다른 객체들에게 책임을 위임함

- 재사용 가능한 컴포넌트에 대한 잠재력이 증대될 수 있음

- use case 상태에 대한 이유로 특정 순서로 작업 수행시 유용함

 

Low Coupling Pattern

 

※ Low Coupling Pattern

- 변화의 영향을 줄이는 방법은 커플링이 낮게 유지되도록 책임을 할당함

- 낮은 커플링은 설계를 보다 독립적으로 만들어 변화의 영향을 줄임

- 안정적인 "global" 객체에 대한 높은 커플링은 문제가 없음

  (ex: java.util과 같은 Java 라이브러리 연결)

 

High Cohesion Pattern

 

※ High Cohesion Pattern

- 객체를 집중, 이해 및 관리할 수 있도록 유지할 수 있음

- 즉, 응집력이 높게 유지될 수 있도록 책임을 부여함

 

Pure Fabrication Pattern

 

※ Pure Fabrication Pattern

- 높은 응집력, 낮은 결합력, 재사용을 지원하기 위해 구성된 문제 영역 개념을 나타내지 않는

  인공적이거나 편리한 "behavior" 클래스에 높은 응집력을 가진 일련의 책임을 할당함

 

예를 들어 Sale 객체를 DB에 저장하고 싶다고 할 때,

(1) Information Expert Pattern

    이 패턴에서는 Sale 클래스에 책임을 할당함

    이 경우 많은 DB 관련 작업을 필요로 하며 Sale 클래스는 낮은 응집력을 갖게 됨

    => 재사용이 힘들며 많은 중복이 발생할 수 있음

(2) Pure Fabrication Pattern

    영구 저장 매체의 객체 저장만을 담당하는 새 클래스 PersistentStorage 를 생성함

    이 경우 PersistentStorage 클래스에 DB 관련 책임을 할당함으로써,

    Sale 클래스는 판매 담당 책임을, PersistentStorage 클래스는 DB 저장 담당 책임을 갖게됨

    => 재사용이 편하며 높은 응집력을 갖게 됨

 

Polymorphism Pattern

   

※ Polymorphism pattern

- 타입별로 행동이 다를 때, 다형성 연산을 사용하여 동작을 변경하는 유형에 대한 책임을 할당함

- 명시적 선택 로직을 사용하는 것보다 쉽고 안정적이며 나중에 추가 동작을 쉽게 추가할 수 있음

- 알려지지 않은 잠재적 미래 변동에 대비하여 과도한 사용은 피해야 함

 

Indirection Pattern

 

※ Indirection Pattern

- 직접적인 결합을 피하기 위해 중간 객체에게 중재할 책임을 부여함

- Adapter, Facade, Proxy, Mediator ... 등이 있음

 

Protected Variations Pattern

 

※ Protected Variations Pattern

- 변동이나 불안정성이 다른 요소에 바람직하지 않은 영향을 미치지 않도록 하기 위해,

  다른 요소들을 중심으로 안정적인 "interface" 를 만들기 위한 책임을 할당함

- 변동으로부터 유연성 및 보호가 가능함

- 보다 구조화된 디자인을 제공함