[TIL]221109 - GRASP 책임을 이용한 객체 설계(1)

• UML과 설계 원칙
  • 책임을 이용해서 설계하라

객체 설계

• 분석 단계가 끝나면
  • 객체 설계를 위한 UML 모델링
  • Test Driven 으로 코딩 시작
• Modeling Day에는 시각적인 설계 모델링
  • 설계 모델링을 할 때 책임 주도 설계
    • GRASP과 GoF 패턴 적용
  • 문서화보다 의사소통이 중요한 모델링을 해야 함

책임과 책임 주도 설계

• 책임 주도 설계 (RDD, Responsibility Driven Design)
  • 책임(분류자의 약정 또는 의무), 역할, 협력(책임은 객체가 혼자서도 할 수 있지만 협력을 통해 수행하는 경우도 많음)
• RDD는 메타포어(Metapor; 은유법)임
  • 우리가 사는 세상을 흉내낸 것
  • 객체를 사람으로 생각할 수 있음

GRASP: 기본적인 객체지향 설계를 위한 조직적 접근

• 책임을 이용한 객체지향 설계를 위한 학습 도구
• General Responsibility Assignment Software Pattern
• Grasp
  • 붙잡다
  • 이해하다
  • 개념을 파악하다

책임, GRASP, UML 다이어그램의 연결

• 인터럭션 다이어그램을 그릴 때가 책임을 할당하는 시간임
  • 누구에게 이 작업을 할당할 것인가?
  • 책임자가 있으면 할당하고, 없으면 적합한 책임자를 생성하고 할당함
    • Know-Where

(디자인)패턴이란?

• Design Patter: 설계 패턴
  • 설계할 때 빈번하게 발생되는 문제들을 분류하여 해결방안을 정리한 것
  • 가장 간단하게 좋은 패턴은 잘 알려진 문제-솔루션 한 쌍
  • 새로운 상황에 적용하는 방법에 대한 조언과 절충, 구현, 변형 등에 대한 논의와 함께 새로운 상황에 적용될 수 있음

• 책임을 충족시킬 필요가 있는 데이터를 가진 클래스에 책임을 할당함

패턴에는 이름이 있음

• 덩이짓기(덩이짓기는 정보를 의미있는 묶음으로 만드는 것)를 지원함
• 그 개념을 우리의 이해와 기억에 통합함
  

• persistence subsystem: DB
• Factory: 객체 공장
• Mapper: AL의 object와 DB의 recode를 mapping시켜주는 역할
• Proxy: "대리"의 의미로, 내부 네트워크에서 인터넷 접속을 할 때에, 빠른 액세스나 안전한 통신등을 확보하기 위한 중계서버를 "프록시 서버"라고 함.
  • 클라이언트와 Web서버의 중간에 위치하고 있어, 대신 통신을 받아 주는 것이 프록시 서버임.
• lazy materializaion: 필요시에만 객체를 만드는 기술

GRASP를 이용한 객체 설계의 예

1. Creator
2. Information Expert
3. Low Coupling
4. High Cohesion
5. Controller

Informaion Expert Pattern 복습

• 문제: 객체에 책임을 할당하는 기본 원칙은 무엇인가?
• 해결책: 이를 수행하는 데 필요한 정보가 있는 클래스에 책임을 할당함
• 가이드
  • 책임을 명확히 기술하고, 책임을 할당하기ㅏ 시작할 것
  • 필요한 정보를 갖는 객체를 찾아라
    • 어디서 찾아야 하는가?
      - 설계 모델에서 찾는다.
      - 없으면 도메인 모델에서 찾고 이것을 소프트웨어 객체로 만든다
      - 도메인 모델을 소프트웨어 객체로 copy&paste 해놓는 게 편함
  • 예
    
• 여러 개의 객체에 책임이 분산됨

Information Expert 패턴에 대한 나머지 정보들

• 객체는 소유한 정보와 관련된 작업을 한다는 일반적인 직관을 반영
• 결과는 응집도, 결합도, 중복의 문제 야기
• 따라서 관심사항을 분리해야 함
  • 어플리케이션 로직(도메인 객체)은 한 곳에 위치
  • 데이터베이스 로직(분리된 영속 서비스 서브시스템)은 다른 곳에 위치
• Expert Supports Low Coupling

Creator 패턴

• 직접 인스턴스를 만들지 말고 생성을 위임할 객체를 찾아라
• 문제: 누가 A를 만드는가?
• 해결책: 다음 중 하나가 true인 경우 클래스 A의 인스턴스를 생성할 책임을 클래스 B에 할당함
  • B는 A를 포함하거나 복합적으로 집계함
  • B는 A를 기록함
  • B는 A를 밀접하게 사용함
  • B는 A에 대한 초기화 정보를 가짐

• 생성된 객체와 연관이 되는 객체를 생성자로 선택 -> 낮은 결합도 지원
• 복잡한 과정이 필요하거나, 재활용의 필요가 있을 때는 Factory 사용
• 장점: 낮은 결합도 지원

Controller Pattern

• UI계층으로부터 가장 먼저 메시지를 받는 계층은?

  • Controller

• UI 계층은 비즈니스 로직을 건드리면 안됨 -> coupling 증가
  

• 문제: UI 계층 너머에 있는 첫 번째 개체는 시스템 작업을 수신하고 조정(제어)하는 것은 무엇인가?

• 해결책 (다음 선택 사항 중 하나를 나타내는 객체에 책임을 할당함)

  • 전체 "system", "root object", 소프트웨어가 내부에서 실행되는 device 또는 주요 하위 시스템(모두 façade controller의 변형임)을 나타냄

  • 시스템 작동이 발생하는 유즈케이스 시나리오를 나타냅니다(use case controller)

    

• Register가 모든 일을 하지 않고 받아서 위임만 함
• System or Root object or Device

• Controller를 사용해서 UI와 Domain Layer를 분리
  • UI는 바뀌기 쉽기 때문에
• Controller를 선택하는 방법
  - low coupling and high cohesion

  • facade controller는 시스템 연산이 많지 않은 경우에 적합

  • usecase controller는 시스템 연산이 많은 경우

    • 시스템 연산의 순서를 관리하고자 하는 경우에도 적합

  • 컨트롤러에 너무 많은 책임이 부여되면 high cohesion을 달성하기 어려운 경우가 있음

  • 일반적으로 컨트롤러는 수행해야 하는 작업을 다른 개체에 위임해야 하며 활동을 조정하거나 제어함. 자체적으로 많은 작업을 수행하지 않음.