책 소개
우형에서 개발 실장으로 일하셨고 현재 카카오에서 일하시는 조영호님이 쓰신 책이다. yes24 책소개에 “객체지향이란 무엇인가라는 … 질문에 답하기 위해 쓰여진 책이다.” 라고 쓰여있다. 이 소개 한 줄이 책을 잘 표현해주는 것 같다. 목차가 궁금하다면 yes24 링크를 참고하자.
읽게된 계기
예전부터 소프트웨어 개발쪽에서 유명한 책이라는 건 알고 있었다. 미루고 미루다가 개발자 지인도 추천하고 스프링 스승님이신 영한님의 추천도 있었기 때문에 읽게 됐다. (스프링 강의는 인프런 영한님 강의…)
그리고 실무를 해보니 더 좋은 소프트 웨어 개발을 하기 위해서는 기술 이외에도 근본이 되는 내용들을 아는 것도 매우 중요하다고 생각했다. 그래서 더 늦기 전에 읽게 됐다.
인상 깊은 내용
객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
p35 객체 지향의 본질
가장 핵심적인 키워드인 협력, 역할, 책임이 다 나오는 문장이다. 이후 내용에서 어떻게 적절한 역할을 잘 수행하며 협력하는지가 나온다. 사실 책을 읽기 전까지 객체는 ‘현실 세계의반영’, ‘클래스의 구현’ 정도였다. 정말 중요한 사실인 협력은 잘 생각하지 못했다. 어떤 객체도 홀로 고립된 채 존재하지 않는다고 나온다.
이때 제대로된 협력이 이루어지려면 역할, 즉 책임을 잘 분배해야된다고 나온다. 한 객체가 너무 많은 역할을 해서는 안 된다. 유명한 설계 원칙인 “단일 책임 원칙”도 결국 객체가 서로 협력하는 존재이기 때문에 그런게 아닐까 생각했다. 종종 이것도 하고 저것도 하는 만능(?) 객체를 만들 때가 있다. 앞으로는 객체를 설계할 때, 객체에게 적절한 책임과 역할이 부여된 것인지 생각해봐야겠다.
객체의 행동은 객체가 협력에 참여하는 유일한 방법이다. 따라서 객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.
p65 행동이 상태를 결정한다
제일 충격(?)을 받은 부분이다. 보통 내가 객체를 설계할 때, 이 객체가 어떤 데이터(상태)를 가져야하는지를 생각하고 어떤 행동을 할 지는 그에 맞춰서 생각하는 경향이 있었다. 좀 더 구체적으로 표현하자면 클래스의 멤버부터 작성하고 메서드는 이후에 작성하는 것이다. 책의 표현을 빌리자면 “객체지향에 갓 입문한 사람들이 가장 쉽게 빠지는 함정"이라고 한다.
나를 제외하고도 객체 지향 설계에 대해서 익숙하지 않은 사람들은 보통 이런 식으로 객체를 설계할 것 같다. 결국 객체의 퀄리티를 떨어뜨리는 부작용이 있기 때문에 지양해야한다고 책에서 설명하고 있다. 객체는 단순히 상태가 있는 대상이 아니라 행동으로 협력에 참여하는 대상이다.
역할을 이용하면 협력을 추상화함으로써 단순화할 수 있다. 구체적인 객체로 추상적인 역할을 대체해서 동일한 구조의 협력을 다양한 문맥에서 재사용할 수 있는 능력은 … 그리고 그 힘은 근본적으로 역할의 대체 가능성에서 비롯된다.
p126 협력의 추상화
꼭 객체 지향 설계가 아니더라도 재사용성은 개발에서 매우 중요한 요소이다. 재사용하지 못하는 코드는 운영에서 헬을 보여줄 것이다. 역할을 잘 추상화하면 그에 맞는 구체적인 객체로 갈아끼우면 그만이라고 한다. 실제로 객체 지향을 잘 활용하는 스프링을 사용하다 보면 발견할 수 있다. 특정 역할을 인터페이스 같은 것으로 지정하고 실제 내용은 구체적인 객체에서 구현한다. 그러면 그때그때 역할에 필요한 객체를 갖다쓰기만 하면 된다.
훌륭한 객체지향 설계는 어떤 객체가 어떤 메세지를 전송할 수 있는가와 어떤 객체가 어떤 메시지를 이해할 수 있는가를 중심으로 객체 사이의 협력 관계를 구성하는 것이다.
p156 객체지향의 핵심, 메시지
객체의 행동과 비슷하게 이전에 많이 생각하지 못한 부분이다. 특정 객체를 설계하다보면 그 객체에만 몰입하게 된다. 그래서 다른 객체에 어떤 메세지를 전송할 수 있고 전달받아야 하는지는 뒷전이 돼 버린다. 완성하고 나면 다른 객체와 제대로 협력하지 못해 다시 고쳐야한다. 객체의 메세지를 생각하면 이 객체가 다른 객체와 어떤 협력을 해야하는지를 생각해볼 수 있을 것 같다.
객체 설계의 핵심은 객체를 두 개의 분리된 요소로 분할해 설계하는 것이다. 그것은 바로 외부에 공개되는 인터페이스와 내부에 감춰지는 구현이다.
p169 인터페이스와 구현의 분리 원칙
이 부분은 경험을 통해 어느 정도는 알고 있었다. 내부 요소를 그대로 드러내버리면 나중에 바꿨을 때 어느 곳에서 갑자기 에러가 날지 짐작하지 못한다.또한 내부 한 곳을 바꿨어도 그걸 사용하는 여기저기를 다 바꿔야하는 불편함이 따를 수도 있다. 꼭 라이브러리 수준이 아니라 자신이 작성한 코드내에서도 충분히 이럴 수 있다. 재사용성과 비슷하게 운영 측면에서 굉장히 중요한 요소 같다.
아쉬운 점
책의 중반부까지 독자의 이해를 위해 실생활이나 엘리스 이야기를 통한 예시가 많이 나온다. (책 표지에 토끼가 있던 이유… ) 물론 이해가 더 쉽게 되지만 예시가 조금 길어져 예시 부분은 넘겨서 읽었던 적이 종종 있었다. 그래서 필요한 내용만 보고 싶은 사람들은 내용에 대한 이해가 됐다면 예시는 빨리빨리 넘겨서 보면 좋을 것 같다. 그 외에는 아쉬운 점이 없었다.
마무리
맨 처음에 말했듯이 소프트 웨어 개발을 할 때 많은 도움을 주는 책이라고 생각한다. 객체를 좀 더 넓은 시야에서 바라보고 잘못된 생각을 바로 잡아준다. 그리고 유지보수가 용이한 코드를 작성하기 위한 기반을 쌓을 수 있는 것 같다. 어떤 언어를 쓰든 소프트 웨어 개발을 한다면 한 번쯤은 꼭 읽어볼 책이라고 생각한다.
