[오브젝트] 마지막 48일차. 604-615pg | 도메인 모델, 분석모델, 설계모델, 구현모델

 

48일차.

오브젝트: 코드로 이해하는 객체지향 설계[8주차_토요일] 마지막날
604-615pg

 
 

#요약

 

**APPENDIX C. 동적인 협력, 정적인 코드**

01. 동적 모델과 정적 모델

1) 행동이 코드를 결정한다.

- 동적 모델이 정적 모델을 결정해야 한다.

2) 변경을 고려하라

-객체지향 설계 관련 다른 도서에서는 도메인 모델을 먼저 만들고 도메인 모델을 기반으로 설계와 구현을 진행하라고 했는데, 도메인 안의 개념과 관계를 담고 있는 도메인 모델은 정적 모델인데?

 

02. 도메인 모델과 구현

1) 도메인 모델에 관하여

- 도메인 : 사용자가 프로그램을 사용하는 대상영역

- 모델 : 지식을 선택적으로 다순화하고 의식적으로 구조화한 형태

- 도메인 모델 : 사용자가 프로그램을 사용하는 대상 영역에 대한 지식을 선택적으로단순화하고 의식적으로 구조화한 형태

 

- 도메인 모델을 작성하는 것은 목표가 아니라 출발점이다.

- 도메인 모델은 여러분의 도메인에 대한 지식을 표현하고 코드의 구조에 대한 힌트를 제공할 수 있다면 어떤 형태로 표현하더라도 상관 없다.

 

2) 몬스터 설계하기

- 주인공 캐릭을 공격하는 다양한 종류의 몬스터가 등장하는 게임 설계

- 앞으로 계속 몬스터 종류를 확장할 수 있어야 함.

- 도메인 모델은 코드를 작성할 수 있는 출발점 제공

- 클래스를 추가하지 않고도 새로운 몬스터를 추가할 수 있게 해야함

 

- 타입 오브젝트 패턴(Type Object Pattern) : 어떤 인스턴스가 다른 인스턴스의 타입을 표현하는 방법

- 몬스터 게임에서는 Breed의 인스턴스가 Monster의 타입을 구현하는 타입 오브젝트 패턴이다.

 

3) 행동과 변경을 고려한 도메인 모델

- 초기에 도메인 모델은 좋은 출발점이 될 수 있지만 더 쉬운 모델이 떠오르면 과감히 버려야 한다.

- 행동과 변경을 고려하지 않고 도메인 모델을 그대로 따르는 설계는 코드의 유지보수를 방해할 뿐.

- 도메인 모델은 단순 클래스 다이어그램이 아니고, 도메인의 핵심을 간략히 단순화해서 표현할수 있는 모든 것이 도메인 모델이다.

- 도메인 모델을 봤을 때 도메인의 개념 뿐 아니라, 코드도 함께 이해될 수 있는 구조를 찾는 것.

 

4) 분석 모델, 설계 모델 그리고 구현 모델

- 분석 모델 : 해결 방법에 대한 언급 없이 문제 도메인을 설명하는 모델

- 설계 모델 : 분석 모델이 완성되면 이를 바탕으로 기술적인 관점에서 솔루션을 서술하는 설계모델이 만들어짐.

- 구현 모델 : 프로그래머는 이렇게 만들어진 청사진을 기반으로 구현 모델을 만든다.

- 분석, 설계, 구현 모델을 명확히 구분하는 것은 불가능하다.

 

- 중요한 건 분석과 설계의 구현 동안 동일한 모델을 유지하는 것.

- 코드와 모델의 차이를 줄이려면 도메인과 코드 간의 차이가 적어야 한다.

- 객체지향의 가장 큰 힘은 도메인을 표현하는 방법과 프로그램 코드를 표현하는 방법이 동일하다는 것

 

 

 

 

 

 

48일간의 여정 끝!!

또 하나의 개발 책 완독,,

2023.08.27.