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

https://product.kyobobook.co.kr/detail/S000001766367

오브젝트 | 조영호 - 교보문고

책 목차:

1장 객체, 설계 : https://inhyeok-blog.tistory.com/32
2장 객체지향 프로그래밍 : https://inhyeok-blog.tistory.com/33
3장 역할, 책임, 협력 : https://inhyeok-blog.tistory.com/34
4장 설계 품질과 트레이드오프 : https://inhyeok-blog.tistory.com/36
5장 책임 할당하기 : https://inhyeok-blog.tistory.com/37
6장 메시지와 인터페이스 :
7장 객체 분해 :
8장 의존성 관리하기 :
9장 유연한 설계 :
10장 상속과 코드 재사용 :
11장 합성과 유연한 설계 :
12장 다형성 :
13장 서브클래싱과 서브타이핑 :
14장 일관성 있는 협력 :
15장 디자인 패턴과 프레임워크 :

---

2장에서 우리는 객체지향 프로그램을 구조화하는 기본적인 방법과 상속을 이용해 다형성을 구현하는 기법을 소개했다. 하지만 객제지향의 본질은 협력하는 개체들의 공동체를 창조하는 것이다.

01. 협력

영화 예매 시스템 돌아보기

 협력 : 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용

 책임 : 객체가 협력에 참여하기 위해 수행하는 로직

 역할 : 협력 안에서 수행하는 책임들이 모여 역할을 구성함

협력

 메시지 전송은 객체 사이에 협력을 하는 유일한 수단이다. 메시지를 받은 객체는 메시지를 처리할 메소드를 결정하고, 이는 객체가 자율적인 존재임을 보장한다. 객체는 내부 구현을 캡슐화 하는 방식으로 자율적인 존재가 되었고, 이로 인해 파급효과를 제한할 수 있게 되어서 변경에 용이해 질 수 있는 것이다.

 객체는 자신에게 할당된 책임을 수행하던 중에 도움이 필요한 경우 다른 객체에게 메시지를 보냄으로서 협력을 하게 되는 것이다. 

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

"어떤 객체도 섬이 아니다" : 애플리케이션 안에 어떤 객체도 협력하지 않는 객체는 없다.

 객체는 앞서 상태와 행동을 하나로 묶어둔 것이라고 말한바 있다. 그럼 앞선 예제에서 Movie는 어떤 행동과 상태를 가졌을까? 우리는 주로 '상영하기'와 같은 행동을 상상할 것이다. 하지만 그렇지 않았다. Movie는 요금을 계산하는 행동과 연관되어있다. 이는 Movie가 참여하고 있는 협력이 모두 영화 예매를 위해서였기 때문이다. 이렇게 객체의 행동은 협력을 통해 정해진다. 그렇다면 상태는 어떨까?

 상태는 행동에 의해서 결정된다. 객체의 행동이 정의되고 나면 필요한 상태들이 정의된다. 결국 상태 역시 협력에 의해서 결정되는 것이다. 결론적으로 협력은 객체를 설계하는 데 필요한 일종의 문맥(context)이다.

 

02. 책임

책임이란 무엇인가

 객체가 수행하는 행동을 책임이라고 부른다. 책임은 크게 하는 것과 아는 것으로 나누어 진다. 여기서 메시지와 협력은 다르다. 책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하는 것으로, 메시지 보다 추상적이고 크기도 더 크다. 따라서 개발을 하면서 책임이 여러개의 메시지로 구현되거나, 여러 객체로 분할되여 협력하게 되기도 한다. 

책임 할당

 INFORMATION EXPERT(정보 전문가) 패턴: 책임을 수행하는 데 필요한 정보를 가장 잘 알고있는 전문가에게 그 책임을 할당하는 것.

 Infromation Expert Pattern을 구현하기 위해서 우선 협력이라는 문맥을 정의해야한다. 협력을 설계하는 출발점은 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 바라보는 것이다. 그 이후 책임을 계속해서 나눠가는 과정이 바로 협력을 설계하는 방법이다. 정보 전문가에게 책임을 할당하는 것만으로도 상태와 행동을 함께 가지는 자율적인 객체를 만들 가능성이 높아진다.(어떤 경우에는 응집도와 결합도의 관점에서 정보 전문가가 아닌 다른 객체에게 책임을 할당하는 것이 더 적절한 경우도 있다.)

책임 주도 설계

 책임 주도 설계: 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법

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

메시지가 객체를 결정한다

 메시지가 객체를 선택하게 했다는 것은 두가지 이유에서 중요하다.

첫째, 객체가 최소한의 인터페이스를 가질 수 있게 된다.

둘째, 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.

-> 객체의 인터페이스는 무엇을 하는지 표현해야 하지만 어떻게 수행하는지를 노출해서는 안된다.

행동이 상태를 결정한다

 중요한 것은 상태가 아니라 행동이다.

 객체는 협력속에서 책임을 할당받아서 존재한다. 여기서 협력은 행동(메시지)으로만 가능하며, 상태는 이런 행동의 구현을 돕기 위한 재료에 불가하다.

 상태를 먼저 정의하고, 적당한 행동을 정하는 방식의 (즉, 구현에 초점을 맞춘) 설계 방법을 데이터-주도 설계라고 하는데, 이는 객체의 캡슐화를 저해한다.  

03. 역할

역할과 협력

 역할 : 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합(객체의 목적)

우리가 앞서 책임 주도 설계를 했을 때에도 최초에 객체를 선택하는 것 보다는, 역할을 찾고 그 역할을 수행하는 객체를 선택하는 방식으로 설계가 진행된 것이다.

 그런데 객체만으로도 충분히 협력을 설계할 수 있을 것 같은데, 왜 굳이 역할이라는 번거러운 과정을 추가한 것일까?

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

 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있다.

 우리가 만약 객체만으로 협력을 설계 했다면,DiscountPolicy는 어떻게 설계 할 수 있을까? 아마도 2가지 할인 정책을 따로따로 구현해야 했을 것이다. 코드 중복은 만악의 근원이며, 경직된 일회성 코드를 생산한다. 앞서 역할은 책임의 집합으로 정의한다 서술한 바 있다. 역할은 Interface, Abstract Class로 표현되는데, 이를 통해서 외부 인터페이스만 공개 하므로서 하나의 설계에서 다양한 구현을 사용할 수 있게 하며, 기능을 추가하기도 용이하게 만든다.

객체 대 역할

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

 협력을 설계할 때 단 하나의 객체만 있는 역할도 역할로 설계해야 할까? 아니다. 하나의 객체만 가진 역할은 그저 객체로 간주한다.

 트리그비 린스카우는 역할을 가리켜 실행되는 동안 협력 안에서 각자의 위치를 가지는 객체들에 대한 별칭이라고 정의한다. 그는 협력은 역할들의 상호작용으로 구성되고, 협력을 구성하기 위해 역할에 적합한 객체가 선택되는 것이라고 설명한다.

 하지만 초반 설계 단계에서는 어떤 것이 객체이고, 어떤 것이 역할인지 뚜렵하지 않은 경우가 많다. 이에 저자는 초반 설계 과정에서는 애매하면 전부 객체로 설계한 후에, 비슷한 방식의 협력이 존재한다면 이를 역할로 뽑아내는 방식을 추천한다. 

역할과 추상화

 앞서 언급한 추상화의 두 가지 장점은 역할에서도 동일하게 적용된다.(중요한 정랙을 상위 수준에서 단순화 할 수 있다는 것과 설계가 유연해 진다는 장점) 

배우와 배역

 영한님의 강의에서 역할과 객체를 배우와 배역에 비유해서 설명 했던 것이 기억 날 것이다.