OOP! Oops

간만에 DevX를 보고 있노라니 몇 사람이 OOP에 대한 논의로 발끈하고 있는 것이 눈에 보이길래..

OOP Is Much Better in Theory Than in Practice
Riled Readers Respond to Restive OOP Rejection
OOP Is Best in Practice

OOP에 대해 간단한 수준의 설명자료로 아래의 링크도 건다.
Introduction to Object-Oriented Programming Using C++

본인의 경우 C++을 처음 배울때, 그리고 OOP라는 용어를 듣기 시작하고 재사용성이니 캡슐속에 꽁꽁 숨어라 등등을 배우면서 신세계를 보는 듯 하였다. 이전의 Procedure-Oriented에서 객체라는 이야기를 하고 그 객체간의 관계를 이야기 하는 시점에서는 거의 광신도가 되어 버렸다. 하지만 OOP가 재사용성을 회기적으로 증가시켜주기 힘들다라는 의견들이나 실제로 몇가지 프로젝트를 하면서 OOP에 대한 환상은 깨져 버렸다고도 할 수 있다.

OOP는 상당히 훌륭한 컨셉임에는 틀림없다. 하지만 그것을 제대로 이해하고 또한 디자인에 실제 적용시키는 데는 상당한 지식과 경험이 요구되고 또한 그렇다고 항상 효율적인 상황으로 유도되는 것도 아니다. 우선 개발자 모두가 OOP에 상당히 익숙하지 못하면 그 프로젝트는 OOP의 가면을 쓴 스파게티가 되어버릴 가능성이 높고 재사용성이니 정보숨기기에 광적으로 집착하다 보면 결국 아무도 쓰지 못하는 쓰레기 코드만 양산되는 경우도 허다하다. 단순히 상속만 하면 그것이 OOP다라고 생각했다가는 무늬만 흉내낼 뿐이 되는 것이다. 다형성(Polymorphism)이라는 필수 양념이 빠져서는 상속은 왜했냐라는 지적을 받을 수도 있다.

누군가 나에게 너는 얼마냐 OOP를 잘하냐라고 묻는다면 학부시절에 조금 봤었고 책 몇권 본게 전부다라고 할 수 밖에 없다. 하지만.. 일전에 술집에서 술을 마시다가 옆테이블에서 OOP의 환상에 대해 이야기하는 사람과 어떻하게 되어 통신상으로 한두마디 나누기 까지 했지만 그사람에게처럼 생각만큼 좋지도 않다라는 이야기는 해 줄수 있을 것이다. 책에서처럼 고양이가 "냐옹"하고 울고 개가 "멍멍"하는 OOP에 아주 적당한 케이스는 매우 드물고 현실에서는 자칫 잘못하면 고양이가 개와 Fxxxing하는 골때리는 상황이 일반적이다는 것이다. 프로젝트를 진행함에 있어 양념으로 OOP도 약간 섞는 것은 모르겠지만 메인 디쉬가 되려면 그전에 OOP를 전공으로 박사학위를 따고 몇년쯤 OOP로만 프로젝트를 진행을 해봐야 한다라고 충고 하고 싶다.

더불어.. 가장 하고 싶은말은, 현재 관리자인 나의 입장에서 OOP에 대해 충분히 익숙하지 않은 사람들에게 억지로 OOP가 좋으니 반드시 써라라고 하는 것 보다는 그냥 평소 하시는 데로 하세요라고 하는 것이 더 저비용에 안정적인 제품이 나올 가능성을 높을 것이라는 것.