객체,상속에 대한 의문점..
본문
처음에 자게에 올렸는데, 여기에 올리면 어느 분에게는 도움도 될것 같아 여기에 올립니다.
처음 글은 이겁니다.
https://sir.kr/cm_free/1622557
제가 객체니 상속에 대해 이렇게 의문이 많은 이유가 있습니다.
정식으로 교육을 받지 못하고 그냥 우선 "당장 필요한거 작동하게..."로 20년 이상을 산 경험으로 볼때
"객체,상속의 기본 바닥이 뭘까?" 가 궁금했습니다.
가장 큰 교훈이 20년 전쯤 통신판매회사의 ERP를 책임졌었습니다.
당시 가장 큰 고민은 64K 도스 메모리 가지고(도스때 64K가 맞던가?) 400만명의 고객을 관리해야 했는데 일주일 마다 리셋을 거듭했습니다.
결국 실력의 한계를 느껴서 모 대학에 개발 의뢰를 했습니다. (회사가 커진 만큼 예산도 왕창써서)
전산과 교수와 계약을 맺고 대학원생이 팀장이 되서 예정일을 훌쩍 넘겨 베타가 나왔는데...ㅠ
처음 의뢰할 때는 문제 다 해결해 준다더니..나중에는 뭐가 하드웨어가 어떻다고, 뭐가 어떻다고... 하면서
현장에서는 쓰지도 못할 프로그램 주면서 이게 결과다 라고 하네요.
말하는데로 하면 되는 줄 알고 서버를 무려 4억 짜리까지 가져다 놓았지만 실무에 적용 불가능.
결국 4억짜리 서버로 도스 프로그램 돌리다 결국 부도로 끝이 났네요.ㅋ
그때 도입한 기술이 객체,상속 같은 개념인지 까지는 모릅니다.
당시 전산 용어 조차 제대로 알고 있는게 없었으니까요.
그런데 그 이후로도 몇 번 신기술이라는 환상에 속아 실전에서 낭패를 몇 번이나 보았습니다.
제가 객체지향 프로그램을 싫어하게 된 결정적인 이유는 똑같은 프로그램을 두가지 버전(객체 vs 절차식)으로 만들어 볼 기회가 있었는데,
(당시 잘 몰라 객체식은 표준 메뉴얼에 있는 것만 사용했습니다.)
그런데 웬걸 절차식이 메모리는 객체식의 1/2 도 사용 안하고 속도는 2배가 넘더군요... 엥??
왜 그럴까? 객체식이 훨씬 최신기술인데...
고민했는데 제 가설은 이렇습니다.
객체식도 결국 컴파일 단계에서는 절차식 코드이다...
절차식이 귀찮기는 해도 중복되지 않게 잘 만들면 훨씬 더 효율적이다.
이 가설이 맞을까요?
결국 객체프로그램은 원래의 기본 언어(즉, 절차식)를 이론(객체지향)에 맞추기 위해 포장을 바꾼 것 아닐까??
그런데 컴파일 단계에서는 결국 가장 기본적인 원천 명령어와 로직으로 컴파일이 되는 것이다.
예를들어 c++ 이 결국 c 를 기반으로 만든 라이브러리를 새로운 언어라는 이름으로 포장한것 아닌가? 하는 생각입니다.
뭐 그래서 사기라는 것은 아닙니다.
라이브러리가 결국 새로운 언어가 된다는 점은 인정하는데, 이것은 하드웨어가 발전하면서 새로운 논리를 충분히 받쳐 줄 수 있기 때문 아닐까 생각합니다.
좀 구닥다리라도 예전 방식은 속도와 메모리 차원에서는 훨씬 더 뛰어 나지 않을까요?(물론 노가다는 좀 해도)
쓰다 보니 뭔 소리 하려고 하는지 모르겠네요.
아~ 그냥 신기술들은 꼭 필요할 때 쓰는게 좋지 않아. 일부러 객체,상속 쓰려고 할 필요가 있을까?.. 이 질문이었네요..
답변 1
이 물음은 늘 순환되는 질문이라...
쉽게 말해 꽃 한송이를 심는데는 한자루의 삽으로 그만이고 포크레인은 잉여일 수 있습니다만..
건축의 기초를 팔 때는 삽으로는 어림도 없습니다. 물론 가능은 하겠지만요.
상속의 개념을 어찌 설명해야 할 지...
html 에서 테이블에 style 로 폰트사이즈를 12픽셀로 주었으면 그 테이블의 하부 엘레먼트인
td 나 span 등은 그 폰트사이즈를 그대로 상속받습니다.
만일 그렇지 않다면 우리는 td 나 span 마다 폰트사이즈를 지정해 줘야 하는 번거로움이 생기겠지요.
클래스 등에서 말하는 상속은 상속은 상속이되 이런 자동상속이 아니라 코드를 짜는 사람이 임의로 원하는 부분에 상속을 줄 수 있습니다. 말하자면 "사용자 상속"의 개념이라고 해야 되나요?
여튼 작은 꽃만 심다가 기회가 되어 드디어 큰 건물의 기초를 파야 할 시기가 오면
그때 포크레인의 귀중함을 절감할 수가 있다는 것 밖에는 달리 드릴 말씀이...
여튼 딱히 더 설명할 재주가 없네요...