지도는 실세계의 지형을 기반으로 만들어진 추상화된 모델
다양한 목적을 위해 재사용될 수 있음
어떤 목적으로 지도를 사용할지 알지 못한다.
길을 갈 때 → 어떻게 어떻게 가세요 ( 기능)
지도를 보고 감 → (구조와 같음)
소프트웨어 설계에 있어서도 기능보다는 구조를 중시하자
소프트웨어의 특징 → 요구사항은 항상 변한다 → 구조를 잘 잡으면 요구사항(기능)이 변해도 쉽게 풀어나갈 수 있음
구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이다.
안정적인 구조를 따라 역할, 책임, 협력을 구성하라.
전통적인 기능 분해는 자주 변경되는 기능을 중심으로 설계한 후 구조가 기능에 따르게 한다. 객체지향 접근방법은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.
객체를 이용해 지도를 만들자. 기능은 지도에 표시된 길을 따라 자연스럽게 흘러갈 것이다.
객체지향 세계를 구축하기 위해서는 1. 사용자에게 제공할 '기능'과 2. 기능을 담을 안정적인 '구조'라는 재료가 준비돼 있어야 한다.
- 구조는 사용자나 이해관계자들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계로 표현했다. ( 도메인 모델링)
- 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다.( 유스케이스 모델링)
사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.
그 분야에 있어서 가장 핵심적인 것들( 도메인). 중고차 자동차 판매상은 구매되는 자동차와 판매되는 자동차의 교환으로 자동차 도메인을 바라보는 것.
도메인 모델은 단순히 다이어그램이 아니라, 이해관계자들이 바라보는 멘탈 모델.
멘탈 모델이란 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형.
(디자인 모델, 사용자 모델, 시스템 이미지) → 최종적으로, 사용자 모델에 최대한 맞게 만들어야 함
도메인 모델은 소프트웨어에 대한 멘탈 모델이다.
객체지향을 사용하면 사용자 모델, 디자인 모델, 시스템 이미지가 모두 유사한 모습을 유지하도록 만드는 것이 가능하다. 객체지향의 이러한 특징을 연결 완전성 또는 표현적 차이라고 한다.
은유를 통해서 현실 객체와 소프트웨어 객체의 차이를 최대한 줄이는 것. 은유를 통해서 사용자가 도메인에 대해 생각하는 개념들에 최대한 가깝게 작성해야 함 → 코드를 이해하고 수정하기 쉽게 만들어줌
도메인 모델이 제공하는 구조가 상대적으로 안정적
도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 해도 실제로 사용자에게 중요한 것은 도메인 모델이 아니라 소프트웨어의 기능 → 유스케이스
사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 함
사용자 목표가 유스케이스의 핵심. 유스케이스는 사용자 목표를 통해 강하게 연관된 시나리오의 집합.
- 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트
- 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합
- 단순한 feature 목록과는 다르다. 이야기를 통해 연관된 기능들을 함께 묶을 수 있다는 점이 강점
- 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
- 내부 설계와 관련된 정보를 포함하지 않는다.
도메인 모델은 객체 지향을 위한 모델이지만, 유스케이스 모델은 모든 패러다임에서 전부 사용할 수 있음
불안정한 기능을 안정적인 구조 안에 담음으로써 변경에 대한 파급효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야 할 기본적인 설계 능력이다.
사용자에게 시스템이 수행하기로 약속한 기능 → 시스템의 책임 → 객체는 전송한 메시지에 응답하는 데 필요한 책임을 수행하는 일종의 객체
시스템이라는 객체 안에 작은 규모의 객체들의 협력으로 시스템이 수행됨.
시스템의 기능 → 시스템의 책임 → 작은 규모의 객체들이 수행해야 하는 더 작은 규모의 책임 → 어떤 객체를 선택할 것인가?( 도메인 모델) → 협력을 완성하는 데 필요한 메시지를 식별하면서 객체들에게 책임을 할당함 → 협력에 참여하는 객체를 구현하기 위해 클래스를 추가하고 속성과 함께 메서드를 구현하면 시스템의 기능이 완성된 것
책임-주도 설계는 시스템의 기능을 역할과 책임을 수행하는 객체들의 협력 관계로 바라보게 함으로써 두 가지 기본재료인 유스케이스와 도메인 모델을 통합
견고한 객체지향 애플리케이션 → 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다
객체지향이 좋은 이유 → 연결완정성 , 그리고 그의 역방향도 설립( 사용자가 생각하는 실제 개념 → 소프트웨어의 객체 , 소프트웨어의 객체 → 사용자가 생각하는 실제 개념)
결국, 사용자가 생각한 것과 소프트웨어 객체가 은유를 잘하면 일치할 수 있음 ( 코드 이해가 매우 쉬우며, 코드 작성도 매우 쉬움)
그렇기 때문에, 도메인 모델은 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.
안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라.
도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라.
'공부기록 > 객체지향' 카테고리의 다른 글
객체지향의 사실과 오해 - 다시 읽어보기 (0) | 2021.09.07 |
---|---|
객체지향의 사실과 오해 - Chapter 7 함께 모으기 (0) | 2021.06.19 |
객체지향의 사실과 오해 - Chapter 5 책임과 메시지 (0) | 2021.06.13 |
객체지향의 사실과 오해 - Chapter 4 역할, 책임, 협력 (0) | 2021.06.12 |
객체지향의 사실과 오해 - Chapter 3 타입과 추상화 (0) | 2021.06.04 |