[[번역] OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다]
위 링크의 글을 읽었습니다. 현실에서 OOP(Object Oriented Programming)가 제대로 이해되지 못한 채 오용, 남용되는 상황에 대해 과격하게 이야기 한 것 같다는 생각이 듭니다.
제가 봤을때 이 분은 너무 기술적인 측면(성능)에 집중하여 의견을 내신 것 같습니다.
프로그램의 규모와 특성에 따라 그것을 안전하게 개발 및 관리할 수 있는 설계 방법론을 선택하여 개발하면 되는 문제를 “OOP는 어떤 프로그램을 짜든 간에 해롭다”고 주장하였고 그것의 근거로 제시한 것은
- 소규모 프로그램을 (거의)완전한 수준의 객체지향 설계로 짠 코드 예시
- 많은 참조와 인자로 인한 퍼포먼스 하락
- 객체지향 설계의 특징들을 “복잡하다”는 말로 일축한 것
이네요.
복잡하고 퍼포먼스가 떨어진다는 근거로 OOP를 깎아내리려면 Python, Java, C#을 지양하고 C를 써야 하겠고 Visual Studio, Intellij 대신 vim이나 emacs를 사용해야겠죠.
이에 대해 번역글 마지막에 소개된 트윗에서 아샬님이 대안으로 언급하신 DDD는 OOP보다 더 어려운 방법론인데 이것도 복잡하니까 쓰면 안되나? 그건 아니죠.
프로그램의 크기가 클 수록 그것의 구조를 사람의 입장에서 쉽게 이해하고 관리할 수 있어야 하는데 수많은 소프트웨어 설계 방법론 중에서 그나마 학부생 수준도 이해하기 쉽고 적용가능한 규모와 시점의 장벽도 낮은게 객체지향 설계여서 대부분의 대학에서 이를 가르치는게 아닌가 싶습니다. 물론 이 방법론을 잘 이해하지 못하고 사용하여 잘못된 사례를 남기는 경우도 적지 않지만요.
정말 객체지향 설계가 실패한 방법론이라면 왜 아직도 이에 기반하여 서비스되고 유지되는 중대형 프로그램들이 많은지 생각해봐야 할 것 같습니다. 적어도 저는 객체지향에 기반해 프로그램을 짜면 보편적으로 실수와 에러에 대해 안전하고 이해하기 깔끔하게 짤 수 있다고 생각합니다.
결론은 OOP든 DDD든 뭐든 취사선택의 문제고 본인의 선택에서 문제가 생기면 방법론을 제대로 이해하지 못하고 적용했거나 다른 알맞은 방법론이 있다는 것입니다.
현실은 학부출신이 특정 프로젝트에 적합한 설계 방법론을 택하고 바닥에서 시작하여 끝까지 완성할 수 있는 경우는 흔하지 않을겁니다. 본인이 회사를 차리거나 박사출신 쯤 되어서 회사의 프로젝트를 직접 주도할 수 있는 정도가 아니라면 말이죠.