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

 

객체지향 패러다임의 핵심은 역할(role), 책임(responsibility), 협력(collaboration)이다.

객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다. 

 

1. 협력

영화 예매 시스템 돌아보기

영화 예매라는 기능을 완성하기 위해 객체들이 서로 메시지를 주고 받으며 상호작용하고 있다. 

 

 

 

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

 

이처럼 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다. 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다. 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.

 

협력

객체지향 시스템은 자율적인 객체들의 공동체이다. 이 객체는 고립된 존재가 아니라 다른 객체들과 협력하여 시스템을 완성해야 하는 사회적 구성원이다. 협력은 객체지향의 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 객체의 협력에 사용되는 유일한 수단은 메시지 전송(message sending)이다. 다른 객체의 내부를 살피는 것이 아니라 메시지 전송을 통해 자신의 요구 사항을 전달한다. 

메시지를 수신한 객체는 자신만의 메서드로 요청을 처리하여 응답한다. 

자율적인 객체는 자신에게 할당된 책임을 수행하던 중에 필요한 정보를 알지 못하거나 외부의 도움이 필요한 경우 적절한 객체에게 메시지를 전송해 협력을 요청한다. 메시지를 수신한 객체 역시 메시지를 처리하던 중에 직접 처리할 수 없는 정보나 행동이 필요한 경우 또 다른 객체에게 도움을 요청한다. 이처럼 객체들 사이의 협력을 구성하는 일련의 요청과 응답의 흐름을 통해 애플리케이션의 기능이 구현된다. 

 

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

 

 

어떤 객체도 섬이 아니다.
No object is an island.
켄트 벡

 

애플리케이션 안에 어떤 객체가 필요하다면 그 이유는 단 하나여야 한다. 그 객체가 어떤 협력에 참여하고 있기 때문이다. 그리고 객체가 협력에 참여할 수 있는 이유는 협력에 필요한 적절한 행동을 보유하고 있기 때문이다. 

결론적으로 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다. 협력이 바뀌면 객체가 제공해야 하는 행동 역시 바뀌어야 한다. 협력은 객체가 필요한 이유와 객체가 수행하는 행동의 동기를 제공한다. 

 

객체의 행동을 결정하는 것이 협력이라면 객체의 상태를 결정하는 것은 행동이다. 객체의 상태는 그 객체가 행동을 수행하는 데 필요한 정보가 무엇인지로 결정된다. 객체는 자신의 상태를 스스로 결정하고 관리하는 자율적인 존재이기 때문에 객체가 수행하는 행동에 필요한 상태도 함께 가지고 있어야 한다. 

 

Movie 객체가 기본 요금인 fee와 할인 정책인 discountPolicy라는 인스턴스 변수를 상태의 일부로 포함하는 이유는 요금 계산이라는 행도응ㄹ 수행하는 데 이 정보들이 필요하기 때문이다. 

 

상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고 행동은 협력 안에서 객체가 처리할 메시지로 결정된다. 결과적으로 객체가 참여하는 협력이 객체를 구성하는 행동과 상태 모두를 결정한다. 따라서 협력은 객체를 설계하는 데 필요한 일종의 문맥(context)을 제공한다. 

 

2. 책임

책임이란 무엇인가

객체를 설계하기 위해 필요한 문맥인 협력이 갖춰지면 이제 협력에 필요한 행동을 수행할 수 있는 적절한 객체를 찾아야 한다. 이때 협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 한다. 

객체의 책임을 크게 하는 것(doing)과 아는 것(knowing)의 범주로 나누어 살펴볼 수 있다.

 

하는 것

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

아는 것

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

 

예제로 돌아와서 Screening, Moive, DiscountPolicy, DiscountCondition의 책임에 대해 살펴보자.

 

• Screening
  • 상영 정보를 알고 있다.
  • 예매 정보를 생성한다.
• Movie
  • 영화 정보를 알고 있다.
  • 가격을 계산한다.
• DiscountPolicy
  • 할인 정책을 알고 있다.
  • 할인 정책을 계산한다.
• DiscountCondition
  • 할인 조건을 알고 있다.
  • 할인 여부를 판단한다.

 

객체는 자신이 맡은 책임을 수행하는 데 필요한 정보를 알고 있을 책임이 있다. 또한 객체는 자신이 할 수 없는 작업을 도와줄 객체를 알고 있을 책임이 있다. 어떤 책임을 수행하기 위해서는 그 책임을 수행하는 데 필요한 정보도 함께 알아야 할 책임이 있는 것이다.

 

책임은 객체지향 설계의 핵심이다. 

 

책임 할당

자율적인 객체를 만드는 가장 기본적인 방법은 책임을 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것이다. 이를 책임 할당을 위한 INFORMATION EXPERT(정보 전문가) 패턴이라고 부른다. 협력에 필요한 지식과 방법을 가장 잘 알고 있는 객체에게 도움을 요청한다. 요청에 응답하기 위해 필요한 이 행동이 객체가 수행할 책임으로 이어지는 것이다. 

 

객체에게 책임을 할당하기 위해서는 먼저 협력이라는 문맥을 정의해야 한다. 협력을 설계하는 출발점은 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 바라보는 것이다 객체지향 설게는 시스템의 책임을 완료하는 데 필요한 더 작은 책임을 찾아내고 이를 객체들에게 할당하는 반복적인 과정을 통해 모양을 갖춰간다. 

 

객체지향 설계는 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해 이뤄진다. 그리고 이런 메시지가 메시지를 수신할 객체의 책임을 결정한다. 협력을 설계하면서 객체의 책임을 식별해 나가는 과정에서 최종적으로 얻게 되는 결과물은 시스템을 구성하는 객체들의 인터페이스와 오퍼레이션의 목록이다. 

물론 모든 책임 할당 과정이 이렇게 단순한 것은 아니다. 어떤 경우에는 응집도와 결합도의 관점에서 정보 전문가가 아닌 다른 객체에게 책임을 할당하는 것이 더 적절한 경우도 있다.

 

책임 주도 설계

어떤 책임을 선택하느냐가 전체적인 설계의 방향과 흐름을 결정한다. 이처럼 책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법을 책임 주도 설계(Responsibility-Driven Design)라고 부른다.

 

책임 주도 설계 과정

 

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

구현이 아닌 책임에 집중하는 것이 중요한 이유는 유연하고 견고한 객체지향 시스템을 위해 가장 중요한 재료가 바로 책임이기 때문이다.

 

메시지가 객체를 결정한다

메시지가 객체를 선택하게 해야 하는 두 가지 중요한 이유

 

1. 객체가 최소한의 인터페이스(minimal interface)를 가질 수 있게 된다.
2. 객체는 충분히 추상적인 인터페이스(abstract interface)를 가질 수 있게 된다.

 

행동이 상태를 결정한다

객체를 객체답게 만드는 것은 객체의 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다.

초보자들은 먼저 객체에 필요한 상태가 무엇인지를 결정하고, 그 후에 상태에 필요한 행동을 결정한다. 이런 방식은 객체의 내부 구현이 객체의 퍼블릭 인터페이스에 노출되도록 만들기 때문에 캡슐화를 저해한다. 객체의 내부 구현에 초점을 맞춘 설계 방법을 데이터-주도 설계(Data-Driven Design)라고 부른다.

 

 

3. 역할

역할과 협력

객체의 목적은 협력 안에서 객체가 맡게 되는 책임의 집합으로 표시된다. 이처럼 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다. 실제로 협력을 모델링할 때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하는게 좋다.

 

예를 들어 영화 예매에서 예매하라라는 메시지를 처리하기에 적합한 객체로 Screening을 선택했다. 사실 이 과정은 한단계 처럼 보이지만 실제로는 두 개의 독립적인 단계가 합쳐진 것이다. 첫번째 단계는 영화를 예매할 수 있는 적절한 역할이 무엇인가를 찾는 것이고, 두 번째 단계는 역할을 수행할 객체로 Screening 인스턴스를 선택하는 것이다. 역할에 특별한 이름을 부여하지는 않았지만 실제로는 익명의 역할을 찾고 그 역할을 수행할 수 있는 객체를 선택하는 방식으로 설계가 진행됐다고 생각하는 것이 자연스럽다.

 

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

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

역할은 다른 것으로 교체할 수 있는 책임의 집합이다. 특정 역할을 수행할 수 객체라면 어떠한 객체로 바꿔 끼워도 상관 없는 것이다.

 

객체 대 역할

오직 한 종류의 객체만 협력에 참여하는 상황에서 역할이라는 개념을 고려하는 것이 유용할까?

 

역할이라는 개념을 생략하고 직접 객체를 이용해 협력을 설계하는 것이 더 좋지 않을까?

 

이런 경우에 역할을 사용하는 것은 상황을 오히려 더 복잡하게 만드는 것은 아닐까?

 

대부분의 경우 어떤 것이 역할이고 어떤 것이 객체인지가 또렷하게 드러나지 않는다. 도메인 모델은 필연적으로 불완전성을 가질 수 밖에 없다. 

 

설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요하고, 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지 않다고 저자는 말하고 있다. 따라서 애매하다면 단순하게 객체로 시작하고 반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다.

 

다양힌 시나리오를 탐색하고 유사한 협력들을 단순화하고 합치다 보면 자연스럽게 역할이 그 모습을 드러낼 것이다. 

 

역할과 추상화

추상화의 장점은 중요한 정책을 상위 수준에서 단순화할 수 있다는 것과 설계가 좀 더 유연해진다는 것이다. 

역할은 객체의 추상화로 볼 수 있기에 추상화가 가지는 장점을 협력의 관점에서 역할에도 동일하게 적용될 수 있다. 

 

배우와 배역

 

연극의 배역과 배우 간의 관계에는 다음과 같은 특성이 존재한다.

 

• 배역은 연극 배우가 특정 연극에서 연기하는 역할이다.
• 배역은 연극이 상영되는 동안에만 존재하는 일시적인 개념이다.
• 연극이 끝나면 연극 배우는 배역이라는 역할을 벗어 버리고 원래의 연극 배우로 돌아온다.

 

위의 사실로부터 연극의 배역과 배우 간에는 다음과 같은 추가적인 특성이 존재한다는 사실을 알 수 있다.

 

• 서로 다른 배우들이 동일한 배역을 연기할 수 있다.
• 하나의 배우가 다양한 연극 안에서 서로 다른 배역을 연기할 수 있다.

 

연극 안에서 배역을 연기하는 배우라는 은유는 협력 안에서 역할을 수행하는 객체라는 관점이 가진 입체적인 측면들을 훌륭하게 담아낸다. 

역할은 특정한 객체의 종류를 캡슐화하기 때문에 동일한 역할을 수행하고 계약을 준수하는 대체 가능한 객체들은 다형적이다.

 

---

느낀점

 

"행동이 상태를 결정한다."를 어어어엄청 강조!

 

오직 한가지 역할만하는 객체에게 역할을 부여할 것인가 객체 그대로 존재하게 둘것인가에 대한 고민도 많이 해봐야겠다.

무조건 역할만 부여하는 것이 오히려 독이 될수도...?