본문 바로가기

책/객체지향의 사실과 오해 (완)

06 객체지도

설계를 할 때 기능을 중심으로 설계를 하는 것이 아닌 구조를 중심으로 설계를 하라는 말이 와닿았습니다. 구조 중심으로 설계를 하며 객체간 메시지를 주고받는 것이 핵심인듯 합니다.


기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다.
...
객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다.

기능이 아닌 구조를, 변경에 유연한 구조를 설계하는 것이 중요하다는 생각이 들었습니다.

 

기능 설계 대 구조 설계

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.
...
전통적인 기능 분해는 자주 변경되는 기능을 중심으로 설계한 후 구조가 기능에 따르게 한다.
...
기능이 변경될 경우 기능의 축을 따라 설계된 소프트웨어가 전체적으로 요동치게 된다.
...
안정적인 객체 구조는 변경을 수용할 수 있는 유연한 소프트웨어를 만들 수 있는 기반을 제공한다.

기능설계가 가지는 단점에 대해 이야기를 하고 있으며 구조 설계가 가지는 장점에 대해 이야기를 하고 있습니다. 객체 지향 설계는 현실 세계에 대한 은유라는 문장과 빗대어 생각을 해보면 변경에 유연하게끔 코드를 작성하는 것이 좋은 설계라 생각합니다.

 

두 가지 재료: 기능과 구조

일반적으로 기능을 수집하고 표현하기 위한 기법을 유스케이스 모델링이라고 하고 구조를 수집하고 표현하기 위한 기법을 도메인 모델링이라고 한다.

여기서 저는 도메인 모델링에 조금 더 관심이 갔습니다. 또한 오브젝트 책에 따르면 도메인 모델은 현실세계에 존재하는 문제점만을 정직하게 표현하지 않고 도메인과 관련이 되어있다면 전부 도메인 모델이라는 것을 생각하며 책을 읽어갔습니다.

 

안정적인 재료: 구조

도메인모델

이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다
...
도메인 모델에서 모델이란 대상을 단순화해서 표현한 것이다.
...
훌륭한 디자인이란 사용자가 예상하는 방식에 따라 정확하게 반응하는 제품을 만드는 것이다.

도메인 모델이 집중을 하되 여전히 사용자 관점에서의 프로그램도 의식하라는 말로 이해하였습니다.

 

도메인의 모습을 담을 수 있는 객체지향

최종코드는 사용자가 도메인을 바라보는 관점을 반영해야 한다. 이것은 곧 애플리케이션이 도메인 모델을 기반으로 설계돼야 한다는 것을 의미한다.

위에서 이야기를 했듯 도메인 모델을 생각하되 사용자의 관점을 잊지 말라고 반복해서 이야기를 하고 있다 느꼈습니다.

 

표현적 차이

소프트웨어 객체는 현실 객체를 모방한 것이 아니라 은유를 기반으로 재창조한 것이다. 따라서 소프트웨어 객체는 현실 객체가 갖지 못한 특성을 가질 수도 있고 현실 객체가 하지 못하는 행동을 할 수도 있다.

이 책의 앞부분에서 언급한 내용입니다. 어디까지나 객체는 현실세계의 모방이기에 객체는 능동적으로 행위를 할 수 있습니다.

불안전한 재료: 기능

기능변경을 흡수하는 안정적인 구조

도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
...
도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.

기능변화가 있더라도 도메인 모델에 따른 구조 설계를 하였다면 충분히 변화를 감당할 수 있다는 이야기를 하고 있습니다.

' > 객체지향의 사실과 오해 (완)' 카테고리의 다른 글

07 함께 모으기  (0) 2024.03.15
05 책임과 메시지  (1) 2024.01.23
04 역할, 책임, 협력  (2) 2024.01.23
03 타입과 추상화  (0) 2024.01.10
02 이상한 나라의 객체  (0) 2024.01.07