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

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

- 도메인 모델, 유스케이스 그리고 책임-주도 설계

시스템이라는 것은 사용자가 첫번째로 만나게 되는 객체이다. 사용자 입장에서 시스템은 자신과의 협력에서 자신의 요청을 처리하는 하나의 객체로 볼 수 있다. 시스템은 자신안에 더 작은 객체들을 갖고 있으며, 사용자로부터 받은 책임을 더 작은 객체들로 적절하게 분배해야 한다.

 

여기에서 책임-주도 설계가 등장한다. 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 볼 수 있게 한다. 즉 사용자로 부터 처음으로 메시지를 수신하는 출발점의 역할을 한다. 그 이후에는 시스템이 안정적인 도메인 모델에 기반하여 기능을 수용하고 객체들로 책임을 분배한다.

 

이자 계산 기능을 구현하는 예제를 통해 책임-주도 설계를 알아보자. 지난 번에 작성한 아래 유스케이스의 3, 4 번 기능을 소프트웨어 기능으로 구현해보자.

 

 

사용자가 '중도 해지 이자액을 계산하라.' 는 기능을 요청할 때, 시스템이라는 객체가 우선 해당 메시지를 수신받을것이다. 메시지를 수신받은 시스템은 책임-주도 설계에 의하여 더 작은 객체들로 어떤 메시지를 그리고 어떤 객체에게 할당할 지를 결정할것이다.

 

 

위는 도메인 객체들의 협력 다이어그램이다. 전체적인 흐름은 해지일자와 함께 이자 계산을 요청하는 것이다. 기간을 체크한 후 계좌가 이자율에게 요청할 때에는 해지일자와 더불어 예금액이 얼마인지를 알아야 하므로 예금액까지 이자율에 전달한다. 그리고 최종적으로 이자를 생성한다.

 

이제 책임(메시지)을 메소드로, 역할(객체)들을 클래스로 변환해서 클래스 다이어그램을 생성해보자.

 

 

도메인 객체들의 협력 다이어그램과 거의 비슷하다. 정기 예금(TimeDeposit) 은 계좌(Account) 에게 특정 일자에 해지시 이자액 계산을 요청한다. 계좌(Account) 는 이자율(InterestRate) 에게 정기 예금(TimeDeposit) 으로 부터 전달받은 해지일자와 자신이 갖고 있는 예금액에 대한 정보로 이자액 계산을 요청한다. 이자율(InterestRate)는 이자(Interest) 를 생성한다.

 

도메인 객체들의 협력 다이어그램과 다른점은 이자율이 계좌의 예금액과 해지일자로 이자를 생성하지만 계좌가 이자를 직접 연관(Directed Association) 으로 참조한다는것이다. 이자는 계좌에 대해 1 번 지급될 수 있고 이는 예금액과 해지일자로 이자를 계산해주는 이자율이 아니라 해당 계좌와 연관을 맺어야 한다. 이자율은 단순히 계산을 해주는 클래스일 뿐이다.

 

앞에서 언급한적이 있지만 현실 세계에서는 정기 예금이 계좌 에게 이자율 계산을 요청할 수 없다. 하지만 객체 지향 세계에서는 사물이라도 자율적으로 다른 객체에게 필요한 것을 요청할 수 있으며, 필요한 것을 가진것으로 생각되는 적절한 객체를 선택할 수 있다.

 

또한 객체지향은 재귀적이다. 큰 객체가 작은 객체를 품을 수 있다. 시스템이라는 거대한 객체는 위와 같이 여러 작은 객체로 나뉘어졌으며 시스템의 요구사항에 따라 예제의 객체들은 더 작은 객체들로 재귀적으로 분할될 수 있다.

---

- 기능 변경을 흡수하는 구조

앞에서 언급한 말 중에 '도메인 모델은 안정적이다.' 라는 말을 지겹도록 보았을것이다. 예제도 없이 원론적인 얘기를 보느라 구체적으로 어떤 의미인지 와닿지도 않고 '이런 말은 나도 할 수 있다.'라는 생각도 했을 것이다. 예제를 통해 무슨 의미인지 알아보도록 하자. 그전에 도메인 모델이 왜 안정적인지 위의 예제에 기반하여 생각해보자.

 

우선 위의 예제처럼 도메인 모델링을 하면 안정적으로 유지되는 개념의 기간이 더 길다. 도메인 모델링은 비즈니스 규칙이기 때문에 빈번하게 변하는 요구사항의 변동사항이 아니라 상품이 변하는 생명주기를 따라 간다.

 

또한 개념간의 관계도 안정적으로 유지되는데 계좌와 이자의 다중성 관계에서 이자가 0 또는 1 인것은 만기가 되거나 해지할 때 이자를 1번 지급받기 때문이다. 이는 비즈니스 규칙이 변하지 않는 한 개념간의 관계 또한 오래 유지가 되는것을 보여주는 대목이다.

 

만약 요구사항이 변경되어 단리 이자만 지급하는 기존 정책과 더불어 복리 이자를 지급하는 상품이 생겼다고 가정해보자. 계좌는 이자율에게 이자 계산을 요청하고, 단리 혹은 복리 방식에 따라 적절하게 계산할 수 있어야 한다.

 

 

기존과 비교해서 변경된 부분은 이자율(InterestRate) 부분이다. 단리 이자를 SimpleInterestRate 로 재정의 하고, 복리 이자(CompoundInterestRate) 를 추가하였다. 이 두 클래스는 InterestRate 인터페이스를 구현(Realization)한다. 다이어그램은 복잡해졌지만 잘 생각해보면 전체적인 구조는 기존과 동일하다고 할 수 있다. 만약 특별한 이자율을 가진 상품을 추가한다면 이자율을 계산하는 구현체를 추가하기만 하면 된다. 또한 다형성도 구현되었으므로 계좌에서는 인터페이스만 참조하면 이자율 계산방식을 실행시간에 변경할 수도 있다.

 

위의 모델은 코드 변환시에도 그대로 적용된다. 코드를 역으로 해석할 때에도 도메인 모델링이 변경되었음을 추측할 수 있다. 도메인 모델은 다이어그램이나 문서가 아니다. 사람들 사이의 형성된 멘탈 모델이다. 문서화 되어있다면 파악하기 더 수월하겠지만 꼭 문서로 되어있지 않아도 사람들의 뇌리속에 위와 같은 모델이 형성된다면 그것만으로 충분하다.