객체지향의 사실과 오해 - chap 6 객체 지도

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다

기능 설계 vs 구조 설계

예측 불가능한 요구사항을 만족하는 기능을 제공하는 동시에 요구사항 변경에 유연하게 대처할 수 있는 구조를 가지는 소프트웨어를 만들어야함
변경을 수용할 수 있는 선택의 여지를 설계에 녹여 놓아야함
- 변경에 소요되는 비용을 낮출 수 있음
어떻게??
- 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하자!
- 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템의 기능을 객체 간의 책임으로 분배

기능
- 사용자가 목표달성을 위해 사용할 수 있는 시스템의 서비스
구조
- 시스템의 기능을 구현하기 위한 기반
- 기능변경을 수용할 수 있도록 안정적이어야함
기법
- 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들간의 관계로 표현
- 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
유스케이스 모델링
- 기능 수집하고 표현하기위한 기법
도메인 모델링
- 구조 수집하고 표현하기 위한 기법

순서
- 시스템 요구 사항을 식별
  - 유스케이스를 작성해 보자
    - 사용자 관점에서 시스템의 기능을 도출 할 수 있음
- 도메인 모델 생성 후 개념을 은유하는 소프트웨어 객체 선택
  - 도메인 모델을 통해 해당 도메인에서 통용되는 개념을 도출할 수 있음
    - 사용자와 설계자가 공유하는 안정적인 구조를 만들 수 있음
- 메세지를 식별하여 적절한 객체에게 책임 분배
  - 유스케이스로 부터 사용자에게 제공해야할 기능을 객체에게 역할 / 책임으로 분배
  - 책임 할당의 원칙
    - 책임을 수행하는데 필요한 정보를 가진 객체에게 그 책임을 할당한다
- 객체 구현을 위해 클래스 만들기
설계 하는데 있어서 여러 디자인 패턴들이 사용될 수 있음
- 예시 - strategy pattern
  - 메세지의 반환 값은 같지만 해당 반환값을 만드는 알고리즘을 교체할 수 있는 전략
  - 단리 , 복리 이자 계산 방식을 적용하고 싶을 때 유용
    - 이자를 계산한다는 것은 같지만 이자를 계산 하는 과정이 다름