들어가며

많은 개발자분들이 추천하는 조영호 님의 객체지향의 사실과 오해를 드디어 읽고 리뷰를 남깁니다.

책의 내용 전체를 정리하고 요약하기보다는 제가 중요하다고 느끼거나 흥미로웠던 부분을 위주로 기록을 남길까 합니다.

만약 객체지향 프로그래밍을 막 시작했거나 배운 대학생 때 이 책을 접했더라면 아마 혼자서는 끝까지 못 읽었을 것 같다는 생각이 들었습니다. 왜냐하면 그 당시에 저는 객체지향의 개념을 제대로 이해하고 있지 못했습니다. (C언어가 최고라고 생각하던 시절)

객체지향의 큰 특징과 장점을 어느 정도 알게 된 지금 이 책은 고개를 끄덕이며 읽을 수 있었습니다. 대학생 때 교수님께서 수업 시간에 이 책을 다뤄주셨다면 얼마나 좋았겠느냐는 생각을 하게 됩니다. 각설하고 본격적으로 리뷰를 시작하겠습니다.

리뷰

행동이 상태를 결정 (p64)

이 한 문장이 책의 내용을 관통하는 핵심 문장이라고 생각합니다. 객체지향 프로그래밍에서 가장 중요한 것은 클래스가 아니라 객체이고, 객체의 상태가 중요한 것이 아니라 객체와 객체 간의 협력하는 행동이라는 것입니다.

즉, 설계 단계에서 개발자는 객체 간의 협력인 행동을 먼저 정의하고 이후에 그에 맞는 객체를 고민해야 합니다. 다르게 말하면 메시지가 우선이 되고 메시지를 수행 가능한 객체를 찾아야 하는 것입니다. 객체의 상태를 정의하는 것은 그다음 문제입니다.

의인화 (p67)

보통 객체지향을 처음 배울 때 현실 세계를 빗대어 설명합니다. 실제로 객체지향 세계와 현실 세계는 비슷한 면이 많습니다. 그래서 이해를 돕는데 현실 세계를 예로 드는 것은 굉장히 좋은 방법입니다. 하지만, 객체지향 세계와 현실 세계는 다릅니다.

객체지향 세계의 객체는 더 많은 권한을 갖습니다. 예를 들어 현실 세계의 카페를 예로 들자면 손님이 보는 메뉴판이라는 객체는 메뉴를 보여줄 뿐, 주체적으로 하는 것은 없습니다. 하지만, 객체지향 세계에서는 메뉴판이라는 객체가 손님이 선택한 메뉴를 찾는 역할을 수행합니다. 마치 객체가 살아 숨 쉬는 느낌을 줍니다.

추상화를 통한 복잡성 극복 (p76)

지하철 노선도는 추상화를 이해하는데 정말 완벽한 예시였습니다. 지하철 노선도를 보면 굉장히 보기 쉽게 되어있습니다. 하지만, 우리는 지하철 노선도를 통해 역과 역 사이의 거리(km)나 지형 등은 전혀 알 수가 없습니다.

하지만 그게 중요할까요? 지하철 노선도의 핵심은 역과 역 사이의 정거장 수 혹은 환승 방법 등이 될 것입니다. 그것에 초점을 맞춰 현재의 지하철 노선도가 탄생했습니다. 다른 부수적인 요소는 정말 중요한 것에 방해가 될 뿐일 것입니다.

추상화는 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것이다.

주의할 것은 추상화는 너무 단순해서도 안 되고, 너무 구체적이어서도 안 된다는 것입니다.

협력 (p110)

• 협력의 본질은 요청과 응답으로 연결되는 객체들의 네트워크이다.
• 어떤 객체가 특정한 요청을 받아들일 수 있는 이유는 그 요청에 대해 적절한 방식으로 응답하는 데 필요한 지식과 행동 방식을 가지고 있기 때문이다.

책임 (p114)

• 어떤 객체가 특정한 요청에 대해 대답하거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 갖는다고 한다.
• 협력에 참여하는 객체들은 목표를 달성하는 데 필요한 책임을 수행한다. 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합이다.
• 객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메시지를 수신할 것인지를 결정하는 것으로부터 시작된다. 어떤 클래스가 필요하고 어떤 메서드를 포함해야 하는지를 결정하는 것은 책임과 메시지에 대한 대략적인 윤곽을 잡은 후에 시작해도 늦지 않다.

역할 (p119)

• 역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있다. 또한 다양한 객체들이 협력에 참여할 수 있으므로 협력이 좀 더 유연해지며 다양한 객체들이 같은 협력에 참여할 수 있기 때문에 재사용성이 높아진다. 역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(reusability)을 뒷받침하는 핵심 개념이다.

객체지향 설계 기법 (p130)

책임-주도 설계

책임-주도 설계는 객체의 역할, 책임, 협력을 고안하려는 방법과 절차를 제시한다.

객체지향 시스템 설계 절차 요약

• 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
• 시스템 책임을 더 작은 책임으로 나눈다.
• 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
• 객체가 책임을 수행하는 중에 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
• 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

디자인 패턴

• 디자인 패턴은 책임-주도 설계의 결과를 표현한다.
• 디자인 패턴은 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험이다.

테스트-주도 개발(TDD)

• 테스트-주도 개발은 테스트를 작성하는 것이 아니라 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다.

책임의 자율성이 협력의 품질을 결정 (p173)

1. 자율적인 책임은 협력을 단순하게 만든다.
2. 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.
   (캡슐화 - 인터페이스와 구현이 분리)
3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
   (캡슐화되기 때문에 두 객체 간의 결합도가 낮아진다.)
4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
   (설계가 유연해지고 재사용성이 높아진다.)
5. 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.

기능과 구조의 통합 (p197)

도메인 모델은 구조를, 유스케이스는 협력의 출발점인 시스템 책임을 제공합니다. 쉽게 얘기해서 도메인 모델은 안정적인 구조를 의미하고, 유스케이스는 불안정한 기능을 의미합니다. 여기서 '안정적/불안정'이란 변경에 대한 상대적인 안정성을 의미합니다.

도메인 모델은 쉽게 말해 현업에 있는 사람들이 잘 아는 업무 flow가 될 것입니다. 특별한 변경사항이 없는 한 이 업무 flow는 오래 지속될 것이며 변경에 적기 때문에 상대적으로 안정적이라고 볼 수 있습니다.

유스케이스의 경우 고객이 원하는 기능을 서술한 시나리오입니다. 당연히 요구사항은 언제든지 변경될 수 있으므로 불안정적이라고 볼 수 있습니다.

불안정한 기능을 안정적인 구조에 담음으로써 변경에 대한 파급효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야 할 기본적인 설계 능력이다.

도메인 모델과 유스케이스를 통합하여 하나의 flow를 설계하고, 이는 코드로 구현하면 됩니다. (여러 방식 중 하나의 방식입니다)

중요한 것은 견고한 객체지향 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다는 것이다.

참고 (p222)

구현하지 않고 머릿속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경된다. 설계 작업은 구현을 위한 스케치를 작성하는 단계지 구현 그 자체일 수는 없다. 중요한 것은 설계가 아니라 코드다. 따라서 협력을 구상하는 단계에 너무 오랜 시간을 쏟지 말고 최대한 빨리 코드를 구현해서 설계에 이상이 없는지, 설계가 구현 가능한지를 판단해야 한다. 코드를 통한 피드백 없이는 깔끔한 설계를 얻을 수 없다.

마치며

간단하게 정리하려 했는데, 생각보다 길어진 것 같습니다. 그만큼 중요한 내용이 많았던 것 같습니다. 이 책은 앞으로 개발을 하면서도 한 번씩 읽으면 좋은 책인 것 같습니다. 잊고 있던 부분을 다시 상기시켜주고, 중요한 것을 짚어주는 나침반 같은 책이었습니다.