Carrey`s 기술블로그 HomeArchivesTagsCategories
Objects Study - Chapter3. 역할, 책임, 협력

역할, 책임, 협력

객체지향 패러다임의 관점에서의 핵심은 역할(role), 책임(responsibility), 협력(collaboration)이다.
애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지 고민하지 않은 채 너무 이른 시기에 구현에만 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다.

  • 협력: 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용
  • 역할: 객체들이 협력안에서 수행하는 책임들을 일컫는 말 (= 인터페이스라 의역하면 이해가 쉽다)
  • 책임: 객체가 협력에 참여하기 위해 수행하는 로직 (= 인터페이스 구현체 또는 객체)

협력

협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다.
하나의 객체가 모든 일을 처리하는 것이 아닌 각각의 역할을 수행할 수 있는 객체들간의 메세지 전송이라는 커뮤니케이션 수단을 이용하여 객체 간 협력을 통해 애플리케이션 기능을 수행할 수 있다.

협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것이다.
한 객체는 어떤 것이 필요할 때 다른 객체에게 전적으로 위임하거나 서로 협력한다.
즉, 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다.
객체 사이의 협력을 설계할 때는 객체를 서로 분리된 인스턴스가 아닌 협력하는 파트너로 인식해야한다.

자율적인 객체는 자신에게 할당된 책임을 수행하던 중 필요한 정보를 알지 못하거나 외부의 도움이 필요한 경우 적절한 객체에게 메세지를 전송해서 협력을 요청한다.

객체들 사이의 협력을 구성하는 일련의 요청과 응답을 통해 애플리케이션의 기능이 구현된다.

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

  • 애플리케이션 안에서 객체가 필요하다면 그 이유는 단 하나여야 한다. (그 객체가 어떠한 협력에 참여하고 있기 때문)
  • 객체가 협력에 참여할 수 있는 이유는 협력에 필요한 적절한 행동을 가지고 있기 때문이다.
  • 객체는 행동(action)과 상태(state)로 구성된다.
    • 행동(action)은 협력 안에서 객체가 처리할 메세지
    • 상태(state)는 객체가 행동하는데 필요한 정보
  • 협력은 객체를 설계하는데 필요한 일종의 context를 제공한다.

책임

책임이란, 협력에 참여하기 위해 객체 수행하는 행동(action)이라 부른다.
책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합으로 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장이다.
즉, 객체의 책임은 ‘무엇을 알고 있는가’, ‘무엇을 할 수 있는가’ 로 구성된다.

하는 것

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

아는 것

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

책임은 객체지향 설계의 핵심이다.
객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것
사실 협력이 중요한 이유는 객체에게 할당할 책임을 결정할 수 있는 문맥을 제공하기 때문이다.

책임 주도 설계

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

책임 주도 설계 방법

  1. 시스템이 사용자에게 제공해야 하는 기능인 시스템의 책임을 판단한다.
    • sms 전송요청 받은 요청을 sms로 보낼 수 있다.
  2. 시스템 책임을 더 작은 책임으로 분할한다.
    • sms 요청을 가공한다.
    • 가공된 sms 요청을 벤더사로 전송한다.
  3. 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
    • sms 요청을 가공한다. -> MessageTransformer
    • 가공된 sms 요청을 벤더사로 전송한다. -> MessageVenderSender
  4. 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
    • sms 요청을 Template 기반으로 변경한다. -> TemplateMessageTransformer
    • 발신번호가 예전 번호인 경우 신규 발신번호로 변경한다. -> LegacySendNumberExchanger
  5. 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

예시

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
class SmsSendRequest(
  private val sendNo: String,
  private val recipientNo: String,
  private val templateId: String
)

interface MessageTransformer {
  fun transform(smsSendRequest: SmsSendRequest): VendorMessageSendRequest
}

class TemplateMessageTransformer(
  private val templateLoader: TemplateLoader
): MessageTransformer() {
  override fun transform(smsSendRequest: SmsSendRequest): VendorMessageSendRequest {
    val template = templateLoader.findByTemplateId(templateId)
    return VendorMessageSendRequest(
      sendNo = smsSendRequest.sendNo,
      recipientNo = smsSendRequest.reciepientNo,
      title = template.title,
      contents = template.contents
    )  
  }
}


class SmsSendProcessor(
  private val messageTransformer: MessageTransformer
  private val legacySendNumberExchanger: LegacySendNumberExchanger
  private val messageVenderSender: MessageVenderSender
) {
  fun sendSms(smsSendRequest: SmsSendRequest) {
    
    legacySendNumberExchanger.exchange(smsSendRequest)
    val vendorMessageSendRequest = messageTransformer.transform(smsSendRequest)
    
    messageVenderSender.sendTo(vendorMessageSendRequest)
  }
}

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

객체에게 책임을 할당하는 데 필요한 메세지를 먼저 식별하고 메세지를 처리할 객체를 나중에 선택하는 것이 중요하다

이유는 2가지가 있다.

  1. 객체가 최소한의 인터페이스를 가질 수 있게 된다.
    • 필요한 메세지가 식별될 때까지 객체의 퍼블릭 인터페이스에 어떤 것도 추가하지 않게 된다.
    • 객체는 꼭 필요한 퍼블릭 인터페이스만 가질 수 있다.
  2. 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.
    • 객체의 인터페이스는 무엇을 하는지?는 표시해야하지만 어떻게 하는지는 노출하면 안된다.
    • 메세지는 외부의 객체가 요청하는 무언가를 의미하기 때문에
      메세지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 인터페이스를 얻을 수 있다.

행동이 상태를 결정한다.

객체가 존재하는 이유는 협력에 참여하기 위해서다.
따라서 객체는 협력에 필요한 행동을 제공해야 한다.
그렇기 때문에 객체는 상태보다는 행동에 초점을 맞춰야 한다.

적절한 객체를 만들었는지에 대한 기준은 얼마나 적절한 책임을 할당했느냐에 달려 있고, 책임이 얼마나 적절한지는 협력에 얼마나 적절한가에 달려있다.

객체지향 패러다임에서 가장 쉽게 하는 실수는 객체의 행동이 아니라 상태에 초점을 맞추는 것이다.
객체의 행동을 고려하지 않고 일단 필드부터 정의하고 보는 행동이다.
이런 방식은 객체의 내부 구현이 객체의 퍼블릭 인터페이스에 노출되도록 만들기 때문에 캡슐화를 저해한다.

상태란, 단지 객체가 행동을 정상적으로 수행하기 위해 필요한 재료에 지나지 않는다.

역할

객체는 협력이라는 주어진 문맥 안에서 특정한 목적을 갖게 된다.
객체의 목적은 협력 안에서 객체가 맡게 되는 책임의 집합으로 표시된다.
이처럼 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.

역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다. (like 인터페이스)
인터페이스와 같이 협력 안에서 객체를 바꿔낄 수 있는 슬롯의 역할을 한다.

따라서 책임과 역할을 중심으로 협력을 바라보는 것이 바로 변경과 확장이 용이한 유연한 설계로 나아가는 첫걸음이다.

객체 vs 역할

만약 오직 한 종류의 객체만 협력에 참여하는 상황이라면 역할이라는 개념을 추가하는 것이 과연 좋을까?
역할의 개념을 생략하고 바로 협력에 객체를 이용하는 것이 좋지 않을까?
(spring에서 하나의 service를 사용하는 과정에서 굳이 인터페이스를 만들어야 할까 말아야 할까와 같다)

레베카 워브스브록은

협력에 참여하는 후보가 여러 종류의 객체에 의해 수행될 필요가 있다면 그 후보는 역할이 되지만,
단지 한 종류의 객체만이 협력에 참여할 필요가 있다면 후보는 객체가 된다.

(즉, 하나의 Service만 필요하다면 클래스 기반의 Service를 만들면 되고, 2개 이상의 Service가 필요하다면 인터페이스 기반의 Service를 만들면 된다.)

만약 서비스 개발 초반에 역할과 객체를 구분하는 것이 애매하다면 일단 객체로 시작해보자
객체로 시작하게 되면 자연스럽게 반복되고 중복되는 코드가 등장하게 되고 그때 역할로 분리해 내면 된다.

협력을 구체적인 객체가 아니라 추상적인 역할의 관점에서 설계하면 협력이 유연하고 재사용이 가능해진다.
역할의 가장 큰 장점은 설계의 구성 요소를 추상화할 수 있다는 점이다.

역할과 추상화

추상화는 2가지 장점이 있다.

  1. 추상화 계층만을 이용하면 중요한 정책을 상위 수준에서 단순화 할 수 있다.
    • 역할은 공통의 책임을 바탕으로 객체의 종류를 숨기기 때문에 이런 관점에서 역할을 객체의 추상화로 볼 수 있다.
    • 협력이라는 관점에서는 세부적인 구현보다는 추상적인 책임에 집중하는게 유용하다.
  2. 설계가 좀 더 유연해 진다.
    • 역할은 다양한 종류의 객체를 끼워 넣을 수 있는 슬롯이기 때문에 서로 대체가 가능하다
    • 역할은 다양한 환경에서 다양한 객체들을 수용할 수 있게 해주기 때문에 협력에 유연하다

참고

  • Objects(코드로 이해하는 객체지향 설계) - Chapter3. 역할, 책임, 협력
Object-Study