소프트웨어공학 - 17. GRASP

1. GRASP

- General Responsibility Assignment Software Patterns

- 객체 설계에 대한 9가지 원칙을 제시한다.

- 전형적인 OOAD의 순서는 "1. 요구사항 파악 -> 2. domain model 생성 -> 3. design model 생성" 이다.

- grasp은 구체적으로 3단계에서 "class에 속성을 부여"하고 "서로 관계를 맺는" 작업의 가이드라인을 제공한다.

- 즉 domian model을 보고 design model을 만든 원칙을 제시한다.

2. Responsibilities

- class의 책임을 정의한다.

knowing

- 그 클래스는 어떤 정보를 알고 있어야 하는가? 

- 관련있는 객체는 누구인가? (다른 객체들의 정보는 어디까지 알고 있는가?)

doing

- 그 클래스는 무슨 일을 해야 하는가?

3. Modularity

- 결국 grasp에 따른 설계의 목적은 시스템을 잘 모듈화 시키는 것이다. 잘 된 모듈화는 전체 시스템에 대한 복잡성을 낮춰준다.

- 올바른 모듈화 결과는 관심영역의 분할이 잘 되어 있고 (seperation of concerns) 모듈간의 인터페이스가 쉽고 간결하다 (information hiding)

- modularity를 측정하는 두가지 기준이 있다. coupling(모듈간의 상호 의존 정도), cohesion(한 모듈안에 내용들이 얼마나 강하게 관련 있는가?)

- coupling은 낮고 cohesion이 높을수록 좋다고 볼 수 있다.

- coupling이 심할수록 한 모듈에서의 change는 많은 다른 곳에 change를 야기한다. 또한 한 기능을 이해하기 위해 너무 많은 의존관계를 살펴봐야 한다. 물론 모듈의 재사용성도 낮아진다.

- A모듈은 서로 관련도가 낮은 세 responsibility를 지니고 있어 응집도가 좋지 않다. 반면 X, Y, Z 모듈은 각자 관련있는 responsibilities만 지니고 있다. 응집도가 높을수록 low coupling에 도움이 된다.

(1) Ceator Pattern 

- 예를들어 class A가 있을때, 이 객체를 누가 생성할 것이냐?에 주목하는 디자인 패턴이다.

- B가 A를 포함하거나? A와 관련이 깊거나 A의 값을 초기화 한다면? B가 A의 creator가 되는 것이 적합해 보인다.

- saleslineitem이라는 객체를 누가 만드는게 적합한가? 를 고민하고 있다고 해보자. creator design 패턴을 적용해보자.

- sale 클래스는 saleslineitem을 포함하고 있으므로 saleslineitem 인스턴스를 만들어내는 responsibility는 sale이 갖는것이 적합해 보인다.

(2) Information Expert Pattern

- 어떤 responsibility를 class에게 부여할때 관련된 information을 가지고 있는 class에게 부여하는 것이 적합하다.

- 판매 금액을 반환하는 기능을 누구에게 부여할 것인가? 고민된다면 전체 물품과 그 물품의 가격을 알고 있는 (saleslineitem들을 가지고 있는) sales class가 갖는 것이 적합해보인다.

(3) Controller pattern

- 전체 시스템을 운영하는 관리자 역할의 객체가 필요할 때 사용하는 디자인 패턴이다.

- 꼭 하나일 필요는 없고 시스템의 시나리오 별로 통제하는 작업을 수행하는 객체를 둘 수 있다.

- 예를들면 사용자의 Input을 받아서 해당하는 api를 호출해주는 Handler class를 만들 수 있다.

(4) low coupling pattern

- 어떤 responsibility를 추가하려고 할 때, coupling을 제일 낮출 수 있는 곳에 추가하는 패턴이다.

- 결제가 이루어질때 payment를 만들어내는 responsibility를 추가해야하는 상황이다. register에게 추가하는 것 보다 sale에 추가하는 것이 훨씬 coupling이 low하므로 두번째 방법을 선택한다.

(5) High cohesion pattern

- responsibility를 추가할 때 cohesion을 높일 수 있는 방향을 선택하는 패턴이다.

- 결제가 이루어질때 payment를 만들어내는 responsibility를 추가해야하는 상황이다. register에게 추가하는 것 보다 sale에 추가하는 것이 훨씬 cohesion이 높으므로 두번째 방법을 선택한다.

(6) Pure Fabrication Pattern

- responsibility를 기존 객체에 추가하려는데 cohesion, coupling issue를 발생시킨다면 아예 새로운 객체를 만들어 버리는 방식이다.

- domain layer에서 파악되지 않은 새로운 객체가 design layer에서 등장하게 된다.

(7) Polymorphism Pattern

- 우리가 잘 알고 있는 상속, 오버로딩, 오버라이딩, 다형성을 설계시에도 작 적용하자는 패턴이다.

(8) Indirection Pattern

- responsibility를 추가할 때, 직접 coupling을 만들기 싫을 때 매개하는 객체를 만드는 방법이다.

- sale객체가 TaxMasterSystem과 통신하고 싶다. 근데 직접 연결하는 것이 좋아보이지 않는다. 따라서 이 작업을 매개해주는 TaxMasterAdapter를 추가한다.

(9) Protected Variations Pattern

- 기능을 추가할때 기존 코드의 변화는 최소화하도록 하는 원칙이다.