[책 리뷰] 객체지향의 사실과 오해, 오브젝트

객체지향의 사실과 오해는 약 2달, 오브젝트는 부록을 포함해 약 600페이지 가량의 오브젝트 책을 5달에 걸쳐 다 읽었다.

중간에 다른 일들이 바빠져 2달 정도는 쉬었지만 아무튼 정말 많은 내용을 담고 있는 책 두권을 어찌저찌 한번 읽어봤다.

객체지향의 사실과 오해는 책이 얇기도 하고(읽고 나서 시간이 지나 내용을 까먹기도 했고) 가볍게 읽을 수 있어 두번 읽었다.

 

오브젝트를 선택한 계기는 '객체지향의 사실과 오해' 책을 읽고 나서 더 디테일한 코드 레벨의 관점을 '오브젝트'에서 얻을 수 있겠다고 생각했기 때문이기도 하고 여전히 올바른 객체지향 프로그래밍이 무엇일까에 대해 다른 사람들의 이야기가 더 궁금했던 이유도 있다.

 

객체지향의 사실과 오해는 작년 중순(22년 8월)쯤에 처음 읽었는데, 당시에 자바로 코드를 작성하면서 '돌아가긴 하는데 이게 맞나?' 하는 생각으로부터 올바른 객체지향 프로그래밍에 대해 궁금해져 읽게 됐다.

 

누군가 한번씩 '그래서 객체지향 프로그래밍이 뭔데?' 라고 물을 때면 당시 100% 이해가 되진 않았지만 '역할 책임 협력을 설계하고 구현하는 것이다' 라며 책의 내용을 이야기 하면서 계속 용어에 익숙해지려고 노력했었고, 이 책을 읽으면서 어렴풋이 코드 레벨에서 객체를 의식(상상)하면서 코드를 짜기 시작하는데 많은 도움이 됐던 것 같다.

 

이후로도 나는 꾸준히 올바른 설계(나는 요구사항 변경에 신속하게 대응할 수 있는 코드 설계를 지향한다)가 무엇인가에 대해 고민하고 정답이 되는 설계라는 것은 없다라고 생각하면서도 나름의 기준을 세우고자 노력하고 있다.

 

오브젝트는 그 과정에서 특히 많은 도움이 됐다고 생각한다. 책의 양이 워낙에 방대하기도 하고 굉장히 디테일한 내용들이 많아 모두 기억하진 못하지만 리팩터링과 같은 책처럼 어느 정도 인덱싱이 가능한 책이라고 생각하고 필요한 내용을 꺼내쓸 때 굉장히 유용하다고도 생각한다.

 

아직 책린이지만 올해 기술 도서를 8권정도 읽으면서 인상 깊었던 점은 조영호님께서 여러 책에서 언급되시는 것이었다. (마치 현재 Spring 개발자들이 김영한님(혹은 백기선님 토비님 등등)으로 대동단결되는 모습 떠올라서 책 말머리부터 웃으면서 들어갔던 기억이 있다.)

 

이 이야기를 하는 이유는 이미 많은 분들이 조영호님의 책을 읽었기 때문에 조영호님의 책들을 읽고 그 책에서 하는 이야기가 무엇인지 이해하고 있다면 분명 나중에 다른 개발자들과 커뮤니케이션하는데에도 도움될 것이라고 생각해서 오브젝트(혹은 객체지향의 사실과 오해)는 꼭 읽어 봐야겠다는 생각을 했다.

 

또한, 오브젝트의 내용도 역할, 책임, 협력이라는 개념으로부터 실제 구현 방식인 타입과 메소드, 데이터 그리고 그들 간의 상속과 합성을 통한 전체적인 객체지향 프로그래밍 방법에 대해 차근차근 알아볼 수 있어 굉장히 좋았다.

 

책의 내용은 일반적인 개념부터 시작해 조금씩 디테일한 내용을 추가하는 방식으로 흘러가고 나는 개인적으로 비슷한 내용이 조금 반복되는 느낌이 있었지만, 매번 잊어서 책의 내용을 뒷받침하는 예제 코드가 함께 제공돼서 읽기 편했다. 책을 읽으면서는 이렇게 완벽한 요구사항이 있다는 것이 실제 프로그래밍과 괴리가 있을 수 있겠다는 생각은 하지만, 개념의 파편들을 실제 코드에 적용했던 경험들이 있기에 더 투덜대지 않고 책을 읽어 나갔다.

 

---

짧은 정리

역할 책임 협력 (역할은 책임의 집합으로 표현되기 때문에 여기서는 편리하게 역할로 합쳐서 말하겠다)

이 세가지는 자주 나오는 단어이기도 하고 객체지향 프로그래밍의 대부분이 객체의 역할을 어떻게 잘 설계하고 객체 간 협력을 어떻게 긴밀하게 수행할지에 대해 고민하는 것으로부터 시작한다고 생각한다.

다만, 책에서도 언급했듯 객체란 실세계의 모방이라는 관점보다는 어떤 역할을 수행하는지에 초점을 맞춰서 바라본다는 사실이 굉장히 잘 와닿았다.(실세계의 사물들은 보통 하나의 역할로 분류되기 힘들다. 따라서 실세계의 사물로 객체를 설계하면 의도대로 흘러가지 않을 수 있다.)

 

낮은 결합도 높은 응집도

높은 응집도는 역할과 관련된 데이터가 얼마나 가까이(실제 물리적인 위치 혹은 논리적인 그룹의 위치) 있느냐를 이야기 한다고 생각한다. 이는 단일 클래스의 캡슐화와도 관련이 있는데 객체를 역할을 수행하는 단위로 본다면 어떤 역할을 수행하기 위해 필요한 데이터는 그 객체 내부에 위치해야 응집도가 높다는 것이고 이를 외부로 드러내지 않는 것은 곧 캡슐화와 관련이 있기 때문이다.

 

낮은 결합도는 객체 간 긴밀한 협력을 위해서 사용되는 개념인데 그 핵심은 한 클래스가 많은 지식을 알고 있지 않도록 함에 있다고 생각한다. 왜냐하면, 많은 지식을 알고 있다는 것은 지식의 변경에 굉장히 취약하다는 것을 의미하고 쉽게 이야기하면 요구사항의 변경의 영향이 코드 전체로 퍼져나갈 수 있다는 것을 의미하기 때문이다.

 

다형성

객체지향 프로그래밍 언어, 그 중에서도 타입을 지원하는 언어에서 구현한 가장 특이한(?) 매커니즘이라고 생각한다.

다형성과 동적 바인딩에 대해 조금씩 알아가면서 인터페이스를 작성하고 클래스 간 결합을 설계하는데 자신감을 얻었던 것 같다. 어쩌면 자바 컴파일 타임과 런타임에서의 동작 방식 차이에 대해서 감을 잡는데도 도움이 됐다고 생각한다. (실제로 책에서는 컴파일 의존성과 런타임 의존성을 구분해서 설명한다)

 

외에도 책에서는 DIP, 상속과 관련된 내용(코드 재사용 관점의 상속의 단점, 타입 구현을 위한 상속), 디자인 패턴에 대한 이야기 등등 정말 많은 내용을 담고 있다.

---

마무리

정답은 역시 없다

객체지향 프로그래밍은 어떤 특정한 언어의 전유물이 아니다. 상속하면 자바가 생각나는 것이 현실이지만 실제로 프로토타입 기반의 언어에서도 상속을 구현할 수 있고 얼마든지 객체지향 프로그래밍이 (일부분)가능하다는 것이다. 이는 곧 시스템을 구현하기 위해 객체지향 프로그래밍을 100% 적용하는 것이 항상 정답이 아니라는 것을 의미한다. 그럼에도 프로젝트의 현재 상황에 맞추어 가장 적절한 방법을 택하기 위해서는 팀원들이 공유(공감) 가능한 설계 방식을 채택할 수 있어야 하기 때문에 객체지향 프로그래밍은 그 관점에서 효율적인 설계 기준이 될 수 있다고 생각한다.

 

최근에 프로젝트를 진행하면서 생각한 것

1. 그라운드 룰과 팀 컨벤션이 중요하다고 생각한다. 내가 최근에 참여한 팀에서 비교적 수월하게 새로운 프로젝트의 구조를 파악할 수 있었던 이유도 기존 히스토리를 문서로 정리한 것과 일반적으로 통용되는 의존 관계를 팀 내에서도 적극적으로 사용하고 있었기 때문이라고 생각한다. 그러면서도 내가 생각하는 의존 방향과 상이한 부분이 있기도 했는데 장단점을 비교해 보니 기존의 방식 또한 굉장히 합리적으로 느껴져 그 방식 그대로 따르기로 결정했다. 이렇게 (설명 가능한)팀 컨벤션이 존재하면 새로 들어온 팀원에게 프로젝트 전체에 대한 이해도를 높이는데도 도움되고 코드 또한 자신감있게 작성할 수 있겠다고 생각했다.

 

2. 컴파일 타임(혹은 빌드 타임)에 개발자의 실수를 집어내는 방법 중 프로젝트를 분리하고 프로젝트 간 의존성을 명시하는 방법이 굉장히 효과적이라고 생각했다. 이를 통해 잘못된 의존 관계를 프로젝트가 감지하고 경고문을 띄워주기 때문에 개발자의 실수를 방지할 수 있다. (물론 관리 범위가 확대되는건 단점으로 볼 수 있다. 소규모 프로젝트에 적용하는 건 고민해 봐야한다고 생각한다)