[Ch.3] 역할, 책임, 협력

오브젝트 : 코드로 이해하는 객체지향 설계 (조영호 저) 를 읽고 정리합니다.

역할, 책임, 협력

객체 = 협력이라는 연극 안에서 역할이라는 배역을 연기하는 배우

• 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것!
  • 기능 구현에 필요한 협력을 먼저 설계하고, 이후 클래스와 상속 등의 구현 메커니즘을 이용해 완성할 때 유연한 코드를 짤 수 있다.
• 동일한 객체(배우)라도, 참여하는 협력(연극)에 따라 역할(배역)이 계속 달라진다.
  • 따라서 특정 협력(연극) 안에서, 필요한 객체의 특정 역할(배역) 이외의 부분은 감춰진다.

1️⃣ 협력

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

• 객체지향 시스템은 자율적인 객체들의 공동체! 자기 일은 스스로 해야 한다.
  • 객체는 자율적이기 위해 필요한 정보와 정보에 기반한 행동만으로 구성되어야 한다 (캡슐화)
  • 따라서 객체는 자신이 할 수 없는 일을 다른 객체에게 요청하며, 이를 협력이라고 한다.
    • Ex. A객체는 자신이 할 수 없는 일을 B객체에게 요청(메시지 전송)하고, B객체는 필요한 메서드를 선택하여 실행해 요청에 응답한다.
• 협력은 객체 설계(= 객체에게 할당할 책임을 결정)에 필요한 문맥을 제공한다.
  • 협력은 객체의 행동을 결정하고, 행동은 객체의 상태를 결정한다.
    • 객체는 협력에 필요한 행동을 보유할 때만 어플리케이션에 필요하기 때문!

2️⃣ 책임

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

• 책임은 객체가 유지해야 하는 정보와 수행할 수 이는 행동에 대해 개략적으로 서술한다.
  • '하는 것' 책임
    • 객체가 '하는' 책임을 수행하기 위해선 '아는' 책임이 필요하다.
    • Ex. 객체를 생성하거나, 계산을 수행하거나, 다른 객체에게 도움을 요청하거나...
  • '아는 것' 책임
    • 객체는 자신이 맡은 책임을 수행하는데 필요한 정보를 알 책임이 있다.
    • 객체는 자신이 할 수 없는 일을 도와줄 객체를 알고 있을 책임이 있다.
    • Ex. 사적인 정보에 대해 알거나, 관련된 객체에 대해 알거나, 내가 할 수 있는 걸 알거나...
• 객체가 할 수 있는 행동들을 종합적으로 서술한다는 점에서 메시지보다 추상적이고 큰 개념!
  • 따라서 객체에게 얼마나 적절한 책임을 할당하는지가 설계에서 굉장히 중요!
• 보통 정보 전문가 패턴을 이용해 책임을 할당한다.
  • 정보 전문가 패턴 : 책임 수행에 필요한 정보를 가장 잘 알고있는 전문가에게 책임을 할당하는 것
    • 보통 일 시킬 때 잘 하는, 잘 아는 사람한테 시킨다. 똑같은 이유~
    • 물론 응집도와 결합도의 관점에서, 다른 방식이 더 적절할 수도 있다. 고냥 보통은 이렇게 한다고~
  • 협력이라는 문맥 안에서 더 작은 책임을 찾고, 그 책임의 적임자를 찾아 할당하는 과정을 반복하며 설계가 이루어진다.
    • 이 과정(책임 주도 설계)을 통해 퍼블릭 인터페이스를 구성할 수도 있다!

📌 책임에 집중하는 책임 주도 설계

• 책임이 협력에 참여할 객체를 결정하도록, 객체의 구현보다는 책임에 집중할 때 유연한 시스템이 된다.
• 단, 책임을 할당할 때는 아래를 고려한다.
  • 메세지가 객체를 결정한다.
    • (1) 식별된 메세지를 기반으로 인터페이스를 구성하기 때문에, 객체가 최소한의 인터페이스를 가질 수 있게 된다.
    • (2) 외부 객체가 요청하는 케이스를 고려할 수 있으므로, 메세지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 추상적인 인터페이스를 가질 수 있게 된다.
  • 행동이 상태를 결정한다.
    • 다른 객체로부터 '무엇을 얻어야 하는지' 고민할 때, 즉 협력에 초점을 맞출 때 높은 응집도와 낮은 결합도를 구현할 수 있다.
    • 협력에 적합한지를 판단하는 기준은 행동! 상태를 기준으로 설계할 때 내부 구현과 퍼블릭 인터페이스의 의존도가 높아진다.

3️⃣ 역할

협력 안에서 특정 객체가 수행하는 책임들이 모인 것

• 책임의 할당은 (1) 적절한 역할이 뭔지 찾고 (2) 그 역할을 수행할 객체를 선택하는 과정으로 이루어진다.
  • 동일한 책임을 수행하는 역할을 기반으로 다수의 협력을 하나로 통합할 수 있다.
    • 즉, 역할을 이용해 불필요한 코드의 중복을 방지하고, 유연한 협력을 구현할 수 있다.
• 설계 초반에는 책임과 협력을 탐색하며 큰 그림을 그리는 것에 집중하자.
  • 일단 구체적인 객체들로 시작하고, 이후 유사한 협력들을 합치다보면 역할을 나눌 수 있을 것!
    • 역할의 기준
      • 협력에 적합한 책임을 수행하는 대상이 한 종류 -> 객체
      • 반대로 대상이 여러 종류가 될 수 있다면? -> 역할
  • 역할을 중심으로 역할 모델링을 시도할 때, 설계의 구성 요소를 추상화할 수 있다.
    • 역할은 모양이나 구조가 아닌, 시스템 문맥 안에서 무엇을 하는지에 의해 정의한다.
• 역할을 슬롯이라는 관점으로 이해하자!
  • 동일한 책임을 수행하는 객체는 동일한 역할을 수행하기에 서로 대체할 수 있다.
  • 따라서 역할이라는 추상화를 이용할 때, 새로운 기능을 구현할 때 유연하게 처리할 수 있다.