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

의도는 "메시징"이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다.
-엘런 케이[Kay 1998]

 최후통첩 게임이란 게임 이론에 등장하는 방법론 중 하나로 1982년 독일 훔볼트대학교 경제학 교수 베르너 귀트(Werner Güth) 등이 고안한 이론이다. 사람이 공정하지 못한 상황에 처하면, 최악의 조건 속에서도 한 올의 합리적인 이익조차 놓치게 되어버리는 심리를 일컬을 때 자주 언급된다.

 

최후통첩 게임 - 일상과학 WiKi - 위키독

 

 만약 인간이 이기적이고 합리적인 존재라면, 자신이 최대한의 금액을 가져갈 수 있는 선택을 해야 한다. 하지만 이 게임의 실험 결과를 보면(위 링크 참조) 사람들은 서로 최대 이득을 얻어갈 수 있는 선택지가 아닌 상황과 감정에 따라 불합리한 선택을 한다는 것이다. 그렇기에 50%이상의 인간은 자신의 최대 이득이 아닌 공동체의 최대 이득을 얻기 위해 윈윈하는 선택지를 주로 선택하게 됬다 결론적으로 인간이 어떤 본질적인 특성을 지니고 있느냐가 아니라 어떤 상황에 처해 있느냐가 인간의 행동을 결정한다. 즉, 각 개인이 처해 있는 정황 또는 문맥(context)이 인간의 행동 방식을 결정한다는 것이다. 이는 객체도 마찬가지다. 객체의 세계에서도 협력이라는 문맥이 객체의 행동 방식을 결정한다.

 

---

역할, 책임, 협력

크레이그 라만은 "객체지향 개발에서 가장 중요한 능력은 책임을 능숙하기 소프트웨어 객체에 할당하는 것"이라고 말한다. 협력에 참여하는 객체들은 목표를 달성하는 데 필요한 책임을 수행한다. 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 알아야 하는 정보와 객체기 수행할 수 있는 행위에 대해 개략적으로 서술한 문장이다. 크레이그 라만은 객체의 책임을 '하는 것'과 '아는 것' 두가지로 분류하고 있다.

 

하는 것(doing)

- 객체를 생성하거나 계산을 하는 등의 스스로 하는 것

- 다른 객체의 행동을 시작시키는 것

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

 

아는 것(knowing)

- 개인적인 정보에 관해 아는 것

- 관련된 객체에 관해 아는 것

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

 

 객체의 책임을 이야기 할 때는 일반적으로 외부에서 접근 가능한 공용 서비스의 관점에서 이야기한다. 즉, 책임은 외부에 제공해 줄 수 있는 정보(아는 것)와 외부에 제공해 줄 수 있는 서비스(하는 것)의 목록이다. 따라서 책임은 객체의 공용 인터페이스를 구성한다.

 

 역할은 협력내에서 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 같은 역할을 가지고 있는 객체들은 모두 그 역할이 이해할 수 있는 메시지를 가지고 있다. 메시지를 이해할 수 있다는 것은 해당 객체의 책임을 의미하는 것이므로, 동일한 역할을 수행할 수 있다는 것은 해당 객체들이 협력 내에서 동일한 책임의 집한을 수행할 수 있다는 것을 의미한다. 역할의 개념을 사용하면 인지 과부하를 줄일 수 있다. 같은 역할을 수행할 수 있는 많은 객체들을 단 하나의 역할로 추상화 할 수 있기 때문이다. 이처럼 역할을 사용하면 협력이 유연해지며, 재사용성이 높아진다.

 

-

 지금 까지의 내용을 C# 개발자의 관점으로 해석해본다면, 객체의 책임은 해당 객체가 가지고 있는 public 메서드와 프로퍼티들을 의미하고, 객체의 역할은 클래스와 인터페이스로 설계를 할 수 있다고 본다.

 

---

객체 지향 설계기법

책임주도설계: 협력에 필요한 책임들을 식별하고 적합한 객체에 책임을 할당하는 방식

- 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.

- 시스템 책임을 더 작은 책임으로 분할한다.

- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.

- 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.

- 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

 

디자인 패턴: 전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 템플릿의 모음(역할, 책임, 협력)

 "효율적으로 일 하는 사람들의 한 가지 특징은 아무것도 없는 상태에서 작업을 시작하지 않고 이전의 훌륭한 결과물을 모방하고 약간의 수정을 거쳐 원하는 결과물을 만들어 낸다는 것이다." [Cockburn 2001]

 

테스트주도개발(TDD): 이름에서 풍기는 뉘앙스와 달리 TDD는 테스트가 아니라 설계를 위한 기법. 실제 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 식별된 역할, 책임, 협력이 적합한지 피드백을 받는 것

 

 TDD의 기본 흐름은 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후 리팩터링을 통해 중복을 제거하는 것이다. TDD를 통해 '작동하는 깔끔한 코드'를 얻을 수 있다. TDD는 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템을 개발할 수 있게 하는 최상의 프랙티스이다. TDD는 객체가 이미 존재한다고 가정하고 객체에게 어떤 메시지를 전송할 것인지에 관해 먼저 생각하라고 충고한다. 협력 안에서 객체의 역할과 책임이 무엇이고 이것이 클래스와 같은 프로그래밍 언어 장치로 구현되는 방식에 대한 감각을 갖춰야한 효과적인 테스트를 작성할 수 있다. 

 

---