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

레벨 2 끝나기 전에는... 다 읽어야지... ㅎ

---

 

✔️ 역할, 책임, 협력

(기억에서 잊혀졌겠지만) 1장에서 언급하였던 예제를 다시 가져와보자.

손님냥이 카페에서 커피를 주문하기까지 다음과 같은 요청과 응답이 이루어진다.

1. 손님냥은 알바냥에게 커피를 요청한다.
2. 알바냥은 셰프냥에게 커피를 만들 것을 요청한다.
3. 요청을 받은 셰프냥은 커피를 만들기 시작하면서 응답한다. 이는 손님냥의 커피 주문에 대한 응답이기도 하다.
4. 만든 커피를 알바냥이 건네받아 손님냥에게 응답한다.

여기서 셰프냥이 커피를 만들라는 요청을 받을 수 있는 이유가 무엇이었을까?

셰프냥은 바리스타 자격증이 있기 때문에 커피를 만들라는 요청에 대해 적합하게 대응할 수 있었기 때문이다.

 

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

알바냥은 셰프냥에게 커피 생성에 대해 전달할 책임을, 셰프냥은 커피를 제작할 책임이 있는 것이다.

 

🌱 책임은, 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장이다.

😻 손님냥

알바냥이 주문을 받는다는 것을 알고 있다. (아는 것)

알바냥에게 커피 제작을 시킨다. (하는 것)

 

😿 알바냥

셰프냥이 바리스타 자격증을 가지고 있어 커피를 만들 수 있다는 것을 알고 있다. (아는 것)

셰프냥에게 커피 제작을 시킨다. (하는 것)

 

🐱 셰프냥

자신은 바리스타 자격증을 가지고 있어, 커피를 만드는 방법을 안다. (아는 것)

커피를 만들어야 한다. (하는 것)

 

🌱 객체가 수행하는 책임의 집합은, 객체가 협력 안에서 수행하는 역할을 암시한다.

알바냥이 셰프냥에게 커피 제작에 대해 요청하였다. ‘커피 주문’이라는 협력 속에서 알바냥은 ‘아르바이트생’ 역할을 수행하며, 셰프냥은 ‘바리스타’의 역할을 수행하고 있다. 근데 이것이 중요할까? 알바냥을 아르바이트생, 셰프냥을 바리스타라고 불러서 상황을 복잡하게 만드는 이유가 무엇일까?

 

이는, 역할이 재사용이 가능하며, 유연한 객체지향 설계를 낳기 때문이다.

만약, 고양이 카페가 멍멍이 카페로 변화하였다고 생각해보자.

손님냥 대신 손님멍, 알바냥 대신 알바멍, 셰프냥 대신에 셰프멍으로 변화할 것이다.

 

객체가 변화하더라도 행위가 변화할까? 아닐 것이다.

손님멍은 알바멍에게 커피를 주문할 것이고, 알바멍은 셰프멍에게 커피 제작을 요청할 것이고, 셰프멍은 커피 제작을 진행할 것이다.

동일한 행위를 하는데 이러한 객체의 협력을 별도로 관리해야 할까?

그럴 필요 없이, 역할을 사용하여 각각의 협력을 하나의 협력으로 추상화하면 된다.

 

역할은 협력 내에서 다른 객체로 대체할 수 있음을 나타낸다.

이 말은 곧, 다른 객체로 대체하기 위해서는 협럭 안에서 어떠한 역할로서 수행하는 모든 책임을 동일하게 수행할 수 있어야 한다는 것이다.

손님 자리에는 손님냥, 손님멍, 손님짹 등이 들어갈 수 있고, 알바 자리에는 알바냥, 알바멍, 알바짹 등 행위를 대체할 수 있는 객체가 들어갈 수 있다. 결국, 동일한 역할을 수행할 수 있다는 것은 해당 객체들이 협력 내에서 동일한 책임의 집합을 수행할 수 있음을 의미하며, 동일한 역할을 수행하는 객체들은 동일한 메시지를 수신할 수 있다.

 

🌱 역할의 대체 가능성은 행위 호환성을 의미하며, 행위 호환성은 동일한 책임의 수행을 의미한다.

알바냥은 단순히 커피 주문만 받지는 않는다. 카페를 벗어나면 알바냥은 고양이 가족의 일원으로서의 책임이 있을 것이다.

즉, 역할이 암시하는 책임보다 객체는 더 많은 책임을 가질 수 있으며, 객체의 타입과 역할 사이에는 일반화 - 특수화 관계가 성립하게 된다.

 

---

 

✔️ 올바른 객체를 설계하기

협력을 설계하는 것은, 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정하는 것이다.

여기서 결정된 요청과 응답의 흐름은, 객체가 협력에 참여하기 위해 수행될 책임이 된다.

결국 객체에게 책임을 할당하고 나면, 책임은 객체가 외부에 제공하게 될 행동이 된다.

 

책임과 행동을 결정하고, 행동을 수행하기 위한 데이터를 고민해야 한다.

그렇기 때문에 클래스와 데이터는 협력과 책임이 결정된 후에 생성할 수 있는 것이며, '협력' 관계를 잘 따져 객체를 생성하고, 협력 관계에 필요한 책임을 구성하여 책임 자체를 객체에게 할당해야 올바른 객체를 설계했다고 말할 수 있는 것이다.

 

그렇다면, 객체지향 설계 기법에는 어떤 것이 있을까?

 

 

🌱 RDD (책임 주도 설계)

: 협력에 필요한 책임을 식별하고, 적합한 객체에게 책임을 할당하는 방식.

“올바른 책임을 올바른 객체에게 할당하는 것”

 

기능 자체를 작은 규모의 책임으로 분할하고, 각 책임은 책임을 수행할 객체에게 할당하는 것이다. 

이때, 스스로 처리할 수 없는 정보는 다른 객체에게 요청하여 응답받아서 사용할 수 있다.

RDD에서는 객체의 책임과 상호작용에 집중할 수 있으며, 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차를 제시하게 된다.

 

 

🌱 디자인 패턴

: RDD의 결과를 표현하는 것.

해결하려는 문제에 대해 서술하고, 해당 패턴을 적용할 수 있는 상황과 없는 상황에 대해 함께 설명한다.

특정 상황에서 어떠한 설계가 더 효과적인지에 대해 따지고, 해당 설계를 적용하는 것이다.

 

 

🌱 TDD (테스트 주도 개발)

테스트를 통과하는 가장 간단한 코드를 작성하고, 리팩터링을 통해 중복을 제거하는 것이다.

테스트를 작성하는 것이 아닌, 책임을 수행할 객체나 클라이언트가 기대하는 객체의 역할이, 메시지를 수신할 때 어떤 결과를 반환하고, 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다.