객체지향의 사실과 오해 - 조영호

https://product.kyobobook.co.kr/detail/S000001628109

객체지향의 사실과 오해 | 조영호 - 교보문고

객체지향의 사실과 오해 (역할, 책임, 협력 관점에서 본 객체지향) 책을 완독했습니다.

 

이 책은 5월 11일부터 출퇴근길에 읽기 시작했고, 오늘 6월 12일에 마지막장을 읽었습니다.

 

엘리스 부트캠프를 하며 친해지게 된 코치님께서 오브젝트 책과 함께 선물을 해주셨습니다.

오브젝트 책의 존재는 알고 있었는데, 객체지향의 사실과 오해 부터 읽으면 된다고 하시더라구요.

오브젝트 책은 조금 두꺼워서 텀을 가지고 천천히 읽어보려고 합니다.

https://product.kyobobook.co.kr/detail/S000001766367

오브젝트 | 조영호 - 교보문고

 

객체지향의 사실과 오해 책은 OOP가 무엇인지 감을 가지게 해주는 책이라고 생각합니다.

이 책의 내용은 오브젝트를 읽기 전에 알고 있어야 하는 OOP에 관한 배경지식으로, 오브젝트에 포함될 예정이었지만 내용이 너무 많아져 따로 출판이 되었다고 합니다.

 

최근 2~3달 동안 OOP에 관심이 많았습니다.

이유는 크게 두 가지인데, 첫 번째로는 회사에서 NestJS 를 사용하기 때문이고, 두 번째는 개발바닥 유튜브를 보아서 입니다.

 

NestJS는 OOP와 Singleton, Typescript 등이 기본적으로 설정되어있는 Node.js 프레임워크이며, 스프링의 간단한 모습을 하고 있습니다.

 

회사에서 현재 NestJS로 Hexagonal Architecture를 적용하여 각 layer가 가진 역할과 책임을 최대한 분리하면서 개발하려고 노력중이고, 이미 Express.js도 Singleton을 적용하여 사용하고 있기 때문에 OOP에 대한 이해도가 높아야 더 개발을 잘 할 수 있겠다는 생각이 들었습니다. Javascript는 태생이 객체지향이 아니고, Node.js도 OOP를 강제하지 않기때문에 처음에는 OOP가 굉장히 낯설었습니다. 하지만 공부를 할수록 왜 사용하는지 감이 조금씩 오고 있습니다.

 

개발바닥 유튜브를 운영하시는 인프런 CTO 이동욱(향로)님과 반려생활 CTO 이주현(호돌맨)님은 우아한형제들에서 Java로 개발을 하셨기때문에 OOP의 중요성을 매우 강조하시는 것을 알 수 있었습니다. 또한, https://www.youtube.com/watch?v=OMvxHl5f8zI  이 영상에서 요즘 Node.js 가르치는 부트캠프에서 OOP 같은 반드시 알아야하는 개념들을 가르치지 않는다는 내용이 나왔는데, 제가 수료한 엘리스의 커리큘럼에서도 OOP는 없어서 제가 괜히 찔렸고, 꼭 공부를 해야겠다는 생각이 들었습니다.

 

마침, 책도 선물 받았겠다 신나서 출퇴근길에 거의 매일 책을 읽었습니다.

하루에 30~40분 서서 책읽겠다고 가방까지 들고다니려니 진짜 번거롭고 귀찮았지만, 책 내용이 재미있기도하고 눈이 뜨이는 기분이 들어 후회는 없습니다. 오히려 오브젝트 책 읽을때도 똑같이 할거같습니다.

 

이 책은 직접 읽어봐야된다고 생각을 해서 중요한 내용 몇가지만 정리하겠습니다.

 

1. 객체지향에서 객체는 Class를 지칭하는것이 아니다.

2. 객체에서 중요한것은 상태가 아니라 행동이다.

3. 객체지향은 협력이 가장 중요하다.

4. 객체지향은 현실세계를 모방한 것이라는 설명이 많은데, 이것은 틀린얘기이다. 현실 세계를 은유하여 새로운 세계를 창조한것이다. 다만, 현실세계를 모방한것이라는 설명은 객체지향을 이해하는데에 도움을 준다.

 

아래는 가장 앞 부분에 나오는 문장들입니다.

 

객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다.

 

실세계의 모방이라는 객체지향의 개념은 훌륭한 프로그램을 설계하고 구현하는 실무적인 관점에서는 부적합하지만 객체지향이라는 용어에 담긴 기본 사상을 이해하고 학습하는 데는 매우 효과적이다.

 

객체지향 설계라는 예술은 적절한 객체에서 적절한 책임을 할당하는 것에서 시작된다.

 

클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라. 객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.

 

뒤로 갈수록 더 자세한 설명이 나옵니다.

가장 인상깊었던 것중에 하나는, 옛날에 지하철 노선도를 '정확성'에 집중해서 사실적인 지형에 근거하여 만들었다가 보기힘들어서 요즘처럼 '목적'에 집중해서 지형, 위치, 거리 등을 모두 무시한 지하철 노선도를 사용하고 있다는 것입니다. 지하철 이용자에게 필요한것은 역의 정확한 위치가 아니라 역과 역을 연결하여 갈아타는 것만 신경써서 몰라도 되는 정보는 죄다 무시해버림으로써 지하철 노선을 추상화 한것입니다.

 

작년 9월경, 다른 면접에서 typescript의 인터페이스가 OOP의 어떤 특성인지 질문을 받았었습니다. 그때는 OOP가 뭔지도 제대로 몰랐기때문에, 모른다고 대답할 수 밖에 없었습니다. 제가 포트폴리오에 typescript 인터페이스를 사용했다고 써놨지만, 저는 타입을 지정하기 위한 목적으로만 사용했었기 때문입니다. 하지만 개발을 하면 할수록 인터페이스는 코드를 단순화할 수 있고, 코드 재사용성과 유지보수성을 높이는 것을 몸소 느꼈습니다. 책에서는 다음과 같이 정의하고 있습니다.

 

어떤 양상, 세부 사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다.

객체지향 패러다임은 객체라는 추상화를 통해 현실의 복잡성을 극복한다.

 

예전에 부트캠프를 막 수료했을 때, 네이버 부스트캠프를 진행하던 친한 동생이 어느날 이런 말을 했습니다.

"여기 카카오출신 강사님이 데이터 먼저 설계하면 안좋을수도 있대"

무슨말인지 모르겠어서 캡처해서 보여달라고 했는데, 그 당시에는 전혀 이해가 안됐었습니다.

요약하면 다음과 같습니다.

데이터를 먼저 설계하고 기능을 작성하면 데이터 위주로 기능을 만들어낼 확률이 높기때문에 객체의 협력을 이끌어내기 어려울 수 있어서 결론적으로 객체 지향 설계와는 조금 멀어질 수 있다.

 

아무리봐도 이해가 안되서 엘리스에 계셨던 카카오 코치님께도 여쭤봤는데, 절대적인건 아니고 상황에 따라 다르다고 말씀해주셨습니다.

 

이해가 더 안되서 묻어뒀다가, 지금 이 글을 작성하면서 어떤 내용인지 다시 찾아봤는데, 이제야 두 코치님들이 어떤 의도로 말씀하셨던 건지 이해가 됩니다.

부트캠프를 하면서는, 도메인도, OOP 개념도, 책임과 역할도, OOP과 관련된 그 어떤것도 배우지 않아 제가 무엇을 모르는지도 모르는 상태였습니다. 물론 배우지 않았다고 해서 모르는것은 자랑이 아닙니다. 지금 생각하면 너무 창피합니다. 이렇게 다시 창피한 기분을 느끼고 싶지 않아서라도 공부를 열심히 해야겠습니다.