객체지향의 사실과 오해(6-1)

객체 지도

길을 찾기위한 두가지 방법.

 

• 1. 다른 사람에게 길을 물어보는 방법 - 해결 방법 지향적인 접근법
• 2. 지도를 이용하는 방법 - 문제 지향적인 접근법

길을 묻는 방법은 A -> B로 이동하는 현재의 요구만 만족시킬 수 있는 반면에 지도는 현재의 목적뿐만 아니라 다양한 목적을 위해 재사용될 수 있다. 이처럼 지도가 범용적인 이유는 지도를 이용하려는 사람들이 원하는 '기능'에 비해 지도에 표시된 '구조'가 더 안정적이기 때문이다. 

 

이번장에서는 기능이 아니라 구조를 바탕으로 시스템을 분할하는 객체지향의 또 다른 측면에 관해 설명한다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하는 객체지향적인 접근법을 살펴보도록 하자.

 

기능 설계 vs 구조 설계

훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분조건이라고 한다면 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요조건이다. 비록 사용자들이 소프트웨어의 내부 구조를 볼 수는 없지만 깔끔하고 단순하며 유지보수하기 쉬운 설계는 사용자의 변하는 요구사항을 반영할 수 있도록 쉽게 확장 가능한 소프트웨어를 창조할 수 있는 기반이 된다.

 

개발자의 삶이 고단하면서 흥미로운 이유는 요구사항이 예측 불가능하게 변경되기 때문이다. 설계자는 훌륭한 기능을 제공하는 동시에 예측 불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야 한다.

 

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다. 지도 은유를 통해 살펴본 것처럼 변경에 대비하고 변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것이다. 

 

기능에 초점을 맞춘 설계 방식은 기능을 분해하고 각 기능들이 서로 밀접하게 관련된 하나의 덩어리를 이루기 때문에 기능이 변경될 경우 기능의 축을 따라 설계된 소프트웨어가 전체적으로 요동치게 된다. 이에 구조에 초점을 맞춘 설계는 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다. 객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다. 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

 

안정적인 재료 : 구조

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

 

소프트웨어의 객체는 현실 객체를 단순히 모방하는 것이 아닌 은유를 기반으로 재창조하는 것이다. 따라서 대상이 현실적인지, 현실적이지 않은지에 상관없이 도메인 모델을 통해 표현되는 도메인 객체를 은유해야 한다.

도메인 모델를 토대로 객체를 은유한다면 첫째로, 도메인 모델을 기반으로 설계하고 구현하는 것은 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있어 현실 객체와 소프트웨어 객체 사이의 차이를 줄일 수 있다. 이는 개발자가 도메인만 이해하면 코드 이해와 코드 수정은 저절로 따라오게 될 것을 의미한다. 다시 말해, 도메인 속의 개념과 관계가 바로 코드 속에 녹아 있기 때문에 도메인이 알려주는 길을 따라가면 코드 속에서 길을 잃지 않을 수 있는 지도를 제공하는 것과 같다. 곧 도메인 모델은 기능을 구현할 때 참조할 수 있는 궁금적인 지도인 셈이다.

 

두번째 장점은 도메인 모델이 제공하는 구조가 상대적으로 안정적이기 때문에 요구사항 변경 시 비교적 쉽게 대응할 수 있다는 것이다.  우리는 변화에 대응해야 하는데 도메인 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 도메인 모델을 기반으로 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.

 

불안정한 재료 : 기능

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

 

유스케이스는 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다. 외부에 제공하는 행위만 표현하기 때문에 유스케이스로부터 시스템 내부의 구조를 유추할 수 있는 방법은 없으며 객체지향과도 상관이 없다. 개발자가 요구사항을 기억하고 관리하는 필요한 다양한 정신적 과부화를 줄여주며 설계에 대한 영감을 불러일으킬 수 있는 약간의 힌트만이 들어 있을 뿐이다.