객체지향의 사실과 오해 - 기능과 구조

- 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.)

- 문제를 접근하는 두 가지 방법

낯선 여행지에서 목적지를 찾아가는 방법에는 여러 가지가 있다. 어떤 사람은 모르는 사람에게 길을 묻고, 어떤 사람은 지도를 보고 목적지를 찾아간다.

 

모르는 사람에게 길을 물으면서 찾아가는 해결법은 '기능적이고 해결책 지향적인 접근법(functional, solution-directed approach)' 라고 할 수 있다. 가령 '길을 따라 얼마쯤 가다가 어떤 랜드마크가 보이면 다른길로 가세요'와 같은 식이다.

반면 지도를 이용하는 방법은 '구조적이고 문제 지향적인 접근법(structural, problem-directed approach)' 이다. 지도는 실제 지형을 기반으로 하여 여러 가지 정보가 함축되어 있는 추상적인 모델이다. 길을 찾을 수 있는 구조를 제공한다.

 

길을 묻는 방법은 그 시점에 해당 질문에 대한 요구사항만 만족할 수 있지만 지도를 이용하면 다른곳을 찾아가는 요구사항도 만족할 수 있다. 또한 지도가 아주 오래 되지 않은 이상은 일정 기간동안 목적지를 찾는 요구사항을 만족시킬 수 있기 때문에 수명도 더 길다고 할 수 있다.

 

이 은유의 핵심은 자주 변경될 수 있는 기능이 아니라 구조를 바탕으로 시스템을 구성하라는것이다.

---

- 기능 설계 vs 구조 설계

소프트웨어 설계는 두 가지 측면이 있는데 하나는 기능 이고 다른 하나는 구조 이다. 기능 측면은 제품이 사용자에게 어떤 기능을 제공할 수 있는가에 초점을 맞추며 구조 측면은 제품의 형태가 어떠해야 하는가에 초점을 맞춘다.

 

소프트웨어의 1차 목표는 사용자가 필요한 기능을 제공하는것이다. 이 목표만 달성해도 사용자 입장에서는 소프트웨어를 사용하는데에 아무런 지장이 없다. 그럼에도 구조적인 측면을 고려해야 하는 이유는 요구사항이 변하기 때문이다.

 

소프트웨어의 구조적인 설계가 제대로 되어있지 않으면 변화하는 요구사항을 민첩하게 대응하기 힘들다. 기능은 서로 연관되며 구조를 전혀 생각하지 않으면 하나의 기능 변경에 대해 다른 연관된 기능이 어떻게 영향을 받는지도 파악하지 못한채 변화하는 요구사항에 점점 대응하기 힘들어진다.

 

좋은 설계는 미래를 예측하여 설계하는 것이 아니라 대비하여 설계하는것이다. 미래를 지나치게 예측하여 설계하면 오버 엔지니어링이 되며 실제로 그 예측이 맞아 떨어지지 않을 수 있다. 단지 미래의 변경에 대비 하면서 예측을 겸허히 받아들이면 되는것이다.

---

- 기능과 구조

객체지향을 구축하기 위해서는 기능과 구조를 수집해야 한다. 앞에서 구조는 마치 좋은것이고 기능은 안 좋은것이라는 늬앙스로 설명했지만 사실 시스템을 구축하기 위해서는 기능과 구조 모두 잘 수집이 되어야 한다.

 

'구조'는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념 및 개념간의 관계로 표현된다. 반면 '기능'은 사용자의 목표를 만족시키기 위한 시스템의 행위이다.

 

기능을 수집하여 표현하는것은 유스케이스 모델링이며 구조를 수집하고 표현하는것을 도메인 모델링이다.