상태도는 객체 설계의 꽃이다
어떻게 하면 모델링을 잘할 수 있을까?
설계를 배우는 동료들과 화상 미팅을 하면서 우발적으로 이런 말을 했습니다. 맞는 말일까요?
상태도는 객체 설계의 꽃이다!
상태도는 객체 설계의 꽃이다?
'상태도'로 찾아보니 이미 제가 쓴 글이 많습니다. 사실 제 발언은 어찌 보면 3년 전에 쓴 <시스템의 상태와 상태도 작성>을 한 문장으로 줄인 것이라고 할 수 있습니다. 그 이야기를 재방송처럼 늘어놓는 대신에 조금 다른 관점으로 풀어 보겠습니다. 마침 링크드인에서 발견한 외국인 개발자의 글이 재료가 되어 줄 듯합니다.
그의 글은 상태 머신을 다루면서 'Because Boolean flags make a mess'를 부제이자 사례로 들고 있습니다. 다음 문장이 나쁜 코드 혹은 냄새나는 코드라는 주장이죠. 과연 그럴까요?
isSlideshow = true
상태는 객체의 위력의 핵심이다
그의 설명 자료를 보면 영문으로 쓴 다섯 가지 비즈니스 로직(혹은 규칙)을 표현할 때, Booleans flags(이진 속성)를 쓰면 다섯 가지 종류의 상태를 혼용해야 합니다. 사실 관계형 데이터베이스로 설계를 하는 경우 흔히 볼 수 있는 모습이죠. 이렇게 되면 코드는 DBMS Transaction을 다루는 스크립트(일회성 코드)에 지나지 않게 되죠.
이를 극복하려면 비즈니스 규칙을 내포한 진정한 객체[1]로 발전해야 합니다. 그게 뭘까요? 일단 개념적으로 나아가기 전에 실질적인 불편함이 뭔가 더 살펴보겠습니다. 저자는 문제를 다음과 같이 요약합니다.
32에 대해 따로 설명이 없어서 제 추측을 구글에서 입력을 해 보니 조합의 경우의 수를 뜻하는 듯합니다. 그런데, 그중에 27 가지는 도달해서는 안 되는 상황인 것이죠. 다시 말해서 다섯 개의 상태가 선후관계를 지닌다는 말입니다. 그러니 if 구문의 조건절 순서를 실수하면 오류가 나는 것이죠.
그럼 대책이 있을까요? 바로 객체가 더 나은 코드를 만들 수 있습니다.
상태 머신은 객체의 코어
저자는 객체란 말 대신에 상태 머신State Machine이라고 표현하며, 다섯 개의 상태가 연관성을 지니도록 묶었습니다. 하나의 컬럼으로 말이죠.
그리고 그 의미를 사람이 읽을 수 있는 값으로 변형한 후에 다음과 같이 그릴 수 있다고 합니다. 그리하면 불필요한 상태를 제거할 수 있고 오류 가능성도 대폭 줄이게 되죠. 더불어 32개 가능 상태 중에 27개를 피해야 하는 고민이 필요 없죠. 가능 상태가 고작 5개뿐이니까요.
하지만, 바로 저 경로를 개발자가 정의해야 합니다. 그림으로 하든 표로 하든 코드로 하든 말이죠. 중요한 설계 요소라고 할 수 있죠.
일면식도 없는 외국인이 쓴 글이지만, 저자는 아마 저랑 견해가 비슷할 듯합니다. 상태도가 설계의 꽃이란 의견에 대해서 말이죠. 다만, 그가 객체나 객체 지향이란 단어를 쓰지는 않았으니 취향이나 견해가 다른 부분은 있을 듯도 합니다.
주석
[1] 마틴 파울러가 말한 Anemic Domain Model(무늬만 객체)의 반대말로 쓴 것입니다.
지난 어떻게 하면 모델링을 잘할 수 있을까? 연재
3. 모델링을 Actor로 시작한다는 의미는 무엇인가?
5. 사고와 인식과 표현의 주체인 임자로 욕망을 바라보기
6. 모델을 그리기 전에 '생각의 종이'부터 준비하세요
7. 순차도로 사태를 하나씩 것과 곳과 쪽으로 차려내기
8. 객체 모델링에서 메시지 그리고 Collaboration
