[오브젝트 스터디] Chapter 03 역할, 책임, 협력

오브젝트 챕터3 역할, 책임, 협력를 시작하겠습니다. 

 

지난 챕터에서는 어떻게 객체지향을 구현할까 하는 관점에서 얘기했지만 이번에는 객체지향의 핵심 개념인 역할, 책임, 협력에 대해 알아본다. 지난 챕터에서의 영화 예매 어플리케이션의 로직을 가져와 설명한다. 

 

아래와 같다.

 

 

먼저,

객체들이 어플리케이션을의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다.

객체가 협력에 참여하기 위해 수행하는 로직을 책임이라고 부름.

객체들이 협력안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.

 

협력

객체지향의 세계에서 기능을 구현할 수 있는 유일한 방법이 협력이다.

메세지 전송은 다른 객체에게 도움 요청을 통해 커뮤니케이션을 할수 있는 유일한 수단이다.

캡슐화를 통해  객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없도록 하기 때문이다.

 

메세지를 수신한 객체는 메서드를 실행해 요청에 응답한다. 응답한 객체는 메세지를 처리할 방법을 자신만의 방법으로 처리하여 요청에 응답해준다. 그렇기 때문에 객체는 스스로 일을 처리할 수 있는 자율적인 존재라는 것을 의미한다.

 

영화 예매 시스템에서 Screening이 Moive에게 처리를 위임하는 이유는 요금을 계산하는데 필요한 기본 요금과 할인정책을 잘 알고 있는 객체가 Movie이기 때문이다. 요금을 계산하는 작업을 Screening이 수행한다면 Movie의 인스턴스 변수인 fee와 discountPolicy에 직접 접근해야하는데 이 경우 Screeininng은 Moive의 내부구현에 결합된다. 그리고 Movie의 자율성이 훼손된다. 이 말은 즉 자율적이지않고 수동적인 존재가 된다는 것이다. 이러면 안된다는것을 지금까지 배웠다. 그저 처리를 위임해야할 뿐이다.

 

협력이 설계를 위한 문맥을 결정한다

Movie라는 객체는 영화를 예매하기 위한 협력에 참여하고 있고 그 안에서 요금을 계산하려는 책임을 지고 있다. 그러나 Movie라는 것은 일반적으로 영화를 상영하는 Play라는 행동이 생각날 수 있다. 하지만 지금은 영화 예매를 하기위한 협력에 참여하고 있기 때문에 Movie는 그러한 의미를 지니지 않는다. 

 

책임이란 무엇인가

객체의 책임은 객체가

무엇을 알고 있는가?

무엇을 할 수 있는가? 로 구성된다. 

 

영화 예매시스템에서

Screening의 책임은 무엇인가? 영화를 예매하는 것이다.

그리고 자신이 상영할 영화를 알고 있어야한다.

 

객체지향에서 가장 중요한 것은 책임이다.

 

책임 할당

자율적인 객체를 만드는 가장 기본적인 방법은 책임을 수행하는데 필요한 정보를 가장 잘알고있는 전문가에게 그 책임을 할당하는 것이다. 이를 INFOMATION EXPERT 패턴이라고 부른다.

 

이 방식은 일상생활에서 모르는 것이 있으면 전문가에게 도움을 요청하는 방식과도 유사한데

 

예매하라는 메세지로 협력을 시작하여 예매를 가장 잘 알고 있는 Screening에게 책임을 할당한다. 그런데 Screening은 예매 가격을 계산하는데 필요한 정보를 잘 알지 못한다. 그래서 Screening은 또 그것을 잘 알고 있는 Movie에게 '가격을 계산하라'는 메세지를 전송한다.

그런데 Movie는 또 할인 요금을 계산하는것을 잘 알고 있지 못한다. 그래서 다시 Movie는 discountPolicy에게 할당한다.

책임주도 설계(RDD)

협력을 설계하기 위해서는 책임에 초점을 맞춰야한다는 것이다. 이것을 책임주도설계(RDD)라고한다.

책임 주도 설계 과정

1. 시스템이 사용자에게 제공해야하는 기능인 시스템 책임을 파악한다.
2.  시스템 책임을 더 작은 책임으로 분할한다.
3.  분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
4.  객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
5.  해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 된다.

메세지가 객체를 결정한다.

아까 '예매하라'라는 메세지로 협력을 시작해 예매를 잘 아는 객체를 찾는다. 그게 메세지가 객체를 결정한다는 말이다.

 

이렇게하면 장점이 뭘까?

꼭 필요한 것만 사용하기 때문에 최소한의 인터페이스를 가질 수 있고 

어떻게 처리하는지에 대해 노출하지 않기 때문에 추상적인 인터페이스를 가질 수 있다. 

행동이 상태를 결정한다.

객체의 행동은 협력에 참여 할 수 있는 유일한 방법이다.

객체지향을 잘모르는 사람들은 객체의 행동이 아니라 상태에 초점을 맞추는 데 이런 방식은 캡슐화를 저해한다.

예를 들어 학생이라는 객체에는 이름과 나이, 주소가 있는데 이 데이터들을 가져오고 세팅하는 메서드를 만들자 정도로 생각하기 쉽다. 이러면 객체 바깥에서 데이터를 직접 건드리는 일이 잦아질 수 있다.

상태는 단지 객체가 행동을 정상적으로 수행하기 위해 필요한 재료일 뿐이다. 행동에 초점을 맞추자.

행동을 결정하고 나서야 상태를 결정할 수 있는 것이다. 이 행동이 객체의 책임이 된다.

 

역할과 협력

협력을 모델링할때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하는게 좋다. 예를들어

영화 예매 협력에서 '예매하라'는 메세지를 처리 하기 위해 적잡한 객체로 Screening을 선택했다.

Screening은 다시 '가격을 계산하라'는 메세지를 Movie에게 보냈다.

 

그러면 또 Movie가 가격을 계산하기 위해 '할인 요금을 계산'하라는 메세지를 다른 객체에게 보내 도움을 청하는데

금액할인정책과 비율할인 정책이라는 두가지 객체가 존재한다. 금액할인정책과 비율할인 정책 둘다 할인 요금을 계산한다는 동일한 책임을 가지고 있다. 이러한 것을 추상화하면 둘 다 할인 요금 계산이라는 역할을 수행하고 있다.

 

동일한 책임을 수행하는 역할을 기반으로 두개의 협력을 하나로 통합하면 불필요한 코드 중복을 제거 할 수 있다. 코드 중복은 항상 문제를 야기한다.

 

 

객체 대 역할

역할은 객체가 참여할 수 있는 일종의 슬롯이다. 

역할은 유용하고 재사용 가능한 설계를 할 수 있게 한다. 

 

그러나 사람들은 세상을 이해할때 무의식적으로 개념, 객체, 역할을 뒤섞는다 그래서 불완전성을 가질 수 밖에 없다.

따라서 애매하다면 단순하게 객체로 시작하고 반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로 부터 역할을 분리해 내는것이 가장 좋은 방법이다.

 

배우와 배역

배우와 배역의 예시로 역할에 대한 이해를 높여보자. 배우는 연극 안에서 역할을 수행하는 객체이다. 배우는 어떤 배우가 와도 상관없다. 하는 역할이 같다. 아까 슬롯의 비유와 같은말이다.