[객체지향의 사실과 오해] Chapter 6

객체 지도

길을 모른다고 가정할 때, 길을 물어보는 방법 2가지 

1. 길을 직접 알려주는 방법

: 가는 경로를 단계별로 상세히 설명함 -> 기능적이고 해결책 지향적인 접근법 

2. 지도를 이용해 길을 찾는 방법 

: 지도를 기반으로 설명 -> 구조적이고 문제 지향적인 접근법 

 

지도는 범용적임 

: 원하는 '기능'에 비해 지도에 표시된 '구조'가 더 안정적이므로

 

저자가 하고싶은 말

- 전통적인 소프트웨어 개발 방법 

: 변경이 빈번히 발생하는 기능에 안정적인 구조를 종속시키는 길을 묻는 방법과 유사 

- 객체지향 개발 방법 

: 안정적인 구조에 변경이 빈번하게 발생하는 기능을 종속시키는 지도의 방법과 유사 

 

이번장에서는 

기능이 아니라 구조를 바탕으로 시스템을 분할하는 객체지향의 또 다른 측면에 관해 설명한다. 

 

안정적인 구조를 따라 역할, 책임, 협력을 구성하라

 

기능 설계 대 구조 설계

소프트웨어 제품의 설계 두 가지 측면 

- 기능 : 제품이 사용자를 위해 무엇을 할 수 있는지에 초점 

- 구조 : 제품의 형태가 어떠해야 하는지에 초점

 

설계 어려움 

왜냐면, 내일은 어떤 요구사항으로 인해 기능이 추가 or 변경될 수 있으므로 그것을 수용할 수 있는 코드를 창조해야 하므로

 

미래를 대비하는 가장 좋은 방법 

- 변경을 예측하는 것 x

- 변경을 수용할 수 있어야 함 (==구조 기반) 

 

객체지향 접근방법 

: 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배 

 

두 가지 재료 : 기능과 구조

객체지향에서 두 의미 

- 기능 : 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위 

- 구조 : 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현

 

기능을 수집하고 표현하기 위한 기법 == 유스케이스 모델링

구조를 수집하고 표현하기 위한 기법 == 도메인 모델링

안정적인 재료 : 구조

도메인 모델

소프트웨어는 사용자의 필요성을 충족 시키기 위해 존재 

사용자가 프로그램을 사용하는 대상 분야 == 도메인

대상을 단순화해서 표현 == 모델

도메인 모델 == 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태

도메인 모델 == 멘탈 모델 == 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형 

 

멘탈 모델 

- 디자인 모델

- 사용자 모델

- 시스템 이미지 

 

도메인 모델은 소프트웨어에 대한 멘탈 모델이다. 

 

도메인의 모습을 담을 수 있는 객체지향

최종 제품 == 사용자의 관점을 반영해야 함

똑같이 소프트웨어 세계에 적용하면

최종 코드 == 사용자가 도메인을 바라보는 관점을 반영해야 함 

-> 애플리케이션이 도메인 모델을 기반을 설계되어야 함

 

객체지향이 이런 요구사항을 가장 잘 만족시키는 패러다임!

왜냐면

- 도메인의 구조와 최대한 유사하게 코드 구조화 가능

- 동적인 객체가 가진 복잡성을 극복하기 위해, 정적인 타입으로 단순화 가능 

- 클래스라는 도구를 이용하여 타입을 코드 안으로 옮길 수 있음

 

표현적 차이

소프트웨어 객체와 현실 객체 사이의 관계는 은유! not 추상화

: 소프트웨어 객체는 현실 객체가 갖지 못한 특성을 가질 수도 있고 현실객체가 하지 못하는 행동을 할 수도 있음 

 

소프트웨어 객체와 현실 객체 사이의 의미적 거리 == 표현적 차이 or 의미적 차이 

 

은유를 통해 투영해야 하는 대상은 무엇?

> 사용자가 도메인에 대해 생각하는 개념, 도메인 모델

 

불안정한 기능을 담는 안정적인 도메인 모델 

도메인 모델을 기반으로 코드 작성하는 이유?

> 도메인 모델이 제공하는 구조가 상대적으로 안정적이므로 

 

도메인에 대한 사용자의 관점이 필요한 이유?

> 누구보다도 도메인의 '본질적인' 측면을 가장 잘 이해하므로

 

예제 - 정기예금 도메인 모델

> 은행 도메인 입장에서 정기예금 == 금융상품의 일종 

> 신규 계좌 개설 

> 특정한 이자율

> 이자

 

 

도메인 모델이 중요한 것은 맞지만, 사용자에게 중요한 것은 소프트웨어 기능

> 소프트웨어 기능을 기술하기 위해, 유스케이스라는 기법을 이용함 

 

불안정한 재료 : 기능 

유스케이스

시스템이 사용자에게 기능을 제공하는 이유?

> 시스템을 통해 달성하고자 하는 '목표'가 존재하므로 

 

훌륭한 기능적 요구사항을 얻기 위해서는?

> 시스템 간의 '상호작용' 관점에서 시스템을 바라보아야 함

 

사용자와 시스템 간에 이뤄지는 상호작용 흐름 == 유스케이스 

서비스 중에 하나를 요청하는 이해관계자 == 일차 액터

 

유스케이스의 가치

- 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있음 

 

예시 - 정기예금 이자 계산 유스케이스

 

유스케이스 명 : 중도 해지 이자액을 계산한다.

일차 액터 : 예금주

 

주요 성공 시나리오

1. 예금주가 정기예금 계좌를 선택한다.

2. 시스템은 정기예금 계좌 정보를 보여준다.

3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.

4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공한다.

 

유스케이스의 특성

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'이다.

 

2. 유스케이스는 하나의 시나리오가 아니라 여러 시나리오의 집합이다. 

> 이자 계산 유스케이스는 2가지 시나리오를 합침 

- 예금주가 계좌를 선택하고 당일까지의 이자액을 계산함

- 예금주가 계좌를 선택하고 특정 일자까지의 이자액을 계산함

 

3. 유스케이스는 단순한 피처 목록과 다르다. 

> 피처는 단순히 목록 나열이지만 유스케이스는 하나의 이야기로 묶어줌 

 

4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.

> 사용자 인터페이스 요소는 배제하고 사용자 관점에서 시스템 행위에 초점! 

> 이를 본질적인 유스케이스

 

5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다. 

> 시스템의 기능을 이야기 형식으로 모으는 것임 

> 내부 설계 설명이 아님 

 

유스케이스는 설계 기법도, 객체지향 기법도 아니다.

> 내부 구조를 유추할 수 있는 방법은 존재하지 않음

 

유스케이스와 객체 구조 사이에 커다란 간격 존재함

> 간격을 없애는 방법은 없음 

> 힌트는 얻을 수 있음 

> 모든 정보가 있다는 착각은 하지마라

 

 

재료합치기 : 기능과 구조의 통합

도메인 모델, 유스케이스, 그리고 책임-주도 설계

유스케이스에 정리된 시스템의 기능 -> 도메인 모델을 기반으로 한 객체들의 책임으로 분배 

 

시스템에 할당된 커다란 책임 -> 작은 규모의 객체들의 책임으로 분배 

어떤 객체를 선택해야 하는가?

> 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 함

 

유스케이스 역할

> 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체간의 안정적인 구조에 책임을 분배할 수 있는 

출발점을 제공함

 

책임-주도 설계 방법

> 유스케이스와 도메인 모델을 통합함 

 

도메인 모델에 명시된 정기예금이나 계좌도 스스로 상태와 행위를 관리하는 자율적인 객체가 됨

 

객체의 이름 == 도메인 모델에 포함된 개념으로부터 차용

책임 == 도메인 모델에 정의한 개념의 정의에 부합

 

기능 변경을 흡수하는 안정적인 구조 

도메인 모델이 안정적인 이유?

> 정기예금, 계좌, 이자율, 이자란 개념은 안정적으로 유지되는 개념 

> 도메인 모델에서의 개념 간의 관계는 비즈니스 규칙을 기반으로 하므로 안정적으로 유지 됨 

ex) 계좌와 이자 간의 0..1관계 

 

예제 - 이자 계산 기능의 변경 

복리를 추가한다고 했을 때,

도메인 기반으로 하면 크게 구조가 바뀌지 않음

 

객체지향의 큰 장점 

> 도메인을 모델링하는 기법과 도메인을 프로그래밍 하기 위해 사용하는 기법이 동일 

 

모델링에서 사용한 객체 -> 개념을 부드럽게 프로그래밍 설계에서의 객체와 클래스로 변환 가능 

이를, 연결완전성이라고 함 

 

 역방향도 가능함 

> 코드에서 모델로의 부드러운 흐름을 의미하는 것, 가역성

 

 

위와 같이 사람들은 코드로부터 도메인 모델을 유추할 수 있게 됨