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

객체의 모양을 빚는 것은 객체가 참여하는 협력이다. 개별적인 객체의 상태나 행동이 아니라 객체들간의 협력에 집중하라!!!

협력

한 객체가 자신의 책임으로 해결할수 없을 때 다른 객체에게 도움을 받기 위해 요청을 한다. 이 객체는 또 자신의 책임으로는 해결할수 없을 때 다른 객체에게 요청을하고, 또 그 객체는 요청한다. 그리고 요청받은 객체는 응답한다. 이런 요청과 응답의 연쇄적인 흐름이 바로 협력이다.

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

책임

객체가 어떠한 요청에 대해 대답할수 있거나 적절한 행동을 할 의무가 있는 경우 해당 객체는 책임이 있다고 한다.
A객체가 B객체에게 요청을 전송할 경우에만 B객체는 책임을 수행한다. 즉, 다른 객체가 책임을 수행하도록 요청을 보내는 것을 메시지 전송이라고 한다.
(책임은 각 객체가 할수 있는 것, 메시지는 두 객체 사이의 관계를 강조한 것)

객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야하는지, 어떤 객체로부터 메시지를 수신할 지를 결정하는 것으로부터 시작한다.

역할

역할은 책임의 집합을 의미한다.
보다 더 본질적인 역할의 존재 이유는, 재사용 가능하고 유연한 객체지향 설계를 가능하게 한다는 것이다.

예를들면 축구에서 공격수는 패스를 받거나, 패스를 주고 슛을 날리는 책임을 가지고있다. 이러한 책임의 집합은 공격수라는 역할을 의미한다. 그러나 공격수가 부상당하면 교체를 해야한다. 즉, 이러한 역할은 해당 책임을 할수 있는 객체로 교체가 가능해야한다. 그렇기에 공격수라는 역할은 재사용이 가능하며 유연한 객체지향 설계를 가능하게한다.

대신 역할을 대체하기 위해서는 수신되는 메시지를 동일하게 이해해야 한다(예시에서도 말했지만 같은 책임을 수행할 수 있어야한다.)

그리고 역할이 또 중요한것은 추상화를 도와준다는 것이다.(복잡성을 낮춰준다.)
왜냐하면 황의조, 호날두, 드록바는 각 객체들인데 하나의 역할 '공격수'로 묶을 수 있다. 그리고 이렇게 묶으면 개발자들에겐 인지 과부하를 줄일수 있게 도와준다.

역할은 객체지향 설계에서 단순성, 유연성, 재사용성을 뒷받침하는 핵심 개념이다.

객체지향에 대한 잘못된 오해

1. 객체는 단지 변수나 메서드를 저장하는 데이터 저장공간이다.
2. 정적인 클래스간의 관계가 중요하다.

1번은 객체의 존재이유가 틀렸다. 객체의 존재 이유는 각자의 책임을 통해 협력에 참여하기 위해서이다. (이러한 협력으로 우리의 목표인 하나의 기능을 만들수 있다.)
2번은 왜 틀렸냐면, 클래스는 단순히 타입을 나타내는(타입은 추상화를 위해, 복잡성을 낮추기 위해 존재한다고 알고있다. 모두!! 그쵸?) 하나의 방법일 뿐이다. 정적인 클래스간의 관계는 중요하지 않고 협력에 참여하는 동적인 객체가 중요하다.(협력안에서 객체가 어떤 책임과 역할을 수행하는지 결정하는 것이 중요하다.)

즉 객체를 하나의 독립적인 매개체로 보지마라. 협력을 우선적으로 생각해야한다.(객체들의 협력으로 우리의 목표인 하나의 기능을 만들수 있다.) 협력내에서 객체는 어떠한 책임을 수행한다.

객체지향 설계 순서

객체를 협력내에서 어떤 책임과 역할을 수행할지 먼저고민해라. 그다음 객체의 행동과 상태를 고민해도 늦지않다.!!!
(이를 위해서 객체는 충분히 협력적이고 충분히 자율적이다는 사실을 항상 잊지말자)

객체지향 설계 기법

책임주도설계(RDD)

1. 어플리케이션의 어떤 기능을 구현할지 생각(기능 = 우리의 목표)
2. 기능을 위해선 어떤 책임이 필요할지 파악
3. 책임을 더 작은 책임으로 분할
4. 작게 분할된 책임을 수행할 적절한 객체에게 할당
5. 객체가 책임을 수행하는 도중 도움이 필요할 경우 요청을 수신할 객체 또는 역할을 찾는다.
6. 해당 객체에게 책임을 할당하여 두 객체가 협력하게 한다.

각 객체의 책임 -> 요청받는 객체에게 책임 -> 두 객체는 협력관계

디자인 패턴(RDD의 결과, 이미만들어진 템플릿)

이미 많은 사람들이 책임주도 설계를 통해 객체지향을 설계했고, 어떠한 문제를 해결하기 위한 해결법이 이미 많이 존재한다. 디자인 패턴은 미리 만들어진 책임주도 설계의 결과를 이용하는 것이다.

테스트주도 개발(TDD)

충분한 역할 책임 협력에 대한 훈련이 되어있어야 하는 설계 기법이다. 단순히 테스트를 통해 설계하는 것이아닌 어떤 객체가 이미 존재한다는 가정하에 해당 객체가 가진 책임에 대해서 이 책임을 위해선 어떤 요청을 어떤 책임에게 해야하고, 어떠한 요청을 수신한 결과로 이 책임을 수행하는지 고민할수 있어야한다.
즉, TDD를 하기 위해선 역할, 책임, 협력의 관점에서 객체를 바라봐야한다.

즉, TDD도 RDD의 기본 개념을 따른다. RDD를 잘하지 못하면 TDD도 당연히 잘하지 못한다.