Ch6. 객체 지도

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.

여행 중에 길을 모르면

1. 지나가는 사람에게 묻는다. (길을 찾는 기능을 통해 해결)
2. 지도를 보고 찾아간다. (길을 찾아주는 구체적 기능이 아닌 길을 찾을 수 있는 구조를 통해 해결)

여기까진 뭐지..? 했음

기능 설계 대 구조 설계

기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다. 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.

성공적인 소프트웨어들이 지닌 공통적인 특징은 훌륭한 기능을 제공하는 동시에 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있다는 것이다.

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.

두 가지 재료: 기능과 구조

안정적인 재료: 구조

도메인 모델

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

도메인 모델: 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점, 이해관계자들이 바라보는 멘탈 모델(Mental Model)

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

도메인 모델이란 사용자들이 도메인을 바라보는 관점이며, 설계자가 시스템의 구조를 바라보는 관점인 동시에 소프트웨어 안에 구현된 코드의 모습 그 자체

도메인 모델의 세 가지 측면을 모두 모델링할 수 있는 유사한 모델링 페러다임을 사용할수록 소프트웨어 개발이 쉬워질 것

객체지향은 이런 요구사항을 만족시킬 수 있는 거의 유일한 모델링 패러다임

표현적 차이

소프트웨어 객체는 현실 객체에 대한 추상화가 아니다. 현실 객체를 모방한 것이 아니라 은유를 기반으로 재창조한 것이다.

이처럼 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 표현적 차이 또는 의미적 차이라고 한다.

핵심은 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것

우리가 은유를 통해 투영해야 하는 대상은 무엇인가? 사용자가 도메인에 대해 생각하는 개념들이다.

도메인 모델을 기반으로 설계하고 구현하는 것은 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있게 한다. 결과적으로 표현적 차이는 줄어들 것이며, 사용자의 멘탈 모델이 그대로 코드에 녹아 스며들게 될 것이다.

코드의 구조가 도메인의 구조를 반영하기 때문에 도메인을 이해하면 코드를 이해하기가 훨씬 수월해진다.

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

사용자들은 도메인의 ‘본질적인' 측면을 가장 잘 이해하고 있다. 본질적이라는 것은 변경이 적고 그 특성이 오랜 시간 유지된다는 것을 의미한다.

불안정한 재료: 기능

유스케이스

사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것

유스케이스의 특성

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 ‘텍스트'다. ‘다이어그램'이 아니다.
2. 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
   1. 예금 이자를 계산하고 사용자에게 보여주는 유스케이스는 2개 시나리오로 구성됨
3. 유스케이스는 단순한 피처(Feature) 목록과 다르다.
   1. 예금이자를 계산한다. 예금 정보를 보여준다. 2개의 피처를 보면 서로 관계없는 기능처럼 보이지만 유스케이스로 작성한다면 다르다.
4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
5. 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스에서 객체 설계로의 전환은 공항적인 규칙과 원칙을 기반으로 한 변환 작업이 아니라 경험과 상식과 의사소통을 기반으로 한 창조 작업이다.

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

불안정한 기능을 안정적인 구조 안에 담음으로써 변경에 대한 파급효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야 할 기본적인 설계 능력이다.

변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다.

객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 점이다. → 완전연결성

객체지향에서는 도메인 모델과 코드 모두 동일한 모델링 패러다임을 공유하기 때문에 코드의 수정이 곧 모델의 수정이 된다.