책을 읽게 된 이유

이 책을 알게 된 계기는 우테코 프리코스를 마친 후 받은 불합격 메일에 첨부된 학습 로드맵이었다. 추천된 책이니 읽어봐야겠다는 생각이 들었다. 프론트엔드 개발자로서 백엔드 개발자와 협업할 일이 많을 텐데, 그들과 원활하게 소통하려면 객체지향 개념을 이해할 필요가 있다고 느꼈다.

백엔드 시스템은 대부분 객체지향적인 구조로 설계되며, API 설계, 도메인 모델, 데이터 흐름 등을 이해하려면 객체지향 개념이 필수적이다. 그래서 객체지향 개념을 알고 있으면 더 효과적으로 대화할 수 있지 않을까? 하는 기대감에 읽게 되었다.

아래 내용은 책을 읽으면서 중요하다고 생각한 문장을 기록한 후, 생성형 AI의 도움을 받아 정리한 것이다.

객체지향의 본질

객체지향의 가장 중요한 본질은 자율적인 객체들의 협력이다.

객체

• 자율적인 객체
  • 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체
• 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행한다.
  • 역할? 관련된 책임의 집합 (Ex) 앨리스, 모자 장수, 요리사라는 객체는 재판에서 증인이라는 역할을 가짐)
• 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는데 적합한 메서드를 자율적으로 선택한다.
  • 메시지? 객체지향의 세계에서 존재하는 단 한가지 의사소통 수단

역할, 책임, 협력

역할

• 역할은 협력 안에서 구체적인 객체로 대체될 수 있는 추상적인 협력자다.

책임

• 객체지향의 세계에서는 어떤 객체가 어떤 요청에 대해 대답해줄 수 있거나, 적절한 행동을 하는 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.
• 협력이라는 문맥 속에서 요청을 수신하는 한 쪽의 객체 관점에서 무엇을 할 수 있는지를 나열하는 것이다.

협력

• 시스템의 기능은 객체들의 협력으로 구현된다.
• 협력은 요청(메시지 전송)과 응답으로 구성된다.
• 객체는 협력 안에서 특정한 역할과 책임을 가진다.

주요 오해와 사실

클래스가 객체지향의 핵심이다.

• 오해
  • 클래스 위주의 설계가 좋은 객체지향 설계다.
• 사실
  • 클래스는 단지 객체를 만드는 구현 메커니즘일 뿐이다.
  • 중요한 것은 객체들의 역할, 책입, 협력 관계이다.

객체지향은 현실 세계의 모방이다.

• 오해
  • 객체지향이 현실을 그대로 모방한다.
• 사실
  • 객체지향은 현실을 은유하여 유용한 객체들을 창조한다.

클래스와 타입은 동일하다.

• 오해
  • 클래스와 타입은 동일한 개념이다.
• 사실
  • 클래스는 타입의 구현 외에도 코드를 재사용하는 용도로도 사용되기 때문에 클래스와 타입을 동일시하는 것은 오해와 혼란을 불러일으키곤 한다.
  • 클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘이다.

객체는 데이터 저장소이다.

• 오해
  • 필요한 데이터를 저장하기 위해 객체가 존재한다.
• 사실
  • 객체는 행위를 수행하며 협력에 참여하기 위해 존재한다.
  • 객체의 행동, 즉 책임이 중요하다.

객체지향을 클래스 간의 정적인 관계를 설계하는 방식이다.

• 오해
  • 객체지향이 클래스와 클래스 간의 관계를 표현하는 시스템의 정적인 측면에 중점을 둔다는 것이다.
• 사실
  • 객체지향의 핵심은 협력안에서 어떤 책임과 역할을 수행할 것인지 결정하는 것이다.

객체지향 설계 기법

역할, 책임, 협력의 관점에서 애플리케이션을 설계하는 유용한 세 가지 기법

책임 주도 설계

협조적이고 성실한 객체 시민들로 구성된 객체지향 시스템을 설계하는 절차:

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

디자인 패턴

패턴은 모범이 되는 설계다. 패턴은 특정한 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험이다.

일반적으로 디자인 패턴은 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍으로 정의된다. 패턴은 해결하려고 하는 문제가 무엇인지를 명확하게 서술하고, 패턴을 적용할 수 있는 상황과 적용할 수 없는 상황을 함께 설명한다. 패턴은 반복해서 일어나는 특정한 상황에서 어떤 설계가 왜 더 효과적인지에 대한 이유를 설명한다.

디자인 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.

테스트 주도 개발

테스트 주도 개발은 애자일 방법론의 한 종류인 XP(eXtreme Programming)의 기본 프랙티스로 소개되면서 주목받기 시작한 설계 기법이다.

테스트 주도 개발의 기본 흐름은 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후, 리팩터링을 통해 중복을 제거하는 것이다.

테스트 주도 개발의 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 식별된 역할, 책임, 협력이 적합한지를 피드백 받는 것이다.

올바른 객체지향 설계를 위한 순서

1. 협력을 먼저 설계하라.
2. 협력에 필요한 책임을 식별하라.
3. 책임을 수행할 적절한 객체를 선택하라.
4. 객체가 책임을 수행하는 데 필요한 데이터를 결정하라.
5. 책임과 데이터를 클래스로 구현 하라.

마무리

이 책은 '이상한 나라의 앨리스'라는 소설을 예시로 객체지향을 설명해주기 때문에 처음에는 비교적 쉽게 읽을 수 있었다. 하지만 객체지향에 대해 알게 된 새로운 정보가 많아 몇 번을 읽어야 이해가 되는 부분도 있었다. 그럼에도 불구하고 책을 다 읽고 나니 객체지향에 조금 더 친숙해졌고, 이해가 되기 시작했다.

책을 읽고 나서 가장 기억에 남는 개념은 '객체지향의 세계는 자율적인 객체들의 협력, 자율적인 객체들의 공동체'이다. 책에서 반복적으로 언급해주어서 이 개념이 머릿속에 깊이 남아 있다. 또한, 설계를 할 때 중요한 요소로 언급되는 "역할", "책임", "협력"이 얼마나 핵심적인 부분인지 알게 되었다.

책을 통해 다룬 객체지향에 대한 오해들은 모두 제가 잘못 이해했던 부분들이었고, 특히 객체지향은 단순히 현실 세계를 모방하는 것이 아니라 현실을 은유하여 유용한 객체들을 창조하는 방식이라는 점은 정말 큰 충격이었다. 그동안 단단히 오해하고 있었다. 지금이라도 이 책을 읽은 것이 정말 다행이라는 생각이 들었다.