객체 지향 도메인모델링

우아한 테크코스 프리코스 미션의 요구사항 중
1. 들여쓰기 depth는 2까지 허용
2. 메소드가 한가지의 일만 하도록 설계
3. 클래스를 분리하는 연습
의 조건이 있었다.

이 세가지의 조건을 보고 이건 하나의 조건이라 생각하였다. (뇌피셜임)

이전에 포스팅을 하면서 공부했던 타이트한 객체지향적인 설계를 하라는 뜻이 아닐까.
각 객체가 하나의 책임을 가지고, 그 책임을 지는 과정의 행동마다 모두 메소드로 정의하라는 것 아닐까.

앞의 글에서 우아한 형제들의 글을 읽고 나름 정리를 해 보았지만 Okky에서 fender님의 글을 읽고 객체지향 도메인을 구상하는 방법을 공부해봤다.

물론 이번 글도 Okky에서 객체지향에 대한 글을 뒤지다 발견한 글을 읽고 생각하고 정리한 글이다.
작성자님의 의도를 100%이해한 것이 아닐 수 있다.
오히려 이 생각들을 하면서도 이게 맞나 라는 의문이 계속 든다.
유일하게 확실한 점은, 지금 내가 적게 될 내용을 알게 된 나는 어제의 모르던 나보다야 낫다는 것이다.

 

객체지향을 설계하기 위한 첫걸음은 도메인의 핵심 개념과 요구조건을 파악한다.

1. 먼저 도메인의 시나리오를 작성 해 본다. (평서문으로)
2. 시나리오에서 자주 등장하는 명사(핵심 개념)를 빈 인터페이스로 코딩한다.
3. 명사들 중에는 어떤 개념에 종속적인 개념이 있다.(카드의 숫자, 자동차의 바퀴) 이를 빈 인터페이스의 속성으로 추가한다.
4. 시나리오에서 동사를 추려내어 적절한 인터페이스의 메소드로 코딩한다.
5. 인터페이스들이 상호 관계를 맺어 동작하는 공용 오퍼레이션을 코딩한다.

    이번 글에서도 지금까지의 인터페이스 구성 단계에서, 세부사항의 구현을 생각하지 말 것을 강조한다.

    - 좋은 객체지향 설계는 공용 API만 보아서도 서로 연계되어 어떤 동작을 하는 지 알 수 있어야 한다.

    - 공용 API를 제외한 나머지 구현은 객체의 속성으로 캡슐화되어야 한다. 인터페이스에서는 객체 내부의 속성에 대한 어떠한 내용도 볼           수 없어야 한다. 이를 위해서는 외부로 공개되는 공용 API를 먼저 설계하고 나중에 내부 구현을 하는 방법이 좋다라는 말이다.

 

여기서 생각나는 점은 시나리오에 등장하는 명사가 인터페이스(구현을 하면 클래스)가 되고, 그 클래스에 의해 객체가 되는 것이다. 말그대로 객체가 된다. 그래서 2주차에 진행하는 자동차 경주 게임을 평서문으로 작성해보고 핵심 개념을 추출해 보았다.

 

 

음,, 지금 내가 개발한 내용에는 Car(자동차), RacingCars(경주할 자동차들), RacingGame(경주), WinnerList(우승자리스트) 밖에 없다.

이름, 이름문자열, 라운드, 최대거리, 현재위치는 객체가 클래스의 변수로 쓰이고 있다.

위의 결과에 따르면 이들도 객체로써 활동해야 한다.

클래스를 추가할 것인지에 대해 심오한 고민을 하는 중이다.

 

 

 

 

 

클래스가 하는 행동이 메서드이다.

    어떠한 기능을 하는 메서드가 어떤 클래스에 속해야 할 지 고민을 많이 했다.

    이를 결정할 수 있는 좋은 방법은, 이 행동을 하는 주체가 누구인지 고민해보는 방법이다.

 

 

 

 

기본적인 모델링에 익숙해지면 그 다음에는 일반화, 추상화에 대해 고민하는 것을 추천하신다