객체지향의 사실과 오해) 04 / 역할, 책임, 협력

< 서론 >

ex) 최후 통첩게임 (단한번의 기회)

제안자에게 일정한 금액을 제안하고 

제안자는 금액 일부를 응답자와 나누어 갖는다.

거부하면 아무도 못갖는다.

제안자는 40% 이상이 제일 많고 50%, 30% 이상도 많았다.

응답자는 20% 이하의 제안의 경우 대부분 거절.

최후 통첩게임의 결과적으론

"가지려면 받고 아니면 말라" 라는 식의 인색한 최후 통첩에 대해 인간은 합리적인 선택을 하지 못하고 감정적으로 대응한다.

결론적으로 

인간이 어떤 본질적인 특성을 지니고 있느냐가 아니라 어떤 상황에 처해 있느냐가 인간의 행동을 결정한다. 

즉, 각 개인이 처해 있는 정황 또는 문맥이 인간의 행동방식을 결정한다는 것.

위의 설명은 별로 와닿지 않는다. 

말하고자 하는건 협력이라는 문맥이 객체의 행동방식을 결정한다.

중요한 것은 객별 객체가 아니라 객체들 사이에 이루어지는 협력이다.

객체들 간의 협력에 집중하라. 이것이 이번장의 주제다.

이번장의 키워드는 

1. 역할, 책임, 협력의 개념

2. 협력이 어떤 식으로 객체의 외양과 특성을 결정하는지

"협력"

협력의 본질은 요청과 응답으로 연결되는 네트워크

ex) 재판

1. 누군가 왕에게 재판 요청

2. 왕이 토끼에서 증인을 부를것을 요청

3. 토끼가 모자장수에게 증인석에 입장할것을 요청

4. 모자장수가 입장함으로 토끼의 요청에 응답 (2번에 대한 응답이기도 함)

5. 왕이 모자장수에게 증언할것을 요청

6. 모자장수가 내용을 증언함으로 왕의 요청에 응답

객체들은 재판이라는 동일한 목적을 달성하기위에 협력하고 있는 것

< 요청과 응답의 초점으로 >

1. 누군가 왕에게 재판 요청

- 왕이 재판을 수행의 의무가 있음

2. 왕이 토끼에서 증인을 부를것을 요청

- 토끼가 목격자에 대해 알고 있으며 동시에 목격자를 부를 의무가 있음

3. 토끼가 모자장수에게 증인석에 입장할것을 요청

4. 모자장수가 입장함으로 토끼의 요청에 응답 (2번에 대한 응답이기도 함)

5. 왕이 모자장수에게 증언할것을 요청

- 모자장수가 사건의 내용을 조금이라도 알고 있고, 증언할 의무가 있음

6. 모자장수가 내용을 증언함으로 왕의 요청에 응답

결국 어떤 등장인물들이 특정한 요청을 받아들일 수 있는 이유는 

그 요청에 대해 적절한 방식으로 응답하는데 

필요한 지식과 행동 방식을 가지고 있기 때문이다.

"책임"

어떤 객체가 어떤 요청에 대해 대답할 수 있거나, 

적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.

왕은 재판을 수행할 책임

토끼는 목격자를 불러올 책임

모자장수는 증언할 책임

- 객체지향개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것

- 책임을 어떻게 구현할 것인가 하는 문제는 객체와 책임이 제자리를 잡은후에 고려해도 늦지 않다.

책임의 분류

1. 하는 것 : 무엇을 하는가 (doing)

a. 객체를 생성하거나, 계산 등을 스스로 하는 것

b. 대른 객체의 행동을 시작하는 것

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

2. 아는 것 : 무엇을 알고 있는가 (knowing)

d. 개인적인 정보에 관해 아는 것

e. 관련된 객체에 관해 아는 것

f. 자신이 유도하거나 계산할 수 있는 것에 대해 아는 것

ex)

왕은 토끼에게 목격자를 불러오라 요청하고 모자장수에게 증언하라 요청한다.

- 다른 객체들의 활동을 제어하고 조율 (c)

토끼는 목격자가 누군지 알고 있고, 모자장수에게 증인석에 입장하도록 요청

- 관련된 객체에 아는 것 (e)

- 다른 객체의 행동을 시작시키는 것. (b)

모자장수는 스스로 증인석에 입장하는 책임과 알고있는 사실을 증언할 책임

- 객체를 생성하거나 계산을 하는 등을 스스로 하는 것 (a)

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

- 적절한 객체에게 적절한 책임을 할당하는게 중요하다.

책임은 객체의 외부에 제공해 줄 수 있는 정보 (아는 것의 측면)와 

외부에 제공해 줄 수 있는 서비스 (하는 것의 측면)의 목록이다

ex) MSA방식에서 다른 모듈에서 정보를 원할때

다른 점포정보라던가.. 찜한 상품 리스트라던가..이벤트리스트라던가..

따라서 책임은 객체의 공용 인터페이스를 구성한다. 

공용 인터페이스의 개념은 뒤에서 나올 캡슐화로 이어진다 (추후나옴)

책임과 메시지

설계를 시작하는 초반에는 어떤 객체가 어떤 책임을 가지고

어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것만으로 충분하다.

어떤 클래스가 필요하고 어떤 메서드를 포함해야 하는 지를 결정하는 것은 

책임과 메시지에 대한 대략적인 윤곽을 잡은 후에 시작해도 늦지 않다.

"역할"

역할이 재사용 가능하고, 유연한 객체지향 설계를 낳는 매우 중요한 요소.

ex) 재판 이어서

1. 누군가 왕에게 재판 요청

2. 왕이 토끼에서 증인을 부를것을 요청

3. 토끼가 "요리사"에게 증인석에 입장할것을 요청

4. "요리사"가 입장함으로 토끼의 요청에 응답 (2번에 대한 응답이기도 함)

5. 왕이 "요리사"에게 증언할것을 요청

6. "요리사"가 내용을 증언함으로 왕의 요청에 응답

왕이 피곤해서 여왕이랑 교체

1. 누군가 "여왕"에게 재판 요청

2. "여왕"이 토끼에서 증인을 부를것을 요청

3. 토끼가 "앨리스"에게 증인석에 입장할것을 요청

4. "앨리스"가 입장함으로 토끼의 요청에 응답 (2번에 대한 응답이기도 함)

5. "여왕"이 "앨리스"에게 증언할것을 요청

6. "앨리스"가 내용을 증언함으로 "여왕"의 요청에 응답

모든 과정이 동일하다. 이 세개의 협력을 별도록 관리하고 유지해야 하는가?

역할이 답이다. 

등장인물을 제외하고 모두 동일하기에 하나의 협력으로 다루면 된다.

판사 : 왕,여왕

증인 : 모자장수,요리사,앨리스

하나의 협력으로 추상화 

1. 누군가  "판사"에게 재판 요청

2. "판사"이 토끼에서 증인을 부를것을 요청

3. 토끼가 "증인"에게 증인석에 입장할것을 요청

4. "증인"가 입장함으로 토끼의 요청에 응답 (2번에 대한 응답이기도 함)

5. "판사"이 "증인"에게 증언할것을 요청

6. "증인"가 내용을 증언함으로 "판사"의 요청에 응답

역할을 이용해 협력을 추상화 했기 때문에

판사, 증인의 역할을 수행할 수 있는 어떤 객체라도 협력에 참여 할 수 있다. 

그러나 앨리스나 요리사가 판사가 될 수 없듯이 

역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정된다. 

역할의 개념을 사용하면, 

유사한 협력을 추상화해서 인지 과부하를 줄일수 있고 (단순성 simplicity )

다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해지며 (유연성 flexibility)

다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용이 높아진다. (재사용성 reusability)

< 협력의 추상화 >

왕  - 토끼 - 모자장수

왕  - 토끼 - 요리사

여왕- 토끼 - 앨리스

위의 구체적인 객체를 추상적인 역할로 대체함으로써

(판사- 토끼 - 증인)

하나의 추상적인 협력으로 대체할 수 있다.

따라서 역할을 이용하면 협력을 추상화함으로 단순화 할 수 있다.

< 대체 가능성 >

왕은 재판을 할 책임뿐만 아니라 국정을 돌봐야할 추가적인 책임

모자장수는 증인뿐만 아니라 모자를 판매할 본질적인 책임

앨리스는 잠시 증인뿐만 아니라 주인공으로서의 역할

결국 객체는 역할이 암시하는 책임보다 더 많은 책임을 가질 수 있다. 

3장에 나온 일반화/특수화 관계가 성립하는 것이 일반적이다.

"객체의 모양을 결정하는 협력"

흔한 오류

선입견

1. 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 선입견

2. 객체지향이 클래스와 클래스간의 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다는 선입견

왕의 인스턴스를 모델링할 경우 왕관을 쓰고 근엄하게 왕좌의 앉아있는 모습을 떠올리며

그 모습을 기반으로 클래스를 개발하면 안된다.

중요한것은 왕의 겉모습이 아니라 

앨리스 이야기에서 왕이 중요한 이유는 재판이라는 협력에 판사의 역할로 참여해서 

죄인의 죄를 판결하는 책임을 수행할 수 있는 것

" 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지 결정하는것이 객체지향의 핵심 "

협력을 따라 흐르는 객체의 책임

객체에게 책임을 할당하고 나면, 책임은 객체가 외부에 제공하게 될 행동이 된다.

앨리스의 이야기에서 누군가는 재판을 진행, 누군가는 증언을 하듯이 

협력을 구성하는데 필요한 일련의 책임을 먼저 고안하고 나면

그 책임을 수행하는데 필요한 객체를 선택하게 된다. 

어떤 책임은 왕에게, 어떤책임은 토끼에게, 어떤 책임은 모자장수에게 할당하면서 책임을 각 객체에 할당해 나간다.

이렇게 할당된 책임은 각각의 객체들이 외부에 제공하게 될 행동을 정의하게 된다.

"객체지향 설계 기법"

1. 책임 주도 설계 (Responsibility-Driven Design)

- 협력에 필요한 책임들을 식별하고, 적합한 객체에게 책임을 할당하는 방식

애플리케이션의 기능을 구현하기 위해 협력관계를 고안하고,

협력에 필요한 역할과 책임을 식별한 후 이를 수행할 수 있는 적절한 객체를 식별에 나가는 과정

객체지향 시스템을 설계하는 절차

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

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

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

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

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

역할,책임,협력에 집중하라.

2. 디자인 패턴 (Design Pattern)

- 전문가들이 반복적으로 사용하는 해결방법을 정의해 놓은 설계 템플릿 모음

3. 테스트 주도 개발 (Tet]st-Driven Development )

- 테스트를 먼저 작성하고, 테스트를 통과하는 구체적인 코드를 추가하면서 개발하는 방식

실패하는 테스트를 작성하고, 테스트를 통과하는 간단한 코드를 작성한 후 

리펙토링을 통해 중복을 제거하는 것.

다양한 설계 경험과 패턴에 대한 지식이 없는 사람들은 온전한 혜택을 누리기가 어렵다.

객체지향의 대한 깊이 있는 지식을 요구한다.