테스트 주도 개발은 객체지향 설계도구

* 이 글은 책을 읽고 주관적인 생각과 함께 요약 정리한 글입니다.

 

 

 

제목 : 객체지향의 사실과 오해

저자 : 조영호

범위 : 04 역할, 책임, 협력

 

 

---

 

요약 정리

• 협력
  • 중요한 것은 개별 객체가 아니라 객체들 사이에 이뤄지는 협력이다.
  • 협력의 본질은 요청과 응답으로 연결되는 네트워크다.
• 첵임
  • 책임은 객체의 외부에 제공해 줄 수 있는 정보(아는 것)
    • 개인적인 정보에 관해 아는 것
    • 관련된 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
  • 외부에 제공해 줄 수 있는 서비스(하는 것)의 목록이다.
    • 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
    • 다른 객체의 행동을 시작시키는 것
    • 다른 객체의 활동을 제어하고 조절하는 것
• 역할
  • '왕'과 '여왕'이 객체라면 '판사'는 그들의 역할이다.
  • 같은 역할의 객체들, 즉 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체이다.
  • 역할은 객체지향 설계의 단순성, 유연성, 재사용성을 뒷받침하는 핵심 개념이다.
  • 역할의 가장 큰 가치는 하나의 협력 안에 여러 종류의 객체가 참여하면서 협력을 추상화 할 수 있는 것이다.
  • 구체적인 객체를 추상적인 역할로 대체함으로써 하나의 추상적인 협력을 만들어 낸다. 
  • 이러한 역할의 대체 가능성은 동일한 구조의 협력을 다양한 문맥에서 재사용할 수 있도록 한다.
  • 역할의 대체 가능성은 행위 호환성을 의미하고, 행위 호환성은 동일한 책임의 수행을 의미한다.
• 흔한 오류
  
  • 객체는 데이터를 저장하기 위해 존재한다? 아니다.
  • 객체가 존재하는 이유는 행위를 수행하며 협력에 참여하기 위해서다. 따라서 실제로 중요한 것은 객체의 행동, 즉 책임이다.
• 객체 설계 순서
  • 첫 번째, 요청과 응답의 흐름을 결정한다. -> 하는 것
  • 두 번째, 행동에 필요한 데이터를 결정한다. -> 아는 것
  • 세 번째, 클래스 등으로 구현 방법을 결정한다. 
• 책임 주도 설계
  • 책임 주도 설계는 개별적인 객체의 상태가 아니라 객체의 책임과 상호작용에 집중한다.
  • 순서
    • 시스템이 사용자에게 제공해야 하는 서비스, '시스템 책임'을 파악한다.
    • '시스템 책임'을 더 작은 책임으로 쪼갠다.
    • 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 만든다.
    • 다른 객체의 도움이 필요한 경우 이를 책임질 객체 또는 역할을 만든다.
    • 협력을 통해 '시스템 책임'을 이끌어 낸다.
• 디자인 패턴
  • 디자인 패턴은 책임 주도 설계의 결과이며 역할, 책임, 협력의 템플릿이다.
  • 즉 디자인 패턴을 알아두면 빠르게 책임 주도 설계를 구현할 수 있다.
• 테스트 주도 개발
  • 테스트 주도 개발은 응집도가 높고 결합도가 낮은 시스템을 개발하는 최상의 프랙티스다.
  • 테스트 주도 개발은 책임을 수행할 객체가 어떤 결과를 반환하고 어떤 객체와 협력하는지에 대한 기대를 코드의 형태로 작성하는 것이다.
  • 테스트 주도 개발은 책임 주도 설계를 통해 도달해야 하는 목적지를 테스트라는 안전장치를 통해 좀 더 빠르고 견고한 방법으로 도달하는 최상의 설계 프랙티스다.
  • 더 쉽게 말하자면, 테스트 주도 개발은 객체지향에 대한 설계도구이며 테스트 코드는 객체에 대한 기대값이다.

 

하고 싶은 말

• 역할은 객체의 복수형태라고 생각하니 이해하기 수월했다.
• 설계의 순서를 정리해두니 어떻게 코딩을 해야하는지 알 것 같다.
• 지금까지는 객체를 만들 순 있어도 객체지향적 사고를 하지는 않았던 것 같다.
• 디자인 패턴은 객체지향 템플릿이라는 것을 알게되었다.
• 테스트 주도 개발은 객체지향과 별개라고 생각했는데 오히려 최적의 객체지향 설계도구라는 것을 알게되었다.
• 점점 객체지향이 이해되는 듯 하다. 내 프로젝트에 적용하면서 체득하고 싶다.