내 생각을 말하자면 "객체지향적이든 아니든 중요하지 않다."이다
물론 동문서답 격인 대답이므로 답글을 달진 않았다. (요즘은 인터넷 공간에 엉뚱한 글을 답글로 쓴다는 것은 상당한 용기가 있어야 한다.)
우선 객체지향(OOP : Object-Oriented Programming)적인 언어라는 것이 무엇을 의미하는지 알아야 한다.
Class, Object, Method, Message 등으로 구성되어 Encapsulation, ,Abstraction, Polymorphism의 특성이 있는 언어라 할 수 있겠다. ( 위키피디아 에서 따왔는데, 한글 위키라 그런지 설명이 좀 부실하다. 10년 전인가 이 개념을 이해하고자 3-4권의 책을 반복으로 정독하고 10여 권을 책을 훑어 본 적이 있음을 기억할 때 그리 간단하게 규정하기는 어렵다고 본다. 이것은 범위가 넓은 거대한(?) 이론이기 때문이다. )
아무튼 대강 그런 뜻이라 여기고 넘어가도록 하자.
항상, 그 이론보다 중요한 것은 그 이론이 발생하고 발전하게 된 동기이다.
즉, 왜 이러한 이론이 필요한지, 무엇을 위한 이론인지가 중요하다.
누가 이론이 아니랄까 봐 어려운 말들로 잔뜩 설명이 되어 있는 일도 있지만,
간단히 이야기하면 원하는 기능의 코드를 빠르고 유지보수가 쉽도록, 추후의 작업에 재사용 가능하도록. 최초 설계 단계에서의 편리성과 보다 정확한 검증을 위해......
한마디로, 생산성의 향상을 위한 것이다.
이렇게 본다면, 어떠한 언어가 얼마나 OOP인가를 따지는 것보다는 어떠한 언어가 생산성이 있는가를 따지는 것이 더 의미가 있다고 본다. 비록 일반적 이론상의 OOP에 미치지 못하는 부분이 조금 있다손 치더라도 그걸로 인해 생산성이 더 향상된다면 굳이 이론상의 OOP를 억지로 구겨 넣어야 할 필요가 없다.
물론 여기서 말하는 생산성은 단순히 빠른 작업 속도만이 아닌 편리성, 안정성을 추가한 개념이다. 뭐 사실 그것이 빠른 작업 속도에 영향을 끼치긴 마찬가지이지만.....
예를 들면, 폼 기반의 애플리케이션 구조를 가진 델파이의 VCL은 객체지향적이라고 하기엔 부족한 면이 있지만, 이는 매우 편리한 UI 제작을 위한 DESIGN 개념을 위한 것이고 그만큼의 충분한 생산성을 향상시켰기 때문에 객체지향적이지 못하다는 것이 큰 문제가 되지 않는다는 것이다. 같은 이유로 모호한 다중상속을 좋아하지 않는다.
또 한가지,
객체지향이라는 것은 방법이나 구조에 대한 이론이기에 그 언어가 크게 중요하지 않다.
즉 어느 정도 객체지향적으로 프로그래밍할 수 있는 언어라면 OOP 이론을 적용하여 프로그래밍하는 것 자체가 중요하지 언어가 중요한 것이 아니다.
실제로 class만 있을 뿐이지 C++ 인지 C 인지 구별이 안 되는 코드는 사방에 널려 있다.
델파이의 예로 들면 VCL의 폼 기반 애플리케이션 설계는 객체지향적이라 보기 미흡하지만 독립된 몇 가지의 클래스로 데이터를 관리하고 폼은 단지 보여주기만 할 뿐...... 의 방식으로 코딩한다면 매우 훌륭한 객체지향적 프로그래밍을 할 수 있다.
요약하면... (구세대 교육을 받은 결과 인지, 요약을 하지 않으면 끝맺음이 뭔가 부실한 느낌이다. -_-; )
- OOP를 따르는 것보다 OOP의 목적을 성취하는 것이 더 중요하다.
- 이를 위해서는 사용하는 언어가 얼마나 객체지향적인가 보다는 개발자가 얼마나 객체지향적으로 프로그래밍할 수 있는가가 중요하다.
