[오브젝트] 3장 역할, 책임, 협력

안녕하세요 남갯입니다

 

오늘은 오브젝트의 역할, 책임, 협력에 대해 포스팅 해보려고 합니다.

 

객체지향은 "역할 책임 협력"

객체지향 패러다임의 관점에서 '역할', '책임', '협력'이다.  이 세가지가 제자리를 찾지 못한다면 응집도 높은 클래스와 중복없는 상속 계층을 구현한다고 하더라도 어플리케이션은 침몰할것 이다.

객체이향의 본질은 협력하는 객체들의 공동체를 창조하는것이다.

 

그림과 같이 객체지향의 원칙을 따르는 어플리케이션의 제어흐름은 한 객체에 의해 통제되지 않고 다양한 객체들 사이에 균형있게 분배되는 것이 일반적이다. 객체들은 요청의 흐름을 따라 자신에게 분배된 로직을 실행ㅎ면서 어플리케이션의 전체 기능을 완성한다.

 

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

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

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

 

 

협력

협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 할 때 시작된다. 메세지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다.

 

객체가 객체에게 무엇인가를 요청하는것이고, 다른객체가 필요할때 위임하거나 협력한다. 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다.

 

일전에 Screeing에서 Movie에게 요금계산 처리를 위임해서 수행시켰다 만약 Screeing에서 직업 수행한다면

fee와 discountPolicy에 직접 접근하게 되고 이 경우 Screeing은 movie에 결합된다.

이렇게 된다면 자율성이 훼손된다.

 

객체를 자율적으로 만다는 가장 기본적인 방법은 내부 구현을 캡슐화 하는것이다.

 

즉 메세지를 전송해서 협력을 요청하고 메세지를 수신한 객체는 도움이 필요한 경우 또 요청해서 처리한다.

즉 이런 객체들 사이의 협력을 구성해 요청과 응답을 통해 기능이 구현된다.

 

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

객체의 상태와 행동을 어떤기준으로 정해야할까? 결론적으로 말하면 객체가 참여하고 있는 협력이다.

협력이 바뀌면 객체가 제공하는 행동 역시 바뀌어야한다.

 

예를들어 Movie가 있고 영화 상영을 한다 했을때 Movie의 행동을 결정하는 것은 예매를 위한 협력이다.

협력이라는 문맥을 고려하지 않고 Movie의 행동을 결정하는 것은 아무런 의미가 없다. 협력이 존재하기 때문에 객체가 존재하는 것이다.

 

 

책임

책임이란 무엇일까?

협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 부른다. 책임이란 객체에 정의되는 응집도 있는 행위의 집합으로 객체가 유지해야 하는 정보와 수행 할 수 있는 행동에 대해 개략적으로 서술한 문장이다.

객체의 책임을 크게 '하는것'과 '아는것'의 범주로 나누어 세분화 된다.

 

하는것 

- 객체를 생성하거나 계산 수행하는 등의 스스로 하는것

- 다른 객체의 행동을 시작시키는 것

- 다른 객체의 활동을 제어하고 조절하는 것

 

아는것

- 사적인 정보에 관해 아는것

- 관련된 객체에 관해 아는것

- 자신이 유도하거나 계산할 수 있는 것에 관해 아는것

 

 

Screening의 책임은 영화를 예매하는것

Movie의 책임은 요금을 계산하는것

 

책임과 메세지의 크기는 다르다

책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에 추상적이고 개념적으로도 더 크다.

처음에는 단순한 책임이라고 생각했던 것이 여러 개의 메세지로 분할되기도 하고 하나가 수행할 수 있다고 생각했던 책임이 나중에는 여러 객체들이 협력해야만 하는 커다란 책임으로 자라는게 일반적이라고 한다.

 

여기서 말하고자 하는 내용의 내 생각은

하는것이란 내가 하는 역할에 대한 책임이고 

아는것은 내가 도움받을 객체를 아는것 이라고 생각된다.

 

CRC카드 (Candidate, Responsibility, Collaborator)

https://ko.wikipedia.org/wiki/CRC_%EC%B9%B4%EB%93%9C 

1. 객체명
2. 패키지명 (만약 있다면)
3. 객체의 책임 (해야할 일)
4. 객체가 자신의 책임을 다하기 위하여 포함해야 하는 다른 객체의 이름을 열거한다.

책임을 할당할 후보는 객체 혹은 역할일수 있고, 후보에 어떤 책임을 할당하는 것인가에 집중한다.

 

책임할당

자율적인 객체를 만드는 기본적인 방법은 책임을 수행하는데 필요한 정보를 가장 잘 알고 있는 전문가에게

그 책임을 할당하는 것이다. 이를 책임 할당을 위한 정보전문가 패턴이라고 부른다.

 

예를들어 '예매하라' 라는 메세지는 어떤 객체에 할당해야 할까?

가장 정보를 많이 알고 있는 Screening에게 주어야한다.

 

Screening은 영화 정보를 알지만 가격을 모르니 '가격을 계산하라' 라는 메세지는 Movie에게 책임을 할당한다.

 

책임 주도 설계 (RDD)

지금까지 살펴본 내용의 요점은 협력을 설계하기 위해서는 책임에 초점을 맞춰야 한다.

책임을 할당하는 방식으로 설계하는 방식은 '책임 주도 설계'라고 부른다.

 

책임 주도 설계방법의 과정

1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.

2. 시스템 책임을 더 작은 책임으로 분할한다.

3. 분할된 책임을 수핼할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.

4. 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.

5. 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

 

 

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

메세지가 객체를 선택해야하는 이유 두가지

1. 객체가 최소한 인터페이스를 가질 수 있게 된다. (필요한 크기의 퍼블릭 인터페이스를 가질 수 있음)

2. 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다. (외부 객체가 요청하는 무언가를 의미하기 때문에 메세지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 인터페이스를 얻을 수 있다.)

 

 

행동이 상태를 결정한다.

객체의 내부 구현에 초점을 맞춘 설계 방법을 데이터 주도 설계하고 부르기도 했는데

캡슐화를 위반 하지 않도록 구현에 대한 결정을 뒤로 미루면서 객체의 행위를 고려하기 위해서는 항상

협력이라는 문맥안에서 객체를 생각해야한다. (얻고 제공하는것)

 

 

역할

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

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

하나의 단계처럼 보이지만 두가지의 단계로 이루어 진것인데

하나는 영화를 예매할 수 있는 적절한 역할이 무엇인지 찾는것이고, 두번째는 역할을 수행할 객체로

Screening인스턴스를 선택하는 것 이다.

 

 

유연하고 재사용 가능한 협력

역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다.

두가지 종류의 객체가 할인요금에 응답하기 위해서는 두 종류의 객체가 참여하는 협력을 개별적으로

만들지 말고

두개는 모두 할인 요금이라는 동일한 책임을 갖고 있으므로 일종의 슬롯이라 생각할 수 있고

이 슬롯이 역할이다.

역할을 포괄하는것을 추상화라고 한다.

 

트리그비 린스카우

협력은 역할들의 상호작용으로 구성되고, 협력을 구성하기 위해 역할에 적합한 객체가 선택되며

객체는 클래스를 이용해 구현되고 생성된다.

즉 객체와 역할을 구분하는것은 그렇게 중요하지는 않고  처음에는 단순하게 객체로 시작해서

반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 좋은 방법이다.

 

 

배역과 배우

연극 안에서 배역을 연기하는 배우라는 은유는 협력안에서 역할을 수행하는 객체라는 관점이

가진 입체적인 측면들을 훌륭하게 담아낸다.