본문 바로가기
책/오브젝트

03. 역할, 책임, 협력

by 오오오니 2025. 3. 17.

03. 역할, 책임, 협력

비어 있음
객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다.
애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한 지를 고민하지 않은 채 너무 이른 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다.

협력

협력은 객체지향의 세계에서 가능을 구현할 수 있는 유일한 방법이다.
두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다.
객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다.
객체의 협력이 행동을 결정하고, 행동이 상태를 결정한다.

책임

책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장이다.
크게 ‘하는 것’과 ‘아는 것’의 두 가지 범주로 나누어 세분화하고 있다.
책임은 객체지향 설계의 핵심이다.

책임 할당

자율적인 객체를 만드는 가장 기본적인 방법은 수행하는 데 필요한 정보를 가장 잘 알고 있는 전문가에게 그 책임을 할당하는 것이다. 이를 정보 전문가 패턴이라고 부른다.
ex)
“예매하라” 메시지를 처리할 적절한 객체는 영화 예매와 관련된 정보를 가장 많이 알고 있는 전문가인 Screening에게 할당하는 것이 바람직하다.

책임 주도 설계

어떤 책임을 선택하고 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방법을 책임 주도 설계라고 부른다.
시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
시스템 책임을 더 작은 책임으로 분할한다.
분할된 책임을 수행할 수 잇는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.
책임을 할당할 때 고려할 요소
메시지가 객체를 결정한다.
객체가 최소한의 인터페이스를 가질 수 있게 된다.
충분히 추상적인 인터페이스를 가질 수 있게 된다.
행동이 상태를 결정한다.
객체는 협력에 필요한 행동을 제공해야 한다.
행동이 아니라 상태에 초점을 맞춰 구현하면 캡슐화를 저해하게 된다. 그러지 않기 위해서는 협력이라는 문맥 안에서 객체를 생각해야 한다.

역할

역할은 다른 것으로 교체할 수 있는 책임의 집합이다.
객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.
협업을 모델링할 때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하는 게 좋다.
유연하고 재사용 가능한 협력
역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다.
ex)
영화 예매 도메인에서 금액 할인 정책, 비율 할인 정책이 존재하기 때문에
AmountDiscountPolicy, PercentDiscountPolicy 두 종류의 객체가 “할인 요금을 계산하라”
라는 메시지에 응답할 수 있어야한다.
두 종류의 객체가 참여하는 협력을 개별적으로 만든다면 대부분의 코드가 중복되고, 중복은 모든 문제의 근원이기 때문에 이런 방법은 피해야 한다.
문제를 해결하기 위해서는 객체가 아닌 책임에 초점을 맞춰, 두 객체가 동일한 책임을 수행한다는 사실을 알고 두 협력을 하나로 통합할 수 있다.
추상클래스, 인터페이스 등을 통해 역할을 구현할 수 있다.

객체 대 역할

한 종류의 객체만 협력에 참여하는 상황에서 역할이라는 개념을 고려하는 것이 유용할까?
협력에 참여하는 대상을 객체가 한 종류라면 객체라고 생각하고, 객체가 여러 종류라면 역할이라고 생각하면 된다.
설계초반에 이런 결정을 하는 것이 어려울 수 있다. 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목표이고 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지 않다. 단순하게 객체로 시작하고 반복적으로 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다.

역할과 추상화

추상화를 이용한 설계를 하면
추상화 계층만을 이용하면 중요한 정책을 상위 수준에서 단순화할 수 있다.
설계가 좀 더 유연해진다.
라는 장점이 있다.
역할은 객체의 종류를 숨기기 때문에 이런 관점에서 역할을 객체의 추상화라고 볼 수 있다.
상위 수준에서 협력을 설명하면 구체적인 객체들이 가지는 복잡성을 제거하고 단순화해서 표현할 수 있다. 또한 역할이 다양한 종류의 객체를 끼워 넣을 수 있는 슬롯이라는 점에서 동일한 역할을 수행하는 객체들은 서로 대체 가능하다.
느낀 점
역할과 책임에 대해서 각각 자세히 살펴봄으로 써 각각의 특징과 정의를 알 수 있어서 좋았다.
역할, 책임이 중요한 개념인 것은 알고 있었지만 둘에 대해 깊이 알지 못해 비슷한 개념으로 생각하고 있었던 것 같다.
특히 역할과 추상화 부분이 인상 깊었다. 역할을 슬롯이라고 생각하고 객체를 끼워 넣는 다는 개념이 신기했다. 책에서 말한 것처럼 이렇게 하면 유연한 설계가 가능하고, 서비스의 흐름을 상위 수준에서 설명할 수 있어서 세부 사항에 얽매이지 않고 설계할 수 있을 것 같다. 그래서 다음에 프로젝트를 할 때 역할에 대해서 생각하고 설계를 하면 좋을 것 같다는 생각을 했다.

' > 오브젝트' 카테고리의 다른 글

06. 메시지와 인터페이스  (0) 2025.03.17
05. 책임 할당하기  (0) 2025.03.17
04. 설계 품질과 트레이드 오프  (0) 2025.03.17
02. 객체지향 프로그래밍  (0) 2025.03.17
01. 객체, 설계  (0) 2025.03.17