object 협력, 책임, 역할 발표

요약정리

객체지향 패러다임의 관점에서의 핵심은 협력(collaboration), 책임(resposibility), 역할(role) 입니다.

협력

협력을 설명하기 앞서 2가지 개념을 먼저 설명하고자 합니다.

캡슐화

메시지를 수신 받은 객체는 메서드를 실행해 요청에 응답합니다. 이때 객체 스스로 메시지를 처리할 방법을 선택하게 되며, 메시지를 전송한 객체는 그 처리 방법을 몰라도 됩니다.
이렇게 객체를 자율적인 존재로 만드는 것을 캡슐화라고 하며 이를 통해 변경에 대한 파급 효과를 줄일 수 있고 변경하기 쉬운 객체를 만들 수 있게 됩니다.

문맥

문맥을 단순히 어학사전에서 해석하면 서로 이어져 있는 문장의 앞뒤 관계라는 의미를 가집니다.

이를 객체지향의 협력이라는 관점으로 설명하면 서로 이어져 있는 객체들간의 앞뒤 관계 즉 협력 안에서 의미있는 객체들간의 관계라고 설명할 수 있겠습니다. 

 

즉 이 두개념을 토대로 설명한 협력이란 자율성을 가진 객체들간의 의미있는 관계를 정의한 것이라 말할 수 있습니다. 

그리고 각 객체들이 협력을 할 수 있는 수단은 메시지 전송(행동)이 됩니다.

 

책임

책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 유지해야하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장입니다.

크레이그 라만은 책임을 크게 하는 것(doing)과 아는 것(knowing)의 두가지 범주로 세분화합니다.

 

하는 것(doing)
객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것
다른 객체의 행동을 시작시키는 것
다른 객체의 활동을 제어하고 조절하는 것

 

아는 것(knowing)
사적인 정보에 관해 아는 것
관련된 객체에 관해 아는 것
자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

 

이 개념을 토대로 영화 예매 시스템 기능을 설명하면 다음과 같습니다.

Screening은 협력 안에서 영화를 예매할 책임을 수행하기 위해 예매하라(reserve)는 메시지를 수신받습니다.

하지만 예매를 위해 영화 관람료를 입력 해야하는데, 영화 관람료 계산을 하는 방법을 알진 못하기에 Movie에게 영화 관람료 계산을 지시합니다. 

Movie는 협력안에서 가격을 계산할 책임을 수행하기에 Screening의 요구 사항을 받아 영화 관람료를 계산합니다. 

하지만 영화 관람료를 계산하는 과정에 있어 영화 관람료의 할인 조건을 계산하는 방법과 할인 금액을 얼만큼 적용해야되는 지를 모릅니다. 

그래서 자신이 모르는 업무를 DiscountCondition과 DiscountPolicy에게 지시합니다.  

 

이 내용에서 우리가 알 수 있는 것은 Screening과 Movie가 협력이라는 관점에서 자신들이 해야될 책임을 알고 있다는 것(아는 것)과 자신들이 할 수 없는 작업을 시킨다(하는 것)는 것을 알 수 있었습니다.

이처럼 협력안에서 객체들이 자신의 역할을 다할 수 있는 이유는 책임 주도 설계를 했기 때문입니다.

 

책임 주도 설계

협력안에서 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 설계방식을 책임 주도 설계라고 합니다.

책임을 할당할 때 고려할 2가지 사항은 다음과 같습니다.

1. 메시지가 객체를 결정한다.
메시지가 객체를 선택하게 만들어야 하는 2가지 중요한 이유가 있습니다.

 

1) 객체가 최소한의 인터페이스를 가질 수 있게 만듭니다.

   협력 관계를 이미 알고 있기에 필요한 행동에 대한 최소한의 인터페이스만을 만들 수 있습니다.

   이렇게 했을 때의 장점은 꼭 필요한 인터페이스만을 가질 수 있다는 것입니다. 

 

2) 객체는 충분히 추상적인 인터페이스를 가질 수 있게 만듭니다.
    협력의 관점에서 어떤 행동을 시키고 어떤 행동을 할지 아는 것은 모든 객체들이 서로의 책임을 다 알필요가 없다는

    의미가 됩니다.

    즉, 각 객체들 간에 서로가 어떻게 구현되는지에 대한 신경을 쓸필요가 없고 추상화된 인터페이스만을 의존해도 협력

    관계가 유지된다는 것입니다. 

    이런 추상적인 인터페이스를 통해 객체들간의 관계를 좀 더 쉽게 파악할 수 있게 됩니다.  

 

결국 메시지가 객체를 결정하는 것은 객체들 간의 협력을 기반으로 하기에 캡슐화를 유지하면서도 객체간의 관계 파악을 쉽게 할 수 있다는 장점을 가지고 있기에 메시지가 객체를 결정해야 된다는 것입니다.

 

2. 행동이 상태를 결정한다.
행동이 상태를 결정하기에 추측에 의한 구현을 막을 수 있습니다. 

추측에 의한 구현은 협력 관계를 생각하지않고 모든 가능성을 열어둔 설계를 말하며, 이로 인해 각 객체들간의 간섭이 심해져 결합도가 높아지는 문제가 발생합니다. 

하지만 행동이 상태를 결정했을 땐 이미 필요한 객체간의 행동을 정의한 상태이기에 최소한의 공용 인터페이스만으로도 시스템이 잘 작동할 것입니다.

역할

객체가 어떤 특정한 협력안에서 수행하는 책임의 집합을 역할이라고 부릅니다.

객체 대 역할

객체와 역할을 구분하는 기준은 책임을 수행하는 대상이 한 종류라면 간단히 객체로 간주하는 것이고, 여러 종류의 객체들이 참여할 수 있다면 역할이라고 보면 됩니다.
객체와 역할의 구분의 시작은 적절한 책임과 협력의 큰 그림이 정해지고 난 뒤에 구분을 시작하면 좋습니다.
특히 구분 이후에도 애매한 경우엔 객체로 만들고, 반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로 부터 역할을 분리해내는 것이 가장 좋은 방법입니다.

역할과 추상화

추상화 설계가 가질 수 있는 장점은 2가지입니다.

1. 추상화 계층만을 이용하면 중요한 정책을 상위 수준에서 단순화 할 수 있습니다.

chapter2인 영화 예매 시스템의 모든 객체와 기능을 표현했다면 업무 플로우를 설명이 어려울 것입니다.
왜냐하면 너무 세부적인 내용까지 다 포함을 하기 때문입니다.

하지만 행동을 기반으로 한 추상화에 집중을 한다면 내용 파악이 좀 더 쉬워집니다.

또한 추상화와 관련된 세부적인 사항을 확인하고 싶은 경우 개별적으로 쉽게 파악할 수 있게 됩니다.

 

2. 설계가 좀 더 유연해집니다.
협력안에서 동일한 책임을 수행하는 객체들은 동일한 역할을 수행하기에 서로 대체가 가능해집니다.

읽고 느낀점

시스템을 만들면서 항상 최대한 빠르게 추상화를 하는 것이 좋다 생각했습니다.
왜냐하면 추상화라는 과정이 코드를 깔끔하게 만든다는 생각을 했기 때문입니다.
하지만 책에선 너무 이른 추상화는 좋지 않다고 말합니다.
오히려 시스템의 기능을 명확히 파악한 뒤 협력 관계에 맞는 책임과 상태를 적용하라고합니다.
그리고 이후엔 공통된 책임이 반복되면 공통된 책임을 역할로 표현하라 합니다.
결국은 제가 이번장까지 읽으며 핵심이라 느낀 부분은 추상화는 최대한 늦게하고, 그 이전까진 시스템의 협력관계 파악과 협력에 맞는 객체 구현을 먼저 해야겠다는 생각을 했습니다.