[책] 객체지향의 사실과 오해 리뷰

 

Review

많은 사람들이 추천하는 책에는 이유가 있는것같다. 왜 이제야 읽었지? 후회될 정도로 좋은 책이었다. 단순히 클래스를 사용한다고 객체지향이 아니라는 걸 깨닫게 해준 책이다.

 

내가 배운 첫 프로그래밍 언어는 C였는데, 그래서 C++을 배울때 굉장히 혼란스러웠다. C언어에도 구조체라는 게 있었기 때문이다. 클래스랑 구조체랑 똑같은 거 아니야? 라는 생각으로 객체지향을 시작하다 보니 자연스레 데이터를 먼저 생각하고, 데이터를 기반으로 메서드를 결정하고 잘못된 설계를 하고 있었던 것 같다.

 

좋은 점은 역시 찰떡같은 비유로 객체지향을 설명해 준다는 점이었다. 커피숍 예제부터, 이상한 나라의 앨리스를 이용한 비유, 그리고 이자 계산 예제까지. 헷갈리기 쉬운 부분을 짚어주면서 진짜 객체지향이란 무엇인가 설명해준다. 내용 외적인 부분에서는 사람들이 왜 번역판 말고 굳이 원판을 찾아보는지 이해하게 되었다. 이전에 읽었던 책(클린 코드)은 영어를 한국어로 옮겨만 놓은 수준이라 이해하기 너무 힘들었는데 이 책을 읽고 다시 보니까 클린 코드에서 했던 말들이 이해가 너무 잘 된다😭 (지난번에 디미터 법칙이 이해가 안된다고 했는데, 이 책에서 설명해주니까 갑자기 이해가 되기 시작했다💦)

 

이 책을 읽으면서 가장 기억에 남는 단어는 ‘협력’이었는데, 결국 객체는 전체의 한 부분으로써 동작해야 하기 때문이다. 그리고 객체지향이 진짜 현실세계를 반영한 게 맞다는 생각도 들었다. 나 자신도 팀의 일부로써 행동해야 하기 때문이다. 객체의 책임은 명확히 하되 자율성을 보장해야 한다는 건 팀 프로젝트에도 적용되는 말이다. 지난 날의 나는 팀원에게 지나치게 간섭하지는 않았는지, 책임을 명확히 했는지 등등 많은 생각을 하게 해주었다.

 

중간중간 몇몇 부분에서 인프런 김영한님의 스프링 기본 강의가 많이 떠올랐다. 그 때 김영한님께서 하셨던 그 말이 이런 의미였다는 걸 깨달을 수 있었고, 책을 전부 읽고 나니 스프링 강의를 진짜 완강했다는 기분이 들었다. 조금 더 빨리 읽었으면 훨씬 좋았을텐데 싶어 아쉬웠던 책🥲

 

---

Highlights

객체는 다른 객체가 무엇(what)을 수행하는지는 알 수 있지만, 어떻게(how) 수행하는지는 알 수 없다.

자율적인 객체를 만드려면 왜 캡슐화가 필요한지 설명해주는 문장이라고 생각한다. 나는 그동안 내부 상태에 접근할 수 없으면 캡슐화라고 생각했는데 이 문장을 읽고 내부 구현이 인터페이스에 드러나지 않는 것까지가 캡슐화라는 것을 깨달았다.

 

클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라.

객체지향에서 클래스는 정말 중요한 개념이다. 하지만 클래스는 수단일 뿐이고 목적은 역할, 책임, 협력이다. 객체지향의 본질은 객체 간의 협력을 통해 목표 기능을 제공하는 것이기 때문이다. 어떤 클래스가 필요할지에 앞서, 어떤 협력이 필요한지를 생각해보자.

 

객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.

객체가 갖고있는 데이터가 아니라 객체가 외부에 제공하는 메서드에 집중하라는 의미다. 지금까지 나는 객체의 상태를 먼저 결정하고, 상태를 기반으로 행동을 결정했기 때문에 내가 잘못된 설계를 하고 있었다는걸 깨닫게 해 준 문장이기도 하다.

 

현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다.

흔히 객체지향을 현실세계를 반영한 패러다임이라고 하기 때문에 착각하기 쉬운 부분인 것 같다. 물론 나도 착각하고 있었다.

현실 세계의 사물은 에이전트가 필요하지만, 객체지향 세계의 자기 스스로 행동을 수행한다. 컴퓨터로 치면, 누군가가 전원을 켜라고 명령하지 않아도 스스로 전원을 켤 수 있는 것이다.

 

추상화의 목적은 불필요한 부분을 무시함으로써 현실에 존재하는 복잡성을 극복하는 것이다.

이 부분에서 지하철 노선도를 예시로 들어주셨는데 완벽에 가까운 비유였다. 종종 서울 지하철 노선도를 보면서 환승역 잇는데만 집중하고 한강은 정말 대충 그려놨다고 생각했는데… 사실 한강이 일직선인지 ㄹ자인지 노선도 보는 사람들은 상관없지않나😂 필요없는 부분을 쳐내고 필요한 부분만 남겨놓으면 목적에 집중하게 된다는 장점이 있을것같다.

 

객체를 분류하는 기준은 타입이며, 타입을 나누는 기준은 객체가 수행하는 행동이다.

행동을 먼저 정의해야 하는 이유라고 생각한다. 같은 행동을 수행할 수 있으면 같은 타입이고, 같은 타입의 객체들끼리는 서로를 대체할 수 있기 때문이다.

김영한님의 스프링 강의에서 들었던 로미오와 줄리엣 이야기가 떠올랐다. 대사를 외우고 연기만 할 수 있으면 누구나 로미오 역을 맡을 수 있다. 그게 디카프리오던 송강호던.

 

어떤 협력에 참여하는지가 객체에 필요한 행동을 결정하고, 필요한 행동이 객체의 상태를 결정한다.

이 부분을 읽으면서 옛날에 우Eㅔ코 프리코스 미션에서 숫자 야구 게임을 구현할 때가 생각났다.

 

나는 절차적 방식으로 코드를 짜고 있었는데, 부트캠프 동기에게 도움을 청하니 게임을 구현할 때는 보통 객체 단위로 설계를 한다고 팁을 알려줬던 적이 있었다. 먼저 사용자가 플레이할 캐릭터가 필요하고, 캐릭터가 있으면 전진, 공격 등의 메서드가 필요하고, 공격을 하려면 무기가 필요하니까 무기를 추가하는 방식이라고 했는데 그게 이 말이었다는걸 이제야 깨달은 것 같다. 필요한 행동을 먼저 결정하면 객체의 메서드가 먼저 정의되고, 거기에 필요한 상태들은 메서드를 구현하면서 자연스레 따라온다.

 

객체지향의 핵심은 클래스를 어떻게 구현할 것인가가 아니라, 객체가 협력 안에서 어떤 책임과 역할을 수행할 것인지 결정하는 것이다.

객체지향은 클래스가 아니라 협력에서 시작한다. 따라서 좋은 객체는 좋은 협력자여야 한다.

개인적으로 현실과도 비슷한 부분이 있다고 생각했다. 여러 번의 팀 프로젝트를 진행했지만 결국 중요한 것은 무슨 기술을 쓸 줄 아는지보다 우리 팀에서 어떤 역할을 수행하는지, 어떻게 협력하는지였기 때문에😂 객체들도 거대한 팀플을 수행하는 팀원이라고 생각하면 이해가 좀 더 쉬울것같다.

 

어떤 객체가 필요한지보다 어떤 메시지가 필요한지를 먼저 결정해야 한다.

이 부분도 팀원을 뽑을 때와 매우 유사하다고 느꼈다. 이 사람을 뽑겠다고 결정하고서 자리를 마련하는게 아니라, 이러이러한 역할을 수행해줄 사람이 필요하다고 자리를 마련한 뒤 그 자리에 적합한 사람을 뽑아야한다. 그래야 조직에 적절한 팀원이 뽑힌다.

필요한 메시지를 먼저 결정하라는 건 자리를 먼저 마련하라는 의미 아닐까?

 

객체가 어떤 메시지를 수신할 수 있는지가 객체의 인터페이스 모양을 결정한다.

객체가 어떤 메시지를 수신할 수 있는지는 객체의 퍼블릭 메서드가 되고, 퍼블릭 메서드가 모여 인터페이스가 된다. 나는 반대로 인터페이스에 수신할 수 있는 메시지와 관련없는 부분을 끼워넣지 말라는 의미로도 이해했다.

 

좋은 설계는 변경을 예측하기보단 나중에 변경할 수 있는 여지를 남겨 놓는 설계이다.

보자마자 지난 프로젝트의 기억들이 주마등처럼 스쳐지나가는 구절이었다😂 우리 프로젝트 이렇게 확장 가능하니까 요런 설계로 갈까요? 라고 말하던 지난 날을 반성했다. 어쩔 때는 변경할 가능성이 없다며 다대다 연관관계를 중간 엔티티 생성 대신 @ManyToMany로 구현한 적도 있었다. 물론 프로젝트가 끝나면서 진짜로 변경하는 일은 일어나지 않았지만…

 

우리 팀의 회의가 끝나지 않았던것도 ‘이렇게 변경되면 어떡해요?’ ‘저렇게 변경되면 어떡해요?’ 라고 끝없는 질문을 던졌기 때문이었음을 깨달았다. 이렇게도 변경 가능하고 저렇게도 변경 가능한 설계가 존재할까? 있어도 그걸 생각하기까지 너무 오래 걸릴 것 같다? 그렇다면 고민하기보다는 그 때 가서 인터페이스 분리하고 확장 가능한 설계로 만들면 되지 않을까?

 

안정적인 객체 구조를 바탕으로 설계하면, 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

도메인 모델을 바탕으로 설계해야 하는 이유를 말해주는 문장이다. 지금까지 도메인 모델이랑 클래스 모델이랑 같은 거라고 생각했는데, 복리-단리 이자 예제를 보고 둘이 다르다는 걸 깨달을 수 있었다.

도메인 모델이 클래스 모델에 비해 추상적이고, 사용자 관점을 더 많이 반영한 느낌? 사용자 모델에 포함된 개념과 규칙은 기능에 비해 변경 확률이 낮기 때문에, 사용자 관점을 반영한 도메인 모델을 바탕으로 설계하면 기능이 변경되더라도 구조는 크게 변경되지 않는다.

 

구현은 인터페이스 안에 캡슐화되어야 하며, 인터페이스와 구현은 명확하게 분리되어야 한다.

구현은 불안정하지만 명세는 안정적이기 때문이다. 구현은 언제든지 바뀔 수 있지만 명세는 상대적으로 변경 가능성이 낮다.

이걸 잘못 이해하면 예전의 나처럼 구현이 메서드명에 그대로 드러나는 코드를 짜게 된다😂 메서드명은 클라이언트 입장에서 결정하자🥹