[객체지향의 사실과 오해] Chapter4. 역할, 책임, 협력

04. 역할, 책임, 협력

인간의 행동은 "어떤 상황에 처해 있는가"가 결정한다.

즉, 각 개인이 처해 있는 정황과 문맥이 행동방식을 결정하고, 결정하는 문맥은 타인과의 협력이다.

객체지향 설계로 옮겨 보면, 결국 객체사이의 협력이 행동을 결정한다.

협력

요청하고 응답하며 협력하는 사람들

• 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작된다.
  • 스스로 해결하기 어려운 문제에 부딪히게 되면 도와줄 수 있는 사람에게 요청한다.
• 요청을 받은 사람은 요청한 사람에게 원하는 지식이나 서비스를 응답한다.
• 결과적으로 협력은 다수의 요청과 응답으로 구성되며 즉, 협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성

책임

• 어떠한 요청에 대해서 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 책임을 가진다고 말한다.

책임의 분류

• 협력에 참여하는 객체는 책임을 수행한다.
• 객체에 의해 정의되는 행위의 집합
  • 객체가 알아야 하는 정보
  • 객체가 수행할 수 있는 행위

1. 하는 것(Doing)
   • 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
   • 다른 객체의 행동을 시작시키는 것
   • 다른 객체의 활동을 제어하고 조절하는 것
2. 아는 것(Knowing)
   • 개인적인 정보에 관해 아는 것
   • 관련된 객체에 대해 아는 것
   • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

• 책임은 객체의 공용 인터페이스(public Interface)를 구성한다.
  • 외부에 제공해 줄 수 잇는 정보(아는 것)
  • 외부에 제공해 줄 수 있는 서비스(하는 것)

책임과 메시지

• 한 객체가 다른 객체에게 전송한 요청은 그 요청을 수신한 객체의 책임이 수행되게 한다.
• 이를 메시지 전송이라 한다.
• 책임이 협력에서 무엇을 할 수 있는지 나열하는 것, 메시지는 관계를 강조한 것
  • 책임은 상대 객체와 상관없이 외부에 제공하는 행위나 정보
  • 메시지는 상호 협력하는 문맥이 강조 된다.
• 메시지 != 책임
  • 책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 개략적으로 서술한 것이다.
  • 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는게 일반적

역할

책임의 집합이 의미하는 것

• 객체가 수행하는 책임의 집합은 결국 협력 안에서 수행하는 역할을 암시한다.
• 역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 중요한 구성요소
• 동일한 역할을 수행할 수 있다는 것 == 협력 내에서 동일한 책임의 집합을 수행할 수 있다

즉 역할의 개념을 사용하면 협력을 추상화해서 인지의 과부화를 막는다.

• 역할은 객체지향 설계의 단순성, 유연성, 재사용성을 돕는다.

대체 가능성

• 역할은 협력에서 구체적인 객체로 대체될 수 있는 추상적인 협력자.
  • 역할은 다른 객체에 의해 대체가 가능하다.
• 대체가 가능하기 위해서는 협력 안에서 역할이 수행하는 모든 책임을 동일하게 수행할 수 있어야 한다.
• 하지만, 객체는 역할의 책임 뿐 아니라 더 많은 책임을 수행할 수 있다.
  • 객체와 역할 사이에는 일반화/특수화 관계가 일반적으로 성립한다.

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

흔한 오류

• 데이터를 저장하기 위해 객체가 존재한다.
  • 아니다. 객체는 행위를 수행하며 협력에 참여하기 위해서 존재한다.
• 객체지향이 클래스와 클래스 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다.
  • 아니다. 중점은 협력에 참여하는 동적인 객체이며, 클래스는 필요한 객체를 표현하고 생성하기 위한 메커니즘

객체지향 설계 기법

책임-주도 설계(RDD, Responsibility-Driven Design)

• 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식.
• UML이나 객체를 그린다고 견고한 객체지향이 보장되지 않는다.
• RDD 시나리오
  • 시스템의 기능은 더 작은 책임으로 분할된다.
  • 책임을 적절히 수행할 객체에게 할당한다.
  • 객체가 수행하지 못할 경우 필요한 작업을 요청한다.
  • 요청된 작업을 수행하는 일은 위임받은 객체의 책임으로 변환된다.
  • 결과적으로 요청한 객체와 받은 객체의 협력이 만들어진다.
• 자신을 책임질 수 있을 정도로 충분히 자율적이며, 우호적으로 협력할 수 있는 생테계를 구축한다.

디자인 패턴

• 전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 템플릿의 모음
• 해결하려고 하는 문제가 무엇인지를 명확하게 서술하고, 패턴을 적용할 수 있는 상황과 없는 상황을 함께 설명한다.
• 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿
• RDD의 결과물인 동시에 지름길

테스트-주도 개발(Test-Driven Development)

• 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 완성해가는 방식
• 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템을 개발할 수 있게 하는 최상의 방법.
• 테스트를 작성하는 것
  • 객체의 메서드를 호출하고, 반환값을 검증하는 것 => 객체의 책임
• 테스트에 필요한 값이나 목 객체(Mock object)를 사용하는 것
  • 다른 객체와 협력을 표현한 것