우리 모두를 합친 것보다 더 현명한 사람은 없다.
- 켄 블랜차드
•
전통적인 경제학에서 인간은 완벽하게 이기적인 동시에 합리적인 존재라고 가정한다. 이 관점에 따르면 인간은 항상 자신에게 최대의 이익이 돌아올 수 있도록 합리적으로 의사결정을 내리려고 한다. 과연 그럴까?
◦
독일 홈볼트 대학의 교수 베르너 귀스는 흥미로운 경제학 게임 하나를 고안했다. 이 실험에는 두 명의 게임 참가자가 참여한다. 한 명은 제안자, 한 명은 응답자라고 부른다.
◦
게임 방법은 간단하다. 연구팀은 제안제에게 일정한 금액을 제공하고 제안자는 자신이 받은 금액 일부를 응답자와 나눠 가져야 한다.
◦
제안자는 자신이 받은 금액을 공평하게 나누어 가지자고 제안할 수도 있고 자신이나 응답자에게 좀 더 많은 금액이 돌아가도록 제안할 수도 있다.
◦
이 게임에는 제안자와 응답자 둘 모두에게 단 한 번의 선택 기회만 주어지기 때문에 최후통첩 게임이라는 이름이 붙었다.
◦
이는 인간을 바라보는 두 가지 관점의 충돌을 잘 설명해 준다. 인간이 가지고 있는 본연의 특성이라는 관점에서 인간은 이기적이면서 합리적인 존재다.
◦
그러나 타인과 관계를 맺는 과정 속에서 인간은 본연의 특성을 배제하고 자신의 이익을 최소화하는 불합리한 선택을 하게 된다.
•
즉 인간은 어떤 본질적인 특성을 지니고 있느냐가 아니라 어떤 상황에 처해있느냐가 인간의 행동을 결정한다. 즉 각 개인이 처해있는 문맥이 인간의 행동 방식을 결정하는 것이다.
•
객체의 세계에서도 협력이라는 문맥이 객체의 행동 방식을 결정한다. 협력이라는 문맥을 고려하지 않는다면 객체가 가져야할 상태와 행동부터 고민하게 되어 좋지 못한 설계를 만들게 된다.
•
객체의 모양을 빚는 것은 객체가 어느 협력에 참여하느냐다. 어떤 협력에 참여하는지가 객체에 필요한 행동을 결정하고 필요한 행동이 객체의 상태를 결정한다.
협력
요청하고 응답하며 협력하는 사람들
•
일상생활 속에서 이뤄지는 협력의 본질은 요청과 응답으로 연결되는 사람들의 네트워크다.
◦
일반적으로 우리가 직면하게 되는 문제는 혼자서 해결하기 힘들기 때문에 해결 과정에 여러 사람이 참여하게 된다. 이 과정 속에서 요청과 응답의 연쇄적인 흐름이 발생한다.
•
협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작된다. 요청을 받은 사람은 일을 처리한 후 요청한 사람에게 필요한 지식이나 서비스를 제공하는 것으로 요청에 응답한다.
누가 파이를 훔쳤지?
•
훌륭한 객체를 설계하려면 먼저 협력이라는 단어 속에 내포된 다양한 특성을 두루 살펴볼 필요가 있다.
•
여기서는 이상한 나라에 홀로 남겨진 앨리스의 이야기 중, 하트 여왕이 만든 파이를 훔쳐 달아나다 붙잡힌 하트 잭에 대한 공판이 열리는 법정의 이야기를 통해 알아보자.
•
법정 안에는 재판을 주관하고 있는 왕과 증언을 하는 모자 장수, 재판을 구경하기 위해 법정을 찾은 앨리스를 비롯해 수많은 인물들이 등장한다.
•
이 많은 등장인물들이 법정에 모여 있는 이유는 무엇일까? 바로 하트 잭을 재판하기 위해서다.
•
객체지향적인 시점에서 봤을 때 법정은, 먼저 등장하는 모든 등장인물들은 객체다. 왕과 하얀 토끼, 모자 장수라고 불리는 객체들은 하트 잭을 재판하기 위해 서로 협력하고 있다.
◦
즉 이 이야기에 등장하는 객체들은 하트 잭의 재판이라는 동일한 목적을 달성하기 위해 협력하고 있는 것이다.
재판 속의 협력
•
하트 잭을 재판하기 위해 등장인물들이 어떤 방식으로 협력하고 있는지 살펴보자. 모든 협력이 그런 것처럼 하트 잭의 재판 과정 역시 재판에 참여하는 많은 사람들이 요청하고 응답하는 과정 속에서 이뤄진다.
◦
누군가가 왕에게 재판을 요청함으로써 재판이 시작된다.
⇒ 누군가 왕에게 재판을 해달라는 요청을 보냈다는 말은 왕이 재판을 수행할 의무가 있으며 재판에 처리하는 데 필요한 지식을 가지고 있음을 의미한다.
◦
왕이 하얀 토끼에게 증인을 부를 것을 요청한다.
⇒ 왕이 하얀 토끼에게 목격자를 불러오라고 요청한 이유는 하얀 토끼가 목격자에 대해 알고 있으며 동시에 목격자를 부를 의무가 있기 때문이다.
◦
왕의 요청을 받은 토끼는 모자 장수에게 증인으로 입장할 것을 요청한다.
◦
모자 장수는 증인석에 입장함으로써 토끼의 요청에 응답한다.
▪
모자 장수의 입장은 왕이 토끼에게 요청했던 증인 호출에 대한 응답이기도 하다.
◦
이후 왕은 모자 장수에게 증언할 것을 요청한다.
⇒ 왕이 모자 장수에게 증언하라고 요청한 이유는 모자 장수가 재판에 도움이 될 만한 사건의 내용에 대해 조금이라도 알고 있으며 증언할 의무가 있기 때문이다.
◦
모자 장수는 자신이 알고 있는 내용을 증언함으로써 왕의 요청에 응답한다.
•
결국 어떤 등장인물들이 특정한 요청을 받아들이는 이유는 그 요청에 대해 적절한 방식으로 응답하는 데 필요한 지식과 행동 방식을 가지고 있기 때문이다.
•
요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.
책임
•
객체지향의 세계에서는 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우, 해당 객체가 책임을 가진다고 말한다.
•
책임은 객체지향 설계의 가장 중요한 재료다.
◦
크레이그 라만은 객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것이라고 말했다.
•
객체와 책임이 이리저리 부유하는 상황에서 겅급하게 구현에 뛰어드는 것은 변경에 취약하고 다양한 협력에 참여할 수 없는 비자율적인 객체를 낳게 된다.
책임의 분류
•
협력에 참여하는 객체들은 목표를 달성하는 데 필요한 책임을 수행한다.
•
책임은 객체에 의해 정의되는 응집도 있는 행위의 집합으로 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장이다.
◦
즉, 객체의 책임은 객체가 무엇을 알고 있는가와 무엇을 할 수 있는가로 구성된다.
•
크레이그 라만은 이러한 분류 체계에 따라 객체의 책임을 크게 하는 것과 아는 것의 두 가지 범주로 자세히 분류하고 있다.
◦
하는 것
▪
객체를 생성하거나 계산을 하는 등, 스스로 하는 것
▪
다른 객체의 행동을 시작하는 것
▪
다른 객체의 활동을 제어하고 조절하는 것
◦
아는 것
▪
개인적인 정보에 관해 아는 것
▪
관련된 객체에 관해 아는 것
▪
자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
•
책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소다. 객체지향 설계의 예술은 적절한 객체에게 적절한 책임을 할당하는 데에 있다.
•
객체의 책임을 이야기할 때 일반적으로 외부에서 접근 가능한 공용 서비스의 관점에서 이야기한다.
◦
즉, 책임은 객체의 외부에 제공해 줄 수 있는 정보와 외부에 제공해 줄 수 있는 서비스의 목록이다.
•
따라서 책임은 객체의 공용 인터페이스를 구성한다.
책임과 메시지
•
협력 안에서 객체는 다른 객체가 요청한 경우에만 자신에게 주어진 책임을 수행한다.
•
결국 한 객체가 다른 객체에게 전송한 요청은 그 요청을 수신한 객체로 하여금 책임을 수행하도록 한다.
•
이처럼 객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것을 메시지 전송이라고 한다.
◦
따라서 두 객체 간의 협력은 메시지를 통해 이뤄진다고 할 수 있다.
◦
메시지를 전송함으로써 협력을 요청하는 객체를 송신자라고 하고 메시지를 받아 요청을 처리하는 객체를 수신자라고 한다.
◦
메시지는 협력을 위해 한 객체가 다른 객체에 접근할 수 있는 유일한 방법이다.
•
책임이 협력이라는 문맥 속에서 요청을 수신하는 한 쪽의 객체 관점에서 무엇을 할 수 있는지를 나열하는 것이라면 메시지는 협력에 참여하는 두 객체 사이의 관계를 강조한 것이다.
◦
협력이 가능하다는 것은 특정한 메시지를 송신자가 보냈을 때, 해당 메시지를 수신자가 받을 수 있음을 의미한다.
•
한 가지 주의할 점은 책임과 메시지의 수준이 같지는 않다는 점이다.
◦
책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것이다.
◦
책임을 결정한 후 실제로 협력을 정제하면서 이를 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는 것이 일반적이다.
•
객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메시지를 수신할 것인지를 결정하는 것으로부터 시작된다.
◦
어떤 클래스가 필요하고 어떤 메소드를 포함해야 하는지를 결정하는 것은 책임과 메시지에 대한 대략적인 윤곽을 잡은 후에 시작해도 늦지 않다.
역할
책임의 집합이 의미하는 것
•
협력의 관점에서 어떤 객체가 어떤 책임의 집합을 수행한다는 것이 무엇을 의미하는 걸까?
•
이는 어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 어떤 역할을 부여받았음을 의미한다.
•
역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이기 때문에 중요하다.
판사와 증인
•
이번 내용에선 판사의 역할이 여왕에게 위임되는 것과 증인의 역할이 공작 부인의 요리사, 앨리스로 넘어가는 내용이었다.
•
역할이 위임되었다고 해서 재판의 흐름이 변경되지는 않았다. 차이점이라고는 왕대신 여왕이, 모자 장수 대신 요리사나 앨리스가 협력에 참여한다는 점 뿐이다.
•
이 세 개의 협력을 별도로 관리하고 유지해야 하는가? 만약 재판 과정이 바뀐다면 세 개의 협력 과정을 일일이 쫓아다니며 수정해야 할까?
역할이 답이다
•
여기서 등장하는 협력의 형태는 총 셋이다.
◦
왕, 하얀 토끼, 모자 장수
◦
왕, 하얀 토끼, 요리사
◦
여왕, 하얀 토끼, 앨리스
•
여기서 문제는 협력에 참여하는 등장인물을 제외한 나머지 과정이 너무나도 유사하기 때문에 하나의 협력으로 단순화하고 싶다는 것이다.
•
방법은 간단하다. 재판이라는 협력 과정 속 왕과 여왕은 판사의 역할을 수행한다. 모자 장수와 요리사 그리고 앨리스는 증인의 역할을 수행한다.
◦
따라서 판사와 증인이라는 역할을 사용하면 세 가지 협력을 모두 포괄할 수 있는 하나의 협력으로 추상화할 수 있다.
•
역할은 협력 내에서 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 협력 안에서 역할은 이 자리에 해당 역할을 수행할 수 있는 어떤 객체라도 대신할 수 있습니다.라고 말하는 것과 같다.
•
그렇다면 어떤 객체라도 판사나 증인의 역할을 수행할 수 있을까? 물론 아니다. 역할을 대체하기 위해서는 각 역할이 수신할 수 있는 메시지를 동일한 방식으로 이해해야 한다.
◦
따라서 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정된다.
•
앞서 메시지가 책임을 의미한다고 했다. 결국 동일한 역할을 수행할 수 있다는 점은 해당 객체들이 협력 내에서 동일한 책임의 집합을 수행할 수 있다는 것을 의미한다.
•
역할은 객체지향 설계의 단순성, 유연성, 재사용성을 뒷받침하는 핵심 개념이다.
◦
역할의 개념을 사용하면 유사한 협력을 추상화하여 과정을 단순화할 수 있다.
◦
다양한 객체들이 협력에 참여하는 것이 가능해지면서 협력이 좀 더 유연해진다.
◦
다양한 객체들이 동일한 협력에 참여할 수 있으므로 재사용성이 높아진다.
협력의 추상화
•
역할의 가장 큰 가치는 하나의 협력 안에서 여러 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화할 수 있다는 것이다.
•
협력의 추상화는 설계자가 다뤄야하는 협력의 개수를 줄이며 구체적인 객체를 추상적인 역할로 대체함으로써 협력의 양상을 단순화한다.
•
역할을 이용하면 협력을 추상화함으로써 단순화할 수 있다. 구체적인 객체로 추상적인 역할을 대체하여 동일한 구조의 협력을 다양한 문맥에서 재사용할 수 있는 능력은 과거의 전통적인 패러다임과 구분되는 객체지향만의 힘이다.
⇒ 이 능력은 근본적으로 역할의 대체 가능성에서 비롯된다.
대체 가능성
•
역할은 협력 안에서 구체적인 객체로 대체될 수 있는 추상적인 협력이다. 따라서 본질적으로 역할은 다른 객체에 의해 대체 가능함을 의미한다.
•
객체가 역할을 대체하기 위해선 행동이 호환되어야 한다는 점에 주목하자.
◦
어떤 객체가 증인이라는 역할을 대체할 수 있는 이유는 그 객체가 증인석에 입장할 수 있고 증언할 수 있기 때문이다.
•
결국 객체는 협력 안에서 역할으 수행하는 행동을 그대로 수행할 수 있어야 한다.
◦
객체지향의 용어를 빌려 설명하면 객체가 역할을 대체 가능하려면 협력 안에서 역할이 수행하는 모든 책임을 동일하게 수행할 수 있어야 한다.
•
객체가 역할에 주어진 책임 이외에 다른 책임을 수행할 수도 있다는 사실을 주목하자.
◦
왕은 판사의 역할을 수행할 수 있지만 재판을 수행하는 책임 뿐만 아니라 국정을 돌봐야 할 추가적인 책임을 가지고 있다.
•
결국 객체는 역할이 암시하는 책임보다 더 많은 책임을 가질 수 있다. 따라서 대부분의 경우에 객체의 타입과 역할 사이에는 일반화/특수화 관계가 성립하는 것이 일반적이다.
◦
일반화/특수화 관점에서 좀 더 일반적인 개념을 의미하는 역할은 일반화이며 좀 더 구체적인 개념을 의미하는 객체의 타입은 특수화다.
◦
역할이 협력을 추상적으로 만들 수 있는 이유는 역할 자체가 객체의 추상화이기 때문이다.
•
역할의 대체 가능성은 행위 호환성을 의미하고 행위 호환성은 동일한 책임의 수행을 의미한다.
객체의 모양을 결정하는 협력
흔한 오류
•
사람들이 흔하게 가지는 객체지향에 대한 첫 번째 선입견은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 것이다.
◦
물론 객체가 상태의 일부로 데이터를 가지고 있는 것은 사실이지만 데이터는 단지 객체가 행위를 수행하는 데 필요한 재료일 뿐이다.
◦
객체가 존재하는 이유는 행위를 수행하며 협력에 참여하기 위해서다 따라서 실제로 중요한 것은 객체의 행동, 즉 책임이다.
•
두 번째 선입견은 객체지향이 클래스와 클래스 간의 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다는 것이다.
◦
중요한 것은 정적인 클래스가 아닌 협력에 참여하는 동적인 객체이며 클래스는 단지 시스템에 필요한 객체를 표현하고 생성하기 위해 프로그래밍 언어가 제공하는 구현 메커니즘이라는 사실을 기억하라.
◦
객체지향의 핵심은 클래스를 어떻게 구현할 것인가가 아니라 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지를 결정하는 것이다.
•
객체지향 입문자들이 데이터나 클래스를 중심으로 어플리케이션을 설계하는 이유는 협력이라는 문맥을 고려하지 않고 각 객체를 독립적으로 바라보기 때문이다.
•
실제로 동작하는 어플리케이션을 효과적으로 구축하기 위해서는 객체가 참여하는 협력을 우선적으로 고려해야 한다.
•
이런 오류들을 바로잡기 위해 우리가 해야할 일은 무엇일까? 바로 객체를 섬으로 바라보던 잘못된 시선을 거두고 올바른 곳을 바라보는 것이다.
협력을 따라 흐르는 객체의 책임
•
따라서 우리는 올바른 객체를 설계하고 싶다면 먼저 견고하고 깔끔한 협력을 설계해야 한다.
◦
협력을 설계한다는 것의 의미는 설계에 참여하는 객체들이 주고받을 요청과 응답의 흐름을 결정한다는 것이다.
◦
이렇게 결정된 요청과 응답의 흐름은 객체가 협력에 참여하기 위해 수행될 책임이 된다.
•
객체에게 책임을 할당하고 나면 책임은 객체가 외부에 제공하게 될 행동이 된다. 협력이라는 문맥에서 객체가 수행하게 될 적절한 책임, 즉 행동을 결정한 후에 그 행동을 수행하는 데 필요한 데이터를 고민해야 한다.
◦
객체가 협력에 참여하기 위해 필요한 데이터와 행동이 어느 정도 결정된 후에 클래스의 구현 방법을 결정해야 한다.
•
결과적으로 클래스와 데이터는 협력과 책임의 집합이 어느정도 결정된 후에야 무대 위에 등장할 수 있다.
•
객체의 행위에 초점을 맞추기 위해선 협력이라는 실행 문맥 안에서 책임을 분배해야 한다. 각 객체가 가져야 하는 상태와 행위에 대해 고민하기 전에 그 객체가 참여할 문맥인 협력을 정의하라.
◦
객체지향 시스템에서 가장 중요한 것은 충분히 자율적인 동시에 충분히 협력적인 객체를 창조하는 것이다.
◦
이 목표를 달성할 수 있는 가장 쉬운 방법은 객체를 충분히 협력적으로 만든 후에 협력이라는 문맥 안에서 객체를 충분히 자율적으로 만드는 것이다.
객체지향 설계 기법
책임 주도 설계
•
협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당하는 방식으로 어플리케이션을 설계하는 방법이다.
◦
이는 객체지향 패러다임의 전문가들이 어플리케이션을 개발할 때 어떤 방식으로 사고하고 무엇을 기반으로 의사결정을 내리는지 잘 보여준다.
•
객체지향 시스템은 역할과 책임을 수행하는 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니며 시스템의 더 큰 목표를 달성하기 위해 다른 객체와 협력하는 사회적인 존재다.
◦
객체지향 시스템의 목적은 사용자의 요구를 만족시킬 수 있는 기능을 제공하는 동시에 이해하기 쉽고, 단순하며, 유연한 상호작용을 제공하는 객체들의 공동체를 구축하는 것이다.
◦
객체지향적 설계란 어플리케이션의 기능을 구현하기 위한 협력 관계를 고안하고 협력에 필요한 역할과 책임을 식별한 후, 이를 수행할 수 있는 적절한 객체를 식별해 나가는 과정이다.
◦
객체지향 설계의 핵심은 올바른 책임을 올바른 객체에게 할당하는 것이다.
•
시스템의 기능은 더 작은 규모의 책임으로 분할되고 각 책임은 책임을 수행할 적절한 객체에게 할당된다. 객체가 책임을 수행하는 도중 스스로 처리할 수 없거나 필요한 정보가 있는 경우, 적절한 객체를 찾아 필요한 작업을 요청한다.
◦
객체가 다른 객체에게 작업을 요청하는 행위를 통해 결과적으로 객체들 간의 협력 관계가 만들어진다.
◦
만약 책임을 여러 종류의 객체가 수행할 수 있다면 협력자는 객체가 아니라 추상적인 역할로 대체되어야 한다.
•
책임 주도 설계에서는 시스템의 책임을 객체의 책임으로 변환하고 각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아 해당 협력자에게 책임을 할당하는 순차적인 방식으로 협력 공동체를 구축한다.
◦
이는 개별적인 객체의 상태가 아닌 객체의 책임과 상호작용에 집중한다.
•
협조적이고 성실한 객체 시민들로 구성된 객체지향 시스템을 설계하는 절차는 다음과 같이 요악할 수 있다.
◦
시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
◦
시스템 책임을 더 작은 책임으로 분할한다.
◦
분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 전달한다.
◦
객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우, 이를 책임질 적절한 객체 또는 역할을 찾는다.
◦
해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.
•
역할, 책임, 협력은 유연하고 견고한 객체지향 시스템을 만드는 데 필요한 가장 중요한 재료다. 그 외의 장치는 단지 이들을 보완하고 복잡도를 줄이기 위한 보조 재료일 뿐이다.
⇒ 이 셋에 집중하자.
디자인 패턴
•
전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음으로 패턴은 전문가들이 특정 문제를 해결하기 위해 이미 식별해 놓은 역할, 책임, 협력의 모음이다.
◦
패턴을 알고 있다면 바퀴를 반복적으로 발명할 필요가 없다. 여러분이 필요로 하는 역할, 책임, 협력이 디자인 패턴 안에 존재하기 때문이다.
•
책임 주도 설계는 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차를 제시한다. 반면 디자인 패턴은 이런 설계의 결과를 표현한다.
•
패턴은 모범이 되는 설계로, 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험이다.
•
일반적으로 디자인 패턴은 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍으로 정의된다.
◦
이는 해결하려고 하는 문제가 무엇인지를 명확하게 서술하고, 패턴을 적용할 수 있는 상황과 적용할 수 없는 상황을 함께 설명한다.
◦
또한 반복해서 일어나는 특정한 상황에서 어떤 설계가 왜 더 효과적인지 이유를 설명한다.
•
디자인 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.
◦
만약 특정한 상황에 적용 가능한 디자인 패턴을 잘 알고 있다면 책임 주도 설계의 절차를 따르지 않고도 객체들의 역할, 책임, 협력 관계를 쉽게 포착할 수 있을 것이다.
•
디자인 패턴은 책임 주도 설계의 결과물인 동시에 지름길이다.
테스트 주도 개발
•
테스트 주도 개발은 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 어플리케이션을 완성해가는 방식을 따른다.
◦
이는 테스트가 아닌 설계를 위한 기법이다.
◦
테스트는 단지 이 기법을 통해 얻을 수 있는 별도의 보너스 같은 것이며 실제 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 식별된 역할, 책임, 협력이 적합한지를, 테스트 가능성으로 평가받는 것이다.
•
애자일 방법론의 한 종류인 XP의 기본 프랙티스로 소개되면서 주목받기 시작한 설계 기법이다.
◦
기본적인 흐름은 실패하는 테스트를 작성하고 테스트를 통과하는 가장 간단한 코드를 작성한 후, 리팩토링을 통해 중복을 제거하는 것이다.
•
테스트 주도 개발이 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템을 개발할 수 있게 하는 최상의 방안인 것은 맞지만 초보자들에겐 어떤 테스트를 어떤 식으로 작성해야 할지 결정하는 데 큰 어려움을 느낀다.
◦
테스트 주도 개발은 객체가 이미 존재한다고 가정하고 객체에게 어떤 메시지를 전송할 것인지에 관해 먼저 생각하라고 충고한다.
⇒ 그러나 이 같은 종류의 충고는 역할, 책임, 협력의 관점에서 객체를 바라보지 않는 상태에선 무의미하다.
•
테스트 주도 개발은 테스트 작성이 아닌 책임을 수행하는 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드 형태로 작성하는 것이다.
