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

객체 지도

이번 장은 좀 어려웠다. 사실 컴퓨터 전공이 아니라 보안 전공이라 유스 케이스 같은 전공을 들을 기회가 없어서인지, 배우는 게 많았지만 시간이 오래 걸렸다. 그래도 두세 번 읽으니깐 이해할 수 있었다.

구조적 설계를 해야한다.

• 객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다.
• 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.
• 설계의 가장 큰 도전은 기능과 구조라는 측면을 함께 녹여 조화를 이루도록 만드는 것
• 훌륭한 구조 -> 훌룡한 기능 -> 훌룡한 소프트웨어
• 요구사항은 늘 변경되기 때문에 안정적인 구조를 제공하는 능력을 갖추어야 한다.
• 훌륭한 설계 = 안정적인 구조를 중심으로 설계
• 길을 묻지 마라, 객체를 이용해 지도를 만들어라 자연스럽게 흘러갈 것이다.

기능과 구조

객체 지향 세계를 구축하기 위해서는 사용자에게 제공할 '기능'과 기능을 담을 안정적인 '구조'라는 재료가 준비되어있어야 한다. 구조는 시스템의 기능을 구현하기 위한 기반으로 기능 변경을 수용할 수 있을 정도로 안정적이 여야 한다.

기능을 수집하기 위한 기법 : 유스 케이스 모델링
구조를 수집하고 표현하기 위한 기법 : 도메인 모델링

도메인 모델 : 구조를 수집하자

사용자가 사용하는 대상 분야를 도메인이라고 한다.

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

도메인 모델은 그저 멘털 모델. 사람들이 어떤 현상을 이해하기 위해 마음속에 구축하는... 모델

 

예를 들면, 사다리는 선으로 이루어지고 , 선은 점으로 이루어진다.

 

도메인 모델과 유사한 모델링을 사용할수록 소프트웨어 개발이 쉬워질 것이다.

객체지향으로 사용자들이 이해하고 있는 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.

객체 지향의 클래스로 타입을 표현하고, 정적인 타입을 이용해 세상을 단순화시킨다.

우리는 은유를 통해 , 도메인에 대해 생각하는 개념들을 투영해야 한다.

 

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

도메인 속 개념과 관계가 코드 속에 녹아 있기에 도메인이 알려주는 길을 따르면 길을 잃지 않는다

(이 말에 백번 공감한다,  나도 막혔을 때 , 정말 기본적인 상식으로 다가가는 경우가 많다)

 

도메인이 안정적인 것 이기 때문에 ( 사람들이 일반적으로 생각하는 개념 과로직) 이를 반영해 불안정한 재료들을 가지고 소프트웨어를 설계하고 구현할 수 있다.

 

불안정한 재료 : 기능을 수집하자

 

 

 

 

어쨌든 소프트웨어는 사용자의 목표에 맞추어 기능을 제공해주면 된다.

여러 기능을 요청하고 요청받고의 과정을 잘 정리한 것이 유스케이스이다.유스 케이스의 가치는 사용자들이 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있단 점이다.

유스케이스

 

 

 

 

사용자와 시스템 간의 상호작용을 일련의 이야기로 얘기한다. 하나의 시나리오가 아니라 여러 시나리오들의 집합이다. 단순 수행 목록을 나열한 것이 아니라, 피처들의 이야기를 묶어 제공한다. 어떻게 뭘 선택해서 정보를 보고, 이런 세부 정보, 내부 설계를 포함하지 말아야 한다.

 

유스 케이스가 단지 사용자가 바라보는 시스템의 외부 관점만을 주목한다.

 

그래서 유스 케이스랑 객체 지향이랑 무슨 상관인데? : 둘이 잇는 건 창조적인 작업이다.

 

유스 케이스

 

 

 

 와 도메인이 합쳐진다면?

도메인 모델은 안정적인 구조를 개념화시키고 유스 케이스는 불안정한 기능을 서술하기 위함.

 

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

 

일단 유스 케이스에 쓰인 기능을 책임으로 보고 도메인의 객체들에게 할당해준다.

 

물론 꼭 필요한 건 아니지만 , 견고한 객체지향을 위하여 사용자의 관점에서 시스템의 기능을 명시하고 사용자와 설계자가 공유하는 안정적인 구조(도메인의 멘털 개념)를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다.

 

도메인 개념을 도입하는 이유는, 도메인은 사람들이 대부분 생각하는 형상이기에 변하지 않는 경우가 많다.= 연결 완정 성 코드의 변경으로부터 도메인 변경 사항을 유출할 수도 있다. 수정이 곧 모델의 수정. 모델의 수정이 코드의 수정, 모델과 코드는 별개가 아니다.

 

안정적인 도메인 모델을 기반으로 기능을 구현하라.