[우테코 권장도서] 객체지향 사실과 오해 6장

6장

계속 같은말을 하지만 이번장은 좀 어렵다.

결국 객체지향 짱짱맨 이런거지만 키워드 위주로 정리해 보려고한다.

도메인 모델(멘탈 모델)

책에서는 구구절절히 설명하는데 결국 도메인 모델이란

우리가 원래 실세계에서 객체들을 보고서 객체지향적으로 옮겨내려고 노력하지만

일반적으로 우리의 도메인이 되는것들은 꼭 실세계 뿐만이 아니라 추상적인 것들도 있고 꼭 물리적인 것은 아니다.

예를들어 은행의 예금 상품 같은것들은 물리적인 실체가 없지만 우리가 실제로 잘사용하고있고

이것들을 우리가 어떻게 머리속에 받아들이고 서로 객체로서 생각하며 머리에 연관도가 작성되는지를 머리속에서 꺼내보고

이런것들을 객체지향적으로 옮겨내야 한다고 한다.

즉 꼭 실체가아니라 내가 이 도메인에서 분석하고 받아들인상태에서 내가 일반적인 사람이라면 다 비슷한 결론과 구조를 볼 수 있을테니

그것들을 연관지어 능동적인 객체로 만드는 재료로 사용하라는 것이다.

또한 이런 도메인 모델로 부터 객체가 출발한다면 각 객체사이의 관계도같은 것들은 이런 관계가 근본적으로 바뀌지 않는이상

변화의 폭이 없거나 적다. 그러므로 이런 객체?? 혹은 우리가 풀어야하는 도메인의 각각의 개념들이 엮이는 관계를 본능적으로 느끼고 그 관계의

흐름에 집중해서 정리해보고 이것을 객체지향을 위한 재료로 활용해보자

기능이 아닌 구조로 설계하라

위의 도메인 모델의 각 개념들의 관계 즉 구현의 문제가아니라 객체들의 연관관계를 미리 설정하고 정리한다면

구조적으로 설계하고 있는것이다.

이책에서 예시로 들고있는 은행 예금상품을 봐도 각 객체사이의 관계는 본질에 가깝다.

즉 그냥 단순 이자율은 바뀔수 있어도 이 한번에 돈을 붓고난후 일정기간후 이자를 받는 방식은 근본이므로 바뀐다면 애초에

정기예금이 없어지고 다른상품이 나오는것이므로 이것은 거의 바뀔확률이 전무하거나 적다.

그러니 이런 본질적인 구조에대해 집중하고 세부구현은 갈아끼울수 있는 요소로 이렇게 잘 짜여있는 객체내에 캡슐화해서

변화에 대응하도록 하자

유스케이스

클린 아키텍쳐 할때 맨날 유스케이스 유스케이스 해서 그냥 함수를 잘 정리한 것이라고 생각했는데

애초에 함수의 집합도 아니고 그냥 글로 정리하는것이 본질이였다.

즉 사용자가 사용할 수 있는 연관된 시나리오를 글로 작성한건데 이는 프로그램이 가져야하는 기능과 대치됨으로

도메인 모델을 통한 객체사이 관계 설정이 완료 되었다면 유스케이스를 확인하며

이 사용자가 요구하는 기능들을 만족시킬수 있도록 사용자 인터페이스를 만들어내라는 소리로 받아들였다.

또한 유스케이스는 설계기법도 객체지향과도 상관없는 것이라고 한다.

즉 그냥 뭣도 아니고 사용자에게 제공하는 외부 인터페이스라고 생각해도된다.

유스케이스는 단순 기능적 요구사항을 사용자 관점에서 문맥을 통해서 묶어놓은 정리기법이라고 한다.

즉 유스케이스를 통해서 설계를 하려 들지 말아라를 장대하게 써놓았다.

책임 주도 설계, 유스케이스, 도메인모델

결국 결론적으로 도메인모델 -> 내머리속에 이런 개념들이 어떻게 관계를 맺게 되는가? 를 확립한후

각 객체들에게 책임들을 분배하고 도메인 모델에 빗대에 은유를 통해서 표현적 차이(완전연결성)를 줄여나가야하고

그후 유스케이스를 살펴보며 프로그램에 요구했던 기능들을 구현해 나가면 되는것이다.

즉 결국 가장 중요한것은 도메인 모델을 객체로 옮기는 방법이아닐까 싶다.