객체 지향적으로 설계하고 구현하는 것이란

woowabros.github.io/study/2016/07/07/think_object_oriented.html

생각하라, 객체지향처럼 - 우아한형제들 기술 블로그

이글은 위의 우아한 형제들 기술 블로그의 김승영님의 글을 읽고 공부한 글입니다.

저만을 위해 쓴 글이기 때문에 객체지향에 대해 알고 싶어서 오신 분이라면 위의 블로그를 들어가서 정독하시는 것을 추천드립니다.

 

1. 도메인 구상하기

도메인은 본래 범위, 영토 라는 뜻을 가진다. 

사용자들이 관심을 가지고 있는 특정 분야나 주제를 말하며 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발된다.

 

1-1. 객체 생각하기 

도메인에서 일어날 수 있는 일을 절차적으로 생각해본다.

ex) 손님이 메뉴판에서 4가지 메뉴 항목들 중 하나를 선택하여 바리스타에게 주문하고, 바리스타는 그 커피를 제조하여 손님에게 제공

이를 통해 객체가 될 것들을 선별한다.

ex) 손님, 바리스타, 메뉴판, 메뉴항목, 커피

 

1-2. 객체간의 관계 생각하기

그림을 그려보며 객체간의 관계를 생각해본다.

ex) 커피선택, 주문, 제조

 

 

1-3. 객체를 타입으로 분류

타입 : 인터페이스

클래스 : 인터페이스를 구현한 클래스(어떻게 구현되느냐를 정의)

ex) 여러가지 커피는 커피타입을 가지는 하나의 인터페이스로 구현될 수 있다. 같은 상태와 같은 행동을 하는 '타입'이다.

 

 

1-4. 타입과의 관계 생각하기

위에서 객체들의 관계를 나타낸 것을 바탕으로 타입간의 관계를 생각해본다.

 

1. 어떤 타입이 도메인을 구성하느냐?

2. 타입들 사이에 어떤 관계가 존재하는지 파악함으로 도메인을 이해.

 

ex) 메뉴 항목은 메뉴판에 '포함'되는 관계이다.

ex) 손님은 메뉴판을 보는 '연관' 관계이다.

 

 

1-5. 객체지향 설계

객체지향의 세계는 협력하는 자율적인 객체들의 공동체

객체들의 협력을 설계하는 것입니다. 즉, 적절한 객체에게 적절한 책임을 할당하는 것입니다.

 

어떤 객체가 협력을 필요로 하고 그 협력을 어떤 객체에 책임으로 할당할 것인가 !

 

 

 

2. 설계하고 구현하기

훌륭한 협력을 설계하는 것이 첫번째 목표

협력을 설계할 때는 객체보다는 메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택
즉, 메시지가 객체를 선택

그 후 메시지를 수신할 객체는 메시지를 처리할 책임을 맡게 되고 객체가 수신하는 메시지는 객체가 외부에 제공하는 공용 인터페이스에 포함

 

(1) 시나리오대로 처음 만들 수 있는 메세지를 정하고 그 메세지(책임)을 수신할 객체를 선택한다.

(2) 수신할 객체는 책임을 지고 메세지를 공용 인터페이스로 만든다.

(3) 메세지를 수신한 객체에서 시나리오대로 메세지를 생성하고 책임을 질 객체를 정하는 과정을 반복한다.

 

(여기서 메세지를 정의할 때 필요한 요소들을 메세지에 포함하게 되는데, 후에 매개변수와 반환값이 될 것이다,)

(객체지향의 세계에선 생물도 의인화하여 능동적인 행동을 한다고 생각해야 한다.)

 

 

 

 

 

 

3. 인터페이스 정리하기

객체가 수신한 메시지가 객체의 인터페이스를 결정한다

메시지가 객체를 선택했고, 선택된 객체는 메시지를 자신의 인터페이스로 받아들인다.

위의 단계에서 구성한 도식에서 객체와 수신하는 메세지 만 때어내면 인터페이스가 된다.

(위에서 언급했듯, 객체가 어떤 메시지를 수신할 수 있다는 것은 그 객체의 인터페이스 안에 메시지에 해당하는 오퍼레이션이 존재한다는 것을 의미)

 

다시한번 말하지만, 협력을 통해서 만들어진 타입의 메세지(오퍼레이션)은 받는 객체가 가져야할 공용 인터페이스(외부에서 접근 가능해야함)의 일부이다. (public 선언 필요)

 

-- 여기까지는 메세지를 교환하면서 협력하는 구조까지 정의한다.

 

 

 

4. 구현하기

위의 단계에서 인터페이스의 오퍼레이션을 식별하고 선언했다. 이제는 공용 오퍼레이션으로 구성된 인터페이스를 구체적으로 구현하면서 내부에 필요한 기능들을 추가적으로 구현하면 된다.

 

메세지를 보내는데 필요한 것들을 찾아서 매개변수로 넣어서 던진다. (객체에 대한 참조)

 

 

 

객체의 속성은 객체의 내부 구현에 속하기 때문에 캡슐화되어야 한다.

객체의 속성이 캡슐화된다는 이야기는 인터페이스에는 객체의 내부 속성에 대한 어떤 힌트도 제공되어서는 안 된다는 것을 의미한다.

이를 위한 가장 훌륭한 방법은 인터페이스를 정하는 단계에서는 객체가 어떤 속성을 가지는지, 또 그 속성이 어떤 자료 구조로 구현됐는지를 고려하지 않는 것이다. 객체에게 책임을 할당하고 인터페이스를 결정할 때는 가급적 객체 내부의 구현에 대한 어떤 가정도 하지 말아야 한다. 객체가 어떤 책임을 수행해야 하는지를 결정한 후에야 책임을 수행하는 데 필요한 객체의 속성을 결정하라.

이것이 객체의 구현 세부 사항을 객체의 공용 인터페이스에 노출시키지 않고 인터페이스와 구현을 깔끔하게 분리할 수 있는 기본적인 방법이다.

인터페이스를 통해 실제로 상호작용을 해보지 않은 채 인터페이스의 모습을 정확하게 예측하는 것은 불가능에 가깝다. 설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿 속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라. 설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라. 테스트-주도 설계로 코드를 구현하는 사람들이 하는 작업이 바로 이것이다. 그들은 테스트 코드를 작성해 가면서 협력을 설계한다.