[객체지향의 사실과 오해] 6장: 객체 지도

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

---

경로가 아닌 지도를 만들어라

어떤 사람이 A라는 마을로 이동하려고 하는데, 길을 모른다고 가정해보자.

 

지나가던 다른 사람에게 A라는 마을로 어떻게 가냐고 묻자, "저기서 오른쪽으로 가서, 200m정도 앞으로 간 뒤 ..." 라고 답한다.

 

결국 경로를 알려준 은인덕분에 A라는 마을에 도달할 수 있었다.

 

이것은 기능적이고 해결책 지향적인 접근법이다. 

A라는 마을에 도달하기 위한 해결책, 즉 기능만 제공한다.

 

반면 지도를 사용하는 경우는 어떨까?

 

A 라는 마을 뿐만 아니라, B, C 라는 마을의 정보까지도 한 눈에 확인할 수 있다.

또한 추상화가 적절히 이루어졌기에 경로를 쉽게 파악할 수 있다.

 

지도는 구조적이고 문제 지향적인 접근법이다.

지도는 A 라는 마을로 가는 경로 뿐만 아니라 다른 경로도 제공한다. 즉, 다른 요구사항도 수용할 수 있다.

 

이처럼 구조에 기반한 모델은 안정적이다.

A라는 마을로 가는 경로를 안다고 하더라도, B라는 마을로 갈 수 있을까?

반면 지형은 거의 변하지 않는다. 대규모 재개발이라도 일어나지 않는 한 지도(구조)는 유효하다.

---

객체지향도 결국 구조를 따라야 한다

구조에 기능을 종속시키는 것이 좋은 객체지향 설계의 핵심 원리다.

요구사항은 변한다. 기능도 변한다. 하지만 구조는 쉽게 변하지 않는다.

 

자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라. 

 

그렇다고 해서 기능이 중요하지 않은 것이 아니다.

사용자가 원하는 것은 기능이다. 그렇기에 기능도 중요하다.

반면 구조는 좋은 소프트웨어를 위한 필요조건이다.

 

따라서 기능과 구조가 적절히 조화되는 것이 설계의 가장 큰 도전이 된다.

 

요구사항이 변경되지 않는다면(A라는 마을만 간다면) 구조(지도)는 필요 없었을 것이다.

하지만 모든 것은 변하기에, 결국 우리는 좋은 구조를 찾아 기능을 접목시켜야 한다.

 

객체 지도를 만들어라. 그러면 기능은 지도에 표시된 길을 따라 자연스럽게 흘러갈 것이다.

---

두 가지 재료: 기능과 구조

좋은 객체지향 설계에는 좋은 구조, 그리고 구조를 따르는 기능이 필요하다.

이 두 가지 재료를 어디서 구할까?

 

일반적인 방법은, 

1. 구조의 경우, 도메인 모델
2. 기능의 경우, 유스케이스 모델

에서 가져오는 것이다.

---

도메인 모델

도메인 모델이란 무엇일까?

 

소프트웨어가 존재하는 이유부터 생각해보자.

소프트웨어는 특정 문제 영역을 다루기 위해 사용된다.

 

계좌 관리 어플리케이션의 목적은 '은행의 계좌 관리 업무를 보조하는 것'이다.

 

이렇게 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.

 

그렇다면 도메인 모델이란 무엇일까?

사용자가 도메인을 바라보는 관점이자 설계자가 시스템의 구조를 바라보는 관점이다.

 

도메인 모델은 쉽게 변하지 않는다. 

하루아침에 은행의 계좌 관리 프로세스가 통째로 변경되는 일이 있을까?

 

아마 어떤 계좌를 관리할지 등 사소한 변경은 존재할 수 있을 것이다. 

그러나 이것은 구조를 통째로 뒤흔들지는 않는다.

 

이것이 도메인 모델을 구조로 따라야 하는 이유다.

우리가 해결하고자 하는 문제영역의 가장 안정적인 구조이자, 사용자들이 바라보는 도메인의 모습이다.

 

---

유스케이스

이제 구조에 기능을 담을 차례다.

 

기능은 어디서 가져와야 할까? 바로 유스케이스다.

유스케이스란, 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 의미한다.

 

정기예금 이자 계산의 경우, 다음과 같은 유스케이스가 존재할 수 있다.

 

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

1. 예금주가 정기예금 계좌를 선택한다.
2. 시스템은 정기예금 계좌 정보를 보여준다.
3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.
4. ...

 

유스케이스의 가치는 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점이다.

사용자 목표라는 문맥을 제공함으로써 각 기능이 유기적인 관계를 지닌 체계를 이루도록 한다.

 

유스케이스는 단순히 기능을 나열하는 것이 아니다.

다음은 유스케이스의 특징을 나타낸다.

1. 유스케이스는 텍스트다. 이야기 흐름이다.
2. 유스케이스는 여러 시나리오의 집합이다.
3. 유스케이스는 기능 목록과 다르다. 독립적인 기능을 나타내지 않는다.
4. 유스케이스는 사용자 인터페이스와 관련된 정보를 포함해서는 안된다.
5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

---

구조와 기능의 통합

어떤 문제 해결영역이 존재하면,

1. 문제를 시스템의 책임으로 정의한다.
2. 시스템의 책임은 객체들의 책임으로 나뉜다. 이때 객체가 선택되는 기준이 도메인 모델이다.
3. 객체들에게 기능을 부여하는 기준이 유스케이스 모델이다.

이처럼 구조와 기능이 통합되었을 때, 좋은 객체지향 설계가 가능해진다.