오브젝트 - 역할, 책임, 협력

앞서 살펴본 상속, 인터페이스를 통한 코드 재사용 및 다형성을 구현한 것은 객체지향 프로그래밍의 구현 측면일 뿐 핵심은 아니다.

객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력 이다.

 

객체지향은 요구사항을 충족시키기 위하여 적절한 객체들을 정의하고 각 객체에게 적절한 역할과 책임을 부여하여,

상호간 협력하는 공동체를 구성하는 것이다.

 

협력

협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다.

그리고 객체 간 협력을 위한 유일한 커뮤니케이션 수단은 메시지 전송(message sending)이다.

 

그리고 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다.

이때 메시지를 수신한 객체는 스스로 처리할 방법을 선택한다. (객체의 자율성)

 

여기서 자율적인 객체란 자신의 상태를 직접 관리하고 스스로의 결정에 따라 행동하는 것을 의미한다.

그리고 결과적으로 객체의 자율성을 보장하는 기본적인 방법은 내부 구현(상태와 행동)을 캡슐화 하는 것이다.

 

캡슐화는 변경에 대한 파급효과를 최소화하며, 객체 간 결합도를 느슨하게 유지할 수 있도록 해준다.

캡슐화를 통한 자율적인 객체들간 상호 협력을 통해(메시지 수신과 응답의 흐름) 애플리케이션의 기능이 구현된다.

 

그렇다면 객체가 가지는 상태와 행동은 어떤 기준으로 정해지는 것인가?

이는 협력이란 문맥 속에 정답이 정해져 있다. 객체는 협력을 하기 위한 적절한 행동을 보유해야 한다.

 

결과적으로 객체가 가질 수 있는 행동은 바로 어떤 협력을 하는가에 따라 정해지는 것이다.

그리고 이러한 행동을 통해 객체의 상태가 결정된다.

객체의 상태란 객체가 행동을 수행하는 데 필요한 정보가 무엇인지로 정해진다.

 

결국 객체의 상태와 행동을 결정하는 것은 바로 협력 이다.

그리고 협력은 객체를 설계하는 데 필요한 일종의 문맥(context)을 제공한다.

 

책임

책임이란, 객체가 협력에 참여하기 위해 수행하는 행동이다.

정리하면, 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 의미이다.(추상적인 개념)

 

책임은 크게 2가지 범주로 나뉜다.

 

하는 것(doing)

• 객체를 생성하거나 계산을 수행하는등의 스스로 하는 것
• 다른 객체의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

아는 것(knowing)

• 사적인 정보에 관해 아는 것
• 관련된 객체에 관해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

협력 안에서 객체에게 할당한 책임이 외부의 인터페이스와 내부의 속성을 결정한다.

이러한 이유로 객체지향 개발에서 가장 중요한 능력은 책임을 적절한 객체에 할당하는 것이다.

그리고 협력이 앞서 설명하였 듯, 책임을 할당하는 문맥(큰 흐름)을 제공한다.

 

책임 할당

협력을 설계하는 출발점은 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 바라보는 것.

그리고 하나의 시스템 책임을 완료하는 데 필요한 더 작은 책임을 찾아내고 이를 객체들에게 할당하는 반복적인 과정을 통해 이뤄진다

객체지향 설계는 협력에 필요한 메시시를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해 완성된다. 그리고 이런 메시지가 수신할 객체의 책임을 결정한다.
각 객체가 수신한 메시지가 해당 객체의 퍼블릭 인터페이스를 구성한다.

책임 주도 설계

위에서 살펴본 것 처럼 책임을 찾고 해당 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로

객체지향의 협력을 설계하는 방식을 "책임 주도 설계" 라고 부른다.

 

책임 주도 설계 과정

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

메시지가 객체를 결정한다

책임을 할당하는 데 필요한 메시지를 먼저 식별하고 해당 메시지를 처리할 객체를 나중에 선택하는 것

• 객체가 최소한의 인터페이스를 가질 수 있게 된다.
• 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.

행동이 상태를 결정한다.

객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법이다.

그리고 이러한 객체의 행동은 협력이란 문맥 속에서 결정되는 적절한 책임으로부터 도출된다.

상태는 행동을 결정하고 나서야 비로소 결정할 수 있다.

 

역할

역할과 협력

협력이란 문맥 속에서 객체는 협력에 필요한 여러 책임의 집합을 가지게 된다.

이러한 책임의 집합은 한 객체가 존재하는 목적이며, 객체가 가지는 역할이라고 한다.

 

책임 할당 과정은 적절한 역할이 무엇인가를 찾고 해당 역할을 수행할 객체를 찾는 것이다.

 

유연하고 재사용 가능한 협력

왜 역할이란 추상적인 개념을 정하여 번거로운 절차를 따지는가

이러한 질문에 대한 답은 바로 역할이란 개념을 통해 재사용 가능한 협력을 얻을 수 있기 때문이다.

 

예시로 만약 영화 예매라는 협력 안에서 할인 요금을 계산에 사용되는 정책이 여러가지일 때,

각 정책별 객체를 생성하여 개별적으로 협력에 참여하게끔 모두 구현해야하는가

이는 코드 중복의 원인이 될 것이며, 결과적으론 객체의 자율성을 침범하여 변경에 취약한 코드를 만들 것이다.

 

역할을 통한 재사용 가능한 협력

역할이란 개념을 도입함으로써 두 객체의 협력 참여를 하나로 통합할 수 있다.

이는 해당 두 객체의 협력이란 문맥 속에서 동일한 책임을 가지기에 합칠 수 있는 것이다.

 

역할이란 구체적인 객체를 포괄하는 추상화는 코드의 중복을 줄이며,

핵심적으로 변경에 유연한 재사용 가능한 설계와 협력을 만들 수 있게 한다.

역할이란, 다른 것으로 교체할 수 있는 책임의 집합이다.

 

그리고 역할을 구현하는데 사용되는 방법으로 앞서 배운 추상 클래스와 인터페이스가 존재한다.

 

협력, 역할, 객체, 클래스의 관계

협력을 구체적인 객체가 아니라 추상적인 역할의 관점에서 설계하다면 협력이 유연하고 재사용 가능해진다

따라서 역할의 가장 큰 장점은 설계의 구성 요소를 추상화할 수 있다는 것이다.

 

참고

• 해당 게시글은 조영호님의 "오브젝트" 를 정리하여 작성하였습니다.
• 보다 자세한 내용은 책을 통해 확인하시길 적극 권장드립니다.