객체지향의 사실과 오해

회사에서 스터디를 하면서 같이 읽은 책이다.

자바를 실무에서 10년 넘게 써왔다. 클래스, 상속, 다형성. 객체지향 하면 떠오르는 단어들이 이미 익숙하게 머릿속에 자리 잡혀 있었다. 그런데 이 책을 읽으면서 문득 불편한 질문이 떠올랐다.

객체지향의 사실과 오해

나는 지금까지 객체지향을 제대로 이해하고 있었던 걸까?

클래스가 아니라 객체를 봐야 한다

책이 초반부터 던지는 핵심 메시지는 명확하다. 객체지향의 중심은 클래스가 아니라 객체라는 것이다. 클래스는 객체를 만들기 위한 도구일 뿐이고, 설계의 중심에는 객체와 객체 사이의 협력이 있어야 한다고 말한다.

돌이켜 보면 나는 클래스 다이어그램을 먼저 그리고, 상속 구조를 먼저 고민하는 방식으로 설계를 시작해 왔다. 저자의 표현을 빌리자면 나는 그동안 클래스 지향 설계를 하면서 객체지향이라고 착각해 온 셈이다.

역할, 책임, 협력

이 책에서 가장 인상적이었던 프레임은 객체를 역할, 책임, 협력이라는 세 가지 관점으로 바라보는 것이다. 객체는 혼자 존재하는 독립적인 개체가 아니라, 기능을 이루기 위한 협력 공동체의 일원이다.

협력이 먼저 정의되고, 그 협력 안에서 역할이 도출되며, 역할에 따라 책임이 부여된다. 그리고 그 책임을 수행할 객체가 결정된다. 이 순서가 뒤집히면 설계가 어긋나기 시작한다는 것, 현업에서 몇 번이나 겪어온 상황이었다.

오해의 정체

오랫동안 “객체지향을 잘 한다”는 것이 디자인 패턴을 많이 아는 것, 또는 클래스 계층을 잘 설계하는 것이라고 막연히 생각해 왔다. 하지만 이 책은 그게 수단일 뿐이라는 걸 천천히, 그러나 확실하게 짚어 준다.

인터페이스가 왜 중요한지, 메시지가 왜 메서드보다 먼저 정의되어야 하는지, 캡슐화가 단순히 private 접근제한자의 문제가 아닌 이유가 무엇인지. 알고 있다고 생각했던 개념들이 실은 표면만 알고 있었던 것임을 깨달았다.

마치며

두껍지 않고, 코드도 별로 없다. 그런데 읽는 내내 머릿속에서 계속 무언가가 재조립되는 느낌이 들었다. 개념을 깊이 이해한 저자가 쓴 글은 이런 인상을 남긴다.

자바를 오래 쓴 개발자일수록 오히려 이 책이 낯설게 읽힐 수 있다. 익숙한 단어들이 전혀 다른 맥락으로 사용되기 때문이다. 하지만 그 낯섦이 이 책의 가치이기도 하다. 자신이 알고 있다고 생각하는 것을 다시 질문하게 만든다는 것, 그게 좋은 책의 조건이라고 생각한다.

References