본문 바로가기
더 좋은 개발자 되기/개발자 책읽기

[개발자 책 읽기] 객체지향의 사실과 오해-조영호 (4장 역할, 책임, 협력)

by Wonit 2021. 4. 9.

[개발자 책읽기] 객체지향의 사실과 오해-조영호 (4장 역할, 책임, 협력)

해당 글은 조영호님의 객체지향의 사실과 오해 역할, 책임, 협력, 관점에서 본 객체지향 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 객체지향의 사실과 오해 에서 확인해주세요.

객체지향의 사실과 오해 - 역할, 책임, 협력 관점에서 본 객체지향 (조영호)

  • 위키북스
  • 지은이: 조영호
  • 펴낸이: 박찬규, 엮은이: 이대엽, 디자인: 북누리
  • 1쇄 발행: 2015.06.17


이번 장에서 이야기하고자 하는 것

  • 이번 장에서는?
    • 협력이라는 문맥이 객체의 행동 방식을 결정
    • 객체지향에서 가장 중요한 것은 개별 객체가 아닌 객체 사이의 협력
      • 객체지향의 설계에서 품질은 여러 객체가 모여 이뤄내는 협력의 품질
      • 객체들간의 요청과 응답에서의 협력
    • 조화와 협력
  • 재판 속의 협력
    • 요청이 발생하는 이유는 특정한 목적을 달성하기 위함
    • 또한 응답이 발생하는 이유는 특정 목적을 달성하기 위함으로 요청의 이유와 동일
      • 요청은 연쇄적으로 발생하고 해당 요청을 응답하기 위해서는 다른 요청을 필요로 함
    • 요청과 응답에 협력하는 객체라면 협력을 위한 책임을 갖게됨
  • 책임
    • 책임 : 어떤 객체가 요청에 응답할 수 있거나 적절한 행동을 할 의무가 있는 경우
      • 객체에 의해 정의되는 응집도 있는 행위의 집합
      • 객체지향 개발에서 가장 중요한 능력은 책임을 어떻게 각각 객체에게 할당하는지
    • 책임의 분류 2가지
      • doing 하는 것
        • 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
        • 다른 객체의 행동을 시작하는 것
        • 다른 객체의 활동을 제어하고 조절하는 것
      • knowing 아는 것
        • 개인적인 정보에 관해 아는 것
        • 관련된 객체에 고나해 아는 것
        • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
  • 책임과 메시지
    • 객체들은 메시지를 기반으로 협력과 책임을 부여함
      • 책임 : 다른 객체로부터 요청이 전송된 경우, 책임을 수행 하도록 요청
      • 메시지 전송 : 다른 객체에게 주어진 책임을 다하도록 요청을 보내는 것
    • 객체지향 설계에서 설계 초반에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것으로 부터 출발
      • 어떠한 클래스가 어떤 메서드를 포함하는지, 어떤 것을 하는지는 책임과 메시지에 대한 대략적인 윤곽을 잡고 난 후 해도 괜찮음
  • 역할
    • 역할은 책임의 집합
    • 역할이 재사용 가능하고 유연한 객체지향을 위한 중요한 구성 요소임
    • 역할에 대한 상황을 가정해면,
      • 커피 전문점에 손님과 직원들로 구성되어 있다.
      • 역할을 나눠보자.
        • 손님
        • 캐셔
        • 바리스타
      • 더 크게 보면, 캐셔와 바리스타는 카페 직원 이라는 역할
      • 그럼 캐셔나 바리스타나 서로 손님의 요청(커피 주문)에 적절한 응답(커피 제공)을 해야 한다는 소리
      • 그럼 직원(캐셔, 바리스타)는 둘 중 누군가에게 손님이 커피를 주문한다고 하면 커피와 관련된 행동, 바리스타가 부재중이라면 캐셔가 커피를 만들거나 바리스타를 부름, 을 수행
      • 만약 손님에게 직원이 커피를 달라고 하면 손님은 어떻게 반응할까?
        • 이걸 봤을 때, 역할은 대체가 불가능한 역할이 있고 가능한 역할이 있음
        • 결국 역할에 따라서 행동을 추상화 하는 것이 가능
  • 협력의 추상화
    • 앞서 봤던 시나리오를 통해서 역할은 추상화가 가능하다는 것을 확인
    • 협력의 추상화는 설계자가 다뤄야 하는 협력의 개수를 줄이는 동시에 구체적인 추상적인 역할로 대체
      • 설계가 쉬워짐
    • 역할을 대체한다는 소리는 동일한 역할을 수행할 수 있는, 동일한 책임을 질 수 있는 가능성을 의미
  • 객체를 충분히 협력적으로 만든 후에 협력이라는 문맥 안에서 객체를 충분히 자율적으로 만들어야 함.
  • 객체지향 설계 기법
    • 책임 주도 설계
    • 디자인 패턴
    • 테스트 주도 개발

나의 해석과 회고

객체지향 설계 초기에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지 개요를 아는 것에서 부터 출발한다.

이 글을 읽고 나는 KSUG 세미나에서 조영호님이 애플리케잇녀 아키텍처와 객체지향 으로 발표하신 내용 중에, CRC 카드가 생각이 났다.

CRC 카드란?

 

 

Kent Beck 이 만든 객체지향 설계 도구로, 책임과 협력을 표현하기 위한 도구이다.

 

출처 : https://metakits.cc/writings/lab-for-oo/

우리 주변에 흔히 볼 수 있는 A4 용지, 노트, 이면지만 있으면 CRC 카드를 만들 수 있다.

 

더 자세한 내용은 추후에 따로 포스팅을 하겠지만, 간단하게 이야기 하자면 다음과 같다.

  • C : candidate, 객체
  • R : responsibility, 책임
  • C : Collaborator, 협력자

C : candidate

역할 또는 객체

R : responsibility, 책임

이 객체, candidate 가 어떤 일을 수행해야하는지 기술

C : Collaborator, 협력자

이 객체가, 해당 책임이 어떠한 행동을 위해 누구에게 요청 메시지를 보내야 하는지를 기술


영화 예메 생성 책임 할당 예제

영화 예매를 한다고 가정해보자.

예메 정보 생성

누군가가 예메를 한다 -> 예매 데이터를 생성한다.


그럼 누가 예메 데이터를 생성할까?


이 답을 찾기 위해서는 state, behavior을 누가 제일 많이 알고 있는지를 생각해보면 된다.


즉, 그 상태를 누가 제일 많이 이용하고 누가 제일 조작하는지에 따라서 책임이 부여되기 때문에!

 

  • 예메를 위해서는 showing 이 가장 많은 정보를 가지고 있기 때문에 책임 할당에 가정 적절한 객체

가격 계산 정보 생성

가격은 누가 제일 많이 알고 있을까?


Movie, 영화다.


영화에 따라서 가격이 있기 때문에

그럼 Showing은 Movie와 협력을 해야함

가격을 계산하기 위해서 할인 정책도 넣어보자.

그럼 할인 정보는 누가 제일 많이 가지고 있을까?

 

Strategy 에 할인 정책이 존재하므로 Strategy 와 Showing 을 협력시키자.

댓글