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

지도는 변경될수 있는 세세한 건물의 이름, 마트 정보등을 나타내는 것이 아닌 잘 변하지 않는 안정적인 지형 정보를 기반으로 되어있다. 그렇기에 지도는 예전부터 많이 변한것이 없고, 우리는 이 지도를 통해서 목적지까지 어렵지 않게 갈수 있다. 지도는 안정적인 지형 정보를 기반으로 만들었기에 예전 지도가 지금까지도 사용이 가능한 것이다.

시간이 지나면 아이스크림 가게가 신발가게로 금방 변하고, 건물이 사라지기도 한다. 그러나 지형정보는 잘변하지 않는다. SW도 사용자의 요구사항은 안타깝게도 자주 변한다. 그렇기에 요구사항에 맞춰서 설계를 하면 금방 설계를 뒤엎어야 할것이다.(바뀔 수도 있기에, 아니 무조건 바뀐다.) 우리는 지도와 마찬가지로 구조를 중심으로 먼저 설계하고 그 위에 기능을 넣어야한다. 그러면 사용자의 요구사항이 변경되어도 변경의 범위가 적을 것이다.

기능 설계 vs 구조 설계

• SW에는 기능, 구조 두가지 측면이 존재한다.

기능은 '무엇을 할수 있는 지', 구조는 '제품의 형태가 어떠해야 하는 지'

사용자의 요구사항의 기능을 만드는 것은 당연히 중요하다. 이는 사용자의 목표이기에
그러나 좋은 소프트웨어의 특징은 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할수 있다이다.

요구사항이 변하지 않는다면 생각할 필요가없다. 그러나 SW에 대한 사용자의 요구사항은 항상, 무조건, 필연적으로 바뀐다.

그렇기에 우리는 예측할수 없는 요구사항 변경에 유연하게 대처할수 있는 안정적인 구조를 제공하는 능력을 가지고 있어야한다.

미래를 예측할순 없다. 단지 우리는 변경을 수용할 수 있는 선택의 여지를 미리 설계에 마련해 놓아야한다.

좋은 설계란, 나중에라도 변경할수 있는 변경의 여지를 남겨놓는 것.

• 변경의 여지를 남겨놓는 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것이다.

안정적인 구조를 중심으로 설계하고, 그 위에 시스템의 기능을 객체간의 책임으로 분배해야한다. 이러면 기능이 변경되더라도, 객체간의 구조는 그대로 변함이 없다. 이는 요구사항이 변경되었다 해도 코드의 변경의 범위가 적기에 변경에 유리한 유연한 코드를 설계할수 있다.

객체도 지도와 같이 구조를 중심 바탕으로 객체들에게 책임을 분배해야한다. 이는 요구사항이 변해도 요동치지않는 튼튼한 설계를 돕는다.

구조

도메인 모델

도메인 : 사용자가 프로그램을 사용하는 대상 분야를 의미한다. 사용자가 롤을 하면 애쉬, 카밀, 등의 캐릭터와 블루, 레드인 모스터 그리고 cs를 먹으면 떨어지는 골드등이다.
모델 : '추상화'의 의미이다. 복잡한걸 간단하게 본다는 의미이다

즉, 도메인 모델이란 사용자가 프로그램을 사용하는 대상을 단순화해서 본 형태를 의미한다.

도메인 모델은 다이어그램이 아닌 멘탈 모델이다.

멘탈 모델이란 사람들이 머릿속으로 생각하는 모델을 의미한다. 햄버거를 보면 사람마다 각자만의 모델로 보는데, 햄버거를 싫어하면 역겹게 보일수도있고 좋아하면 맛있는 음식으로 보일수도 있다.

즉, 도메인 모델은 사람마다 마음속에 가지고 있는 멘탈모델이다.

이 멘탈모델은 세가지로 나눌수 있다.

1. 사용자 모델 : 사용자가 보는 멘탈 모델
2. 디자인 모델 : 개발자가 보는 멘탈 모델
3. 시스템 이미지 : 최종시스템의 멘탈모델(최종 소프트웨어)

개발을 하는 도중 사용자가 간섭할수 없기에 우리는 시스템이미지(최종 소프트웨어)가 사용자 모델과 비슷하게 만들려 노력해야한다.

즉, 도메인 모델은 사용자가 바라보는 관점에 맞게 반영해야한다.

우리는 도메인모델(멘탈모델)의 세가지 모델을 모두 유사한 모습으로 만들도록 해야한다.

표현적 차이

소프트웨어 객체는 현실 객체를 은유한 것이다.(모방한게 아닌 은유한것)

소프트웨어 객체는 현실객체가 할수 없는 할수도 있다.

표현적 차이란 소프트웨어 객체와 현실 객체의 의미적 거리를 의미한다.
우리는 은유를 통해서 표현적 차이를 줄이려 노력해야한다.

어떻게 차이를 줄일까?
바로, 사용자가 도메인에 대해 생각하는 개념을 통해서 실제 소프트웨어 객체와의 차이를 줄여야한다. 이게 핵심이다.
즉, 우리는 도메인 모델을 통해서 표현적 차이(의미적 차이)를 줄여야한다.

사용자 멘탈 모델이 코드 그대로 스며들게 해야한다. 그래야 사용자가 도메인을 바라보는 관점 그대로 소프트웨어에 투영할수 있다. 어떻게? 바로 도메인모델을 통해서 소프트웨어를 설계하면 된다!

안정적인 도메인 모델

도메인 모델은 안정적이다.
도메인 모델은 사용자가 도메인을 바라보는 관점을 반영해서 소프트웨어를 설계하고 구현하는 것이다.

도메인은 사용자 모델을 반영한 것이기에 잘 변하지 않는다.
사용자가 바라보는 규칙, 관계는 잘변하지 않기 때문이다.

이러한 안정적인 도메인 모델을 구조로써 소프트웨어를 설계하면 변경에 유연하게 대응할수 있다.

기능

유스케이스

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

• 유스케이스에는 단지 사용자가 시스템을 통해 무엇을 얻을수 있는지, 어떻게 상호작용할수 있는지에 대한 정보만 기술된다.

구조와 기능 통합

불안정한 기능을 안정적인 구조에 담음으로써 요구사항의 변경에 대한 파급 효과를 줄일수 있다. 이는 객체지향 설계자의 기본 설계 능력이다.

그렇다면 둘을 합쳐보자.

1. 유스케이스의 한 기능을 구현하기 위해 사용자가 상호작용하는 시스템 전체를 하나의 객체로 본다. 즉, 기능을 하나의 객체의 책임으로 본것이다.
2. 시스템이라는 하나의 객체가 가지고있는 책임을 더 작은 객체들에게 분배해야한다. 이때, 도메인 모델을 토대로 객체들에 책임을 분배한다.

책임 주도 설계(RDD)관점에서 보자
유스케이스로부터 첫번째 메시지를 시스템이라는 객체가 받는다.
시스템이라는 객체는 다른 객체의 도움이 필요하기에 해당 책임을 수행할수 있는 더 작은 객체에게 메시지를 요청한다.
더 작은 객체는 메시지 요청을 받고 책임을 수행하고 도움이 필요하면 다른 객체에게 메시지를 요청한다...
...

중요한건
도메인 모델이라는 구조를 중심으로 객체들에게 책임을 분배함으로써 안정적인 구조를 기반으로 책임을 할당한다는 것이다.

객체지향의 장점

안정적인 도메인 모델을 기반으로 구조를 설계하면 기능이 변경될시, 유연하게 코드 변경이 가능하다는 것을 알았다.

객체지향에는 도메인 모델과 관련된 두가지 장점이있다.

1. 도메인 모델 -> 코드로 변경이 매끄럽다. (연결 완전성)
2. 코드 -> 도메인 모델로 변경이 매끄럽다. (가역성)

객체지향은 도메인을 모델하는 기법과 도메인을 프로그래밍하는 기법이 동일하기에 두가지 장점이 존재한다.

도메인 모델은 사람들의 멘탈모델이다. 도메인 모델이라는 다이어그램에 만드는것에 집중할필요가 없다.
우리는 도메인 모델과 프로그래밍 코드를 밀접하게 연관시킨다면 코드를 보고 도메인 모델을 떠올릴 것이고, 도메인 모델을 보고 코드를 떠올릴수 있을 것이다.

객체지향의 견고한 설계를 위해선 도메인 모델과 코드를 밀접하게 연관시키려 노력하라. 이것은 변경에 유연한 객체지향 시스템을 만드는 첫걸음이 될수 있다.