[오브젝트] ch03 역할, 책임, 협력

OOP 패러다임의 본질은 협력하는 객체들의 공동체를 만드는 것

“객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다.”73p

하지만 적절하다는 표현에 대한 의구심은 들었다.

적절하다는 것은 이미 경험해본 사람만이 정할 수 있는 것 아닌가 와 경험해 본 사람들 간에서도 차이가 있을 수 있다.

아직은 초반이니 그려러니하고 우선 읽어 나아가 보고 적용해 봐야 저 말의 의미를 조금은 알 수 있겠다 싶다.

협력

“객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다.”74p

“객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다.”75p

“객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.”75p

협력 → 책임 → 역할 순서로 영향을 주고 있다

 

“두 객체들 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다.”75p

“메시지 전송(message sending)은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다.”75p

OOP 안에서의 이야기이지만 메시지 전송이라 표현되니 서버와 클라이언트 간의 요청과 응답이 떠오른다.

 

 책 속 예시에서 자율성이 훼손 되는 점이 있었다.

영화 예매를 할 때 Screening이 Movie의 정보를 이용해 요금을 계산하는 경우, 정보와 행동이 Movie, Screening이라는 별도의 객체로 나뉘고 그로 인해 Movie는 자율적인 존재가 아니라 수동적인 존재가 된다.

 

해결을 위해서는 Movie가 자신이 알고 있는 정보를 이용하여 직접 요금을 계산해야 한다.

Screening이 Movie에게 요금을 계산하도록 위임하는 이유가 된다고 한다.

객체를 자율적으로 만들기 위해 내부 구현을 캡슐화할 수 있다 하고 협력할 때 위에서 적은 것처럼 요청만 하고 어떻게 만들라고 할지는 관여하지 않는 것이 객체지향적인 처리라 느껴졌다.

 

from: 123rf

같은 저자분이 쓴 “객체지향의 사실과 오해”에 나오는 커피숍 예시가 떠오른다.

고객-점원-바리스타가 있을 때, 고객은 메뉴를 주문하고 점원은 받은 메뉴 주문을 바리스타에게 만들어달라고 요청한다.

메뉴를 만들어달라 요청할 뿐 어떻게 만들어야 할지는 요청받은 객체가 처리해야 할 부분이라 하여 이 점이 자율성과 연결된다 싶었다.

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

 

“객체란 상태와 행동을 함께 캡슐화하는 실행단위이다” 76p

객체는 섬이 아니다

객체가 필요한 이유는 그 객체가 어떤 협력에 참여하고 있기 때문.

“객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다” 77p

“협력이 바뀌면 객체가 제공해야 하는 행동 역시 바뀌어야 한다.”77p

“협력은 객체가 필요한 이유와 객체가 수행하는 행동의 동기를 제공한다” 77p

 

객체를 만들려면 결국 협력이 중요하고 협력이 객체의 행동을 결정하니까 프로그램을 객체 지향으로 설계한다 했을 때 어떻게 해야 할지 싶다.

나라면 일단 대략적인 프로그램 흐름을 서술하고 시나리오를 짤 거 같다.

이 틈에서 협력을 끼기에는 이미 역할을 나누어야 가능할 거란 생각이 든다.

객체지향적으로 설계하기 위해 맨 첫 시작을 객체지향적으로 설계하는 엔지니어들은 어떻게 만드는가 궁금해진다.

후기인데 책 내용을 나열하고 짤막한 나의 감상을 적는 게 되고 있어서 좀 더 줄여서 적어보고자 한다.

객체지향에서는 협력 → 행동 → 상태 순서로 영향을 준다

상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고 행동은 협력 안에서 객체가 처리할 메시지로 결정된다.

책임

책임이란 객체 의해 정의되는 응집도 있는 행위의 집합

객체의 책임은 ‘무엇을 알고 있는가’와 ‘무엇을 할 수 있는가’ 둘로 나뉜다.

하는 것(doing)과 아는 것(knowing)

책에서는 CRC(Candidate Responsibility Collaborator)라는 구체화 장치를 통해 효율적으로 객체지향적으로 설계하는데 도움을 줄 수 있다 한다(캔트 백과 워드 커닝험이 개발하였다고 한다)

https://medium.com/mindful-programmer/designing-with-crc-cards-9d53a6d92457

 

책임 할당이라는 패턴도 나오지만 아직은 확실하게 감이 오지는 않다.

책임 주도 설계

협력을 설계하기 위해서는 책임에 초점을 맞추어야 한다.

어떤 책임을 설계하느냐에 따라 전체적인 설계의 방향과 흐름이 결정된다.

“책임을 찾고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법”83p

책임 주도 설계 방법의 과정

• 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
• 시스템 책임을 더 작은 책임으로 분할한다.
• 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
• 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 객체 또는 역할을 찾는다.
• 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

결국 메시지가 객체를 선택하게 하였다.

메시지가 객체를 선택하게 해야 하는 중요한 이유

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

역할

“객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.”86p

• 협력은 메시지 요청에 의해 결정
• 책임은 응집도 있는 행위의 집합
• 역할은 특정한 협력 안에서 수행하는 책임의 집합

“객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다.”74p

“객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다.”75p

“객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.”75p

 

읽는 데에도 여러 시간 걸렸는데 적는 데에도 꽤나 걸렸다. 하지만 다 소화하지는 못했다.

확실히 개념을 읽고 구현도 해보고 고쳐보기도 해 봐야 조금이나 이해가 깊어질 수 있을 거 같은 책이다.