[04] 객체지향의 사실과 오해 - 역할,책임, 협력

 

 

 

우리 모두를 합친 것보다 더 현명한 사람은 없다. - 켄 블랜차드

 

중요한 것은 개별 객체가 아니라 객체들 사이에 이뤄지는 협력이다. 객체지향 설계의 전체적인 품질을 결정하는 것은 개별 객체의 품질이 아니라 여러 객체들이 모여 이뤄내는 협력의 품질이다.

협력

협력은 요청할 때 시작한다. 요청하면 응답한다.

협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다.

책임

객체지향의 세계에서는 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.

책임의 분류

하는 것과 아는 것으로 나뉜다.

역할

협력 안에서 역할은 “이 자리는 해당 역할을 수행할 수 있는 어떤 객체라도 대신할 수 있다.”

역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(reusability)을 뒷받침하는 핵심 개념이다.

협력의 추상화

역할의 가장 큰 가치는 하나의 협력 안에 여러 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화 할 수 있다는 것이다. 역할의 대체 가능성에서 비롯된다.

대체 가능성

역할을 대체하기 위해서는 행동이 호환돼야 한다.

역할이 수행하는 모든 책임을 동일하게 수행할 수 있어야 한다.

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

흔한 오류

많은 사람들은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 선입견을 가지고 있다. 데이터는 단지 객체가 행위를 수행하는 데 필요한 재료일 뿐이다.

객체지향의 핵심은 클래스를 어떻게 구현할 것인가가 아니라 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지 결정하는 것이다.

객체지향 입문자들이 데이터나 클래스를 중심으로 애플리케이션을 설계하는 이유는 협력이라는 문맥을 고려하지 않고 각 객체를 독립적으로 바라보기 때문이다.

근엄한 왕을 설계하는 것이 아니라 왕이 협력에 어떤한 역할로 참여해서 책임을 수행할 수 있는지를 고려해야 한다.

협력을 따라 흐르는 객체의 책임

견고하고 깔끔한 협력을 설계해야 한다. 협력을 설계한다는 것은 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정한다는 것을 의미한다. 이 흐름은 객체가 협력에 참여하기 위해 수행될 책임이 된다

객체지향 설계 기법

역할, 책임, 협력이 견고하고 유연한 객체지향 설계를 낳기 위한 가장 중요한 토양

역할, 책임 협력의 관점에서 애플리케이션을 설계하는 유용한 세 가지 기법

 

1. 책임-주도 설계

 

협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 설계

시스템의 책임을 객체의 책임으로 변환하고, 각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아 해당 협력자에게 책임을 할당하는 순차적인 방식으로 객체들의 협력 공동체를 구축한다.

 

2. 디자인 패턴

 

전문가들이 반복적으로 사용하는 역할, 책임, 협력 구조를 정의 해놓은 설계 템플릿 모음

COMPOSITE 패턴은 전체와 부분을 하나의 단위로 추상화해야 하는 경우에 사용할 수 있는 패턴

Component, Leaf, Composite 라는 역할이 서로 협력하는 패턴

 

3. 테스트-주도 개발

 

테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식

구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 적합한지 피드백하는 방법

테스트-주도 개발은 테스트를 작성하는 것이 아니라 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다. 테스트라는 안전장치를 통해 좀 더 빠르고 견고한 방법으로 도달할 수 있도록 해주는 최상의 설계 프랙티스다.