역할, 책임, 협력

협력

• 다수의 요청과 응답으로 구성
• 다수의 연쇄적인 요청과 응답의 흐름으로 구성
• 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의

책임

• 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.
• 책임의 분류
  • 무엇을 알고 있는가
    • 개인적인 정보에 관해 아는 것
    • 관련된 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
  • 무엇을 할 수 있는가
    • 객체를 생성하거나 계산을 하는 등 스스로 하는 것
    • 다른 객체의 행동을 시작 시키는 것
    • 다른 객체의 활동을 제어하고 조절하는 것
• 책임은 객체의 외부에 제공해 줄 수 있는 정보와 외부에 제공해줄 수 있는 서비스의 목록
  • 책임은 객체의 공용 인터페이스를 구성 → 캡슐화로 연결

책임과 메시지

• 협력 안에서 객체는 다른 객체로부터 요청이 전송됐을 경우에만 자신에게 주어진 책임을 수행
  • 한 객체가 다른 객체에게 전송한 요청은 요청을 수신한 객체의 책임이 수행되게 한다.
  • 이렇게 다른 객체에 주어진 책임을 수행하도록 요청을 보내는 것을 메시지 전송 이라 함
• 두 객체의 협력은 메시지 전송을 통해 이루어진다.
  • 송신자: 메시지를 전송해 협력을 요청
  • 수신자: 메시지를 받아 요청을 처리하는 객체
• 책임과 메시지
  • 책임: 협력이라는 문맥 속 요청을 수신하는 한 쪽의 객체 관점에서 무엇을 할 수 있는지 나열
  • 메세지: 협력에 참여하는 두 객체 사이의 관계를 강조
• 객체 지향의 설계
  • 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행하는지
  • 어떤 객체로부터 메시지를 수신할 것인지 결정
  • 이후 어떤 클래스가 필요하고 어떤 메서드를 포함해야 하는지를 결정한다.

역할

• 협력 안에서 역할의 의미: 해당 역할을 수행할 수 있는 어떤 객체라도 대신할 수 있다.
  • 판사가 왕이든 여왕이든 상관 없다.
  • 동일한 메시지를 이해할 수 있는 객체여야 한다.
• 동일한 역할을 수행하는 것 = 동일한 책임을 수행할 수 있다는 것
• 역할 개념의 장점
  • 유사한 협력을 추상화 해 인지 과부하를 줄일 수 있다.
  • 다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해진다.
  • 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.
  • 단순성, 유연성, 재사용성의 장점
• 협력의 추상화
  • 하나의 협력 안에 여러 종류의 객체가 참여할 수 있게 한다.
  • 설계자가 다뤄야 하는 협력의 개수를 줄인다.
  • 구체적인 객체를 추상적인 역할로 대체
  • 애플리케이션의 설계를 이해하고 기억하기 쉬워진다.
• 하지만 객체는 역할에 주어진 책임 이외에 다른 책임을 수행할 수도 있다.

  • 역할이 암시하는 책임보다 더 많은 책임을 가질 수 있음

    → 객체 타입과 역할 사이 일반화/특수화 관계 가 성립

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

• 흔한 오류
  1. 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다.

     • 객체가 존재하는 이유는 행위를 수행하며 협력에 참여하기 위함

       → 실제 중요한 것은 책임

  2. 객체지향이 클래스와 클래스 간의 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다.
     1. 협력에 참여하는 동적 객체가 중요한 것
     2. 클래스는 단지 시스템에 필요한 객체를 표현하고 생성하는 것

객체 설계

• 올바른 객체 설계를 위해서는 깔끔한 협력 설계가 필요

  • 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정한다는 것을 의미

    → 협력에 참여하기 위해 수행될 책임의 분배

  • 책임은 객체가 외부에 제공하게 될 행동
  • 객체가 수행할 적절한 책임을 결정한 후 클래스 구현 방법 결정
• 객체 지향은 올바른 객체에 올바른 책임을 할당하는 것과 관련된 모든 것
• 올바른 객체지향 애플리케이션을 구현하는 것은 협력이라는 문맥 안에서 객체를 생각하는 것
• 일단 협력이 갖춰지면 협력을 위해 필요한 책임이 결정된다.
  • 각 객체가 가져야 하는 상태와 행위 이전에 객체가 참여할 문맥인 협력의 정의가 필요

객체지향 설계 기법

1. 책임 주도 설계

• 협력에 필요한 책임 식별 → 적합한 객체에 책임 할당
• 시스템의 기능이 더 작은 규모의 책임으로 분할되고 각 책임은 수행할 적절한 객체에 할당
• 객체가 책임을 수행하는 도중에 스스로 처리할 수 없는 정보나 기능이 필요한 경우 적절한 객체를 찾아 요청
  • 객체들 간 협력 관계가 만들어진다.
• 책임을 여러 종류의 객체가 수행할 수 있다면 협력자는 객체가 아니라 추상적인 역할로 대체
• 개별적인 객체의 상태가 아닌 객체의 책임과 상호작용에 집중
• 설계 절차
  1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임 파악
  2. 시스템 책임을 더 작은 책임으로 분할
  3. 분할 된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임 할당
  4. 객체가 책임을 수행하는 중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
  5. 해당 객체 또는 역할에게 책임을 할당해 두 객체가 협력하게 한다.

2. 디자인 패턴

• 반복적으로 사용하는 해결 방법을 정의해놓은 설계 탬플릿의 모음
• 필요한 역할, 책임, 협력이 디자인 패턴 안에 이미 존재
• 책임-주도 설계의 결과 표현
• 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험

3. 테스트 주도 개발

• 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하며 애플리케이션을 완성해가는 방식
• 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템을 개발할 수 있게 함
• 객체가 이미 존재한다 가정하고 객체에게 어떤 메시지를 전송할 것인지에 관해 생각
  • 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지 작성