🎫소프트웨어 공학 part17~18. grasp 책임을 이용한 객체 설계

Grasp이란?

분석이 끝나고 객체를 설계할 때, 이러한 노하우를 정리해 놓은 것이 grasp!

UML과 설계 원칙

• UML의 세부사항을 잘 안다고 객체지향적 설계를 할 수 있는 것이 아니다!
• 책임을 이용하여 설계하는 것이 중요하다.
• 분석 단계가 끝났을 때 객체 설계를 위한 UML 모델링 (인터렉션 다이어그램)을 수행한다.
  인터렉션 다이어그램을 그릴 때가 바로 책임을 할당하는 시간이다.
  해당 책임을 수행할 적합한 담장자가 있다면 할당하고, 없으면 적합한 담당자를 생성한다.

Modeling Day에는 무엇을 해야하는가?

• Grasp과 GoF 패턴을 사용하여 책임주도 설계를 한다.
• 설계 단계에서 가장 많이 쓰는 것은 오퍼레이션 약정이며, 없으면 SSD을 사용한다.

책임 주도 설계(RDD) : RDD는 메타포어이다. (“객체를 사람으로 생각할 수 있다”)

• 책임(물품을 프랜차이즈에 공급할 책임), 역할(물품을 공급), 협력(공급할 물품을 제작)

Grasp (General Responsibility Assignment Software Pattern)

• 책임을 할당하기 위한 디자인 패턴
• Grasp을 한단어로 표현하면? 이해하다.

CRC

"Class - Responsibility - collaborator"(객체 - 책임 - 공동 작업자)의 약자

패턴이란?

• Pattern Name / Problem / Solution 으로 나눈다.

  패턴의 이름의 해석
  

Data Mapper

• 도메인 레이어를 만드는 사람이 DB를 이해하고, SQL 사용법을 알지 않아도 된다.
• 즉 도메인 레이어를 만드는 것이 집중할 수 있다.
• dada mapper에서 SQL문장을 수행하고, 해당 객체를 DB에서 찾아 도메인에 반환 해주는 것.
• 도메인 레이어와 DB사이에 있는 것이 바로 mapper이다.
  

GoF 패턴

• 4명의 갱들이 만든 디자인 패턴

Grasp을 이용한 객체 설계의 패턴 5개

• Creator (객체를 만드는 책임)
• Information Expert (해당 정보를 잘 알고 있는 객체여야 한다.)
• Low Coupling (커플링-연결성이 이 작아야 한다.)
• Controller (컨트롤 해줌)
• High Cohesion (응집도. 한 객체가 한가지의 책임만을 한다.)
  

Information Expert 패턴의 예제

예제 : 어떤 클래스가 Sale의 총액을 알 필요가 있는가? → Sale

• 문제 : sale의 총액을 구하기 위한 정보를 가지고 있는가? (가장먼저 필요한 고려사항)
• 해결책 : sale의 총액을 결정할 수 정보를 가진 객체에게 할당한다.
  

Information Expert를 적용하므로써, getTotal을 호출하는 Sale이 해주어야하는 일이 분산되었다. 즉, 각 정보를 가장 잘 알고 처리할 수 있는 객체들에게 책임이 분산되었다.

추가적인 논의

• 어플리케이션 로직(도메인 로직)과 데이터베이스 로직을 다른 곳에 위치. (책임을 분산)

Creator 패턴

• 직접 만들지 말고, 생성을 위임할 객체를 찾으라는 의미
  SaleLineitem 인스턴스를 생성하는 책임은 누가 가지는가? Sale
  

핵심

• 생성된 객체와 연관이 되는 객체를 생성자로 선택하여 커플링을 낮춘다.
  
• 복잡한 과정이 필요할때는 Factory를 사용한다. (생성을 외주 맡김)
  

Controller Pattern

• UI 계층으로부터 가장 먼저 메세지를 받는 계층이다.
• 즉, UI로 부터 오는 메세지를 받는 책임을 가지고 있다.

MVC 모델

사용하는 이유 : 모델 뷰 컨트롤러가 각자의 역할에만 충실하도록 만들어, 코드의 중복을 방지하고, 높은 유지보수성 및 확장성을 가진다.

Controller를 선택하는 방법

• 시스템 연산이 많지 않은 경우, 하나로 묶을 수 있는 Facade Controller를 사용
• 시스템 연산이 많은 경우, Usecase Controller를 사용
• 컨트롤러에 많은 책임이 부여되면 high cohesion을 달성하기 어렵다.

Low Coupling Pattern

• Payment 인스턴스를 생성하고 이 인스턴스를 Sale에 연관시킬 때, 이 일을 누가하는가?
• 둘 다 가능하다. 하지만 Sale이 생성하도록 하는 것이 좋다. (더 낮은 커플링)

java.util은 거의 모든 객체와 결합을 가진다. 하지만 문제가 되지않는 이유는?
→ 변화가 잘 일어나지 않는 안정된 요소이기 때문이다.

High Cohesion (높은 응집도)패턴

• Payment 인스턴스를 생성하고 생성된 인스턴스를 Sale과 연관시킬 필요가 있다. 이에 대한 책임을 어떤 클래스에 할당해야 하는가? → Sale에게 책임을 할당한다.
• Register에 할당할 시, 일단 low coupling이 발생하고 Register가 Domain Logic의 일또한 자기가 하게 되므로 응집도가 낮아진다.
  

총 몇개의 클래스를 만들 수 있는가?

• 들어오는 건 계산하지 않는다. 따라서 Sale(2), 나가는 연관 총 (2)개로 4개이다.

초기화와 Start up usecae

Q. 어플리케이션 시작 시, 얼마나 많은 라인이 필요한가?
A. 필요한 것만 적은 라인이 필요하다. 초기화 또한 책임 할당의 원칙을 따른다.