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

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

제목부터 이전부터 저자가 강조한 역할, 책임, 협력에 관해서 나온다.



사람들도 어떠한 상황에 처해있느냐에 따라 다르게 행동할 수 있다는 부분에서 객체 또한 어떤 협력에 참여하는지에 따라 필요한 행동이 결정되고, 그 행동이 객체의 상태를 결정한다고 한다. 객체들 간의 협력에 집중하라. 이번 장의 주제이다.

 

협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작한다. 이렇듯 객체간의 협력은 한 객체가 다른 객체에게 메시지를 통해 요청을 할 때 시작되는 것이다.

 

협력 안에서 각 객체들은 어떤 요청에 대해 응답하거나 적절한 행동을 한다. 이를 우리는 객체의 책임이라고 부르고, 객체지향 개발에서 중요한 것은 객체 들에게 이러한 책임을 적절하게 부여하는 것이다. 

개발을 하다보면 책임을 부여하기 전에 어떻게 구현 할 것인지에 대해 고민을 하는데, 그러기보다는 책임을 먼저 부여하고 구현을 할 것을 권장하고 있다.

 

저자는 책임을 다음 두 개로 분류하였다.

1. 하는 것(doing)

2. 아는 것(knowing)

 

하는 것과 아는 것을 세부적으로 3가지로 나누었다.

하는 것은

1. 객체를 생성하거나 계산을 하는 것

2. 다른 객체의 행동을 시작시키는 것(송신자)

3. 다른 객체의 활동을 제어하고 조절하는 것

 

아는 것은

1. 개인적인 정보에 관해 아는 것

2. 관련된 객체에 관해 아는 것

3. 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

 

하는 것은 확실히 느낌이 오는데 아는 것은 느낌이 잘 안 올 것이다.

책의 정보를 이용해 설명하자면 아는 것은 자신이 어떠한 책임을 가졌고, 어떠한 메시지를 요청받았을 때 어떤 행위를 해야 할지 알고 있다는 것이다.

 

책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소인데, 일반적으로 책임을 얘기할 때는 외부에서 접근 가능한 공용 서비스의 관점에서 이야기 한다. 

 

책임과 메시지의 관점에서 메시지를 송신하고 수신한 객체가 책임에 따라 행동하는 상호 협력적인 관계이지만, 책임과 메시지의 수준이 같지 않다는 점을 주의해야 한다.

실제로 하나의 객체는 큰 책임을 가지고 있고, 메시지는 그 큰 책임 중 일부를 행동하도록 도와주는 것이다. 

 

이전에 역할이 부여됐다는 것은 책임을 가지고 있다는 것임을 얘기한 적 있다. 객체가 곧 어떠한 책임을 가지고 행위를 한다는 것은 어떤 역할 군에 속한 객체가 그에 맞는 협력을 한다는 것이다.

 

객체지향 개발을 한다면 귀가 닳도록 들어왔겠지만 그 만큼 역할은 유연한 설계를 가능하게 해준다.

 

역할로 인해 협력을 추상화 할 수 있고, 또 그 역할에 대해 다른 객체가 대체 할 수도 있다. 이를 대체가능성이라고 한다.

생각보다 역할을 참 많은 일들을 해준다. 따라서 타입과 역할에 대해 일반화/특수화 관계가 성립된다고 한다.

참고로 역할이 일반화이고 타입이 특수화이다.

 

저자는 반복해서 개발자들에게 클래스 간의 관계를 표현하는 정적인 측면에 중점을 두지 말고 협력에 참여하는 동적인 측면에 집중하라고 한다.

 

그리고 3가지 객체지향 설계 기법에 대해서 소개를 해준다. 많이 들어봤지만 잘 못 이해하고 있던 부분이 있었다.

1. 책임-주도 설계(Responsibility-Driven Design) : 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식이다.

 

2. 디자인 패턴(Design Pattern) : 전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿 모음이다.

 

3. 테스트-주도 개발(Test-Driven Development) : 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해나가는 방식이다.

 

여기서 나는 단순히 테스트-주도 개발을 위에 정의 그 자체적으로만 이해해서 유지보수가 하기 쉽도록 하는 것 만이 목적이라고 생각했다. 하지만 저자는 다른 관점 또한 얘기해준다.

 

테스트-주도 개발의 실제 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 식별된 역할, 책임, 협력이 적합한지를 확인하는 것이다. 즉, 책임-주도 설계를 더 잘하기 위해서 테스트-주도 개발을 하는 것이라고 얘기를 해준다.

 

이렇게 얘기하니, 얼마나 테스트 주도 개발이 중요한지에 대해서 더 와닿을 수 있던 파트였다.