.png "back to home page")
그간 procedural language에서는 function과 procedure만을 지원했고 oop에 와서에 reciever란 개념이 생긴 것은 전반적인 syntax 에 굉장히 긍정적인 발상이고 이를 oop라 명한 것이 아닐까 하는 생각이 들기도 했다.
내가 생각했던 oop는 위와 같이 reciever의 등장과 그에서 기인한 abstraction, 그 둘의 synerge effect가 코드의 전반적인 단순화 및 추상화에 큰 도움을 주었다라는 것이었다.
윗 글은 reciever가 single reciever만을 기대하는 것이 아니라 multiple reciver(사실 여까지만 알아듣겠다;)의 중요성도 간과하지 않는다.
물론 jQuery를 사용하면서 multiple reciver의 존재의 중요성을 새삼 느끼긴 하였으나 여전히 그 핵심은 reciver의 존재를 통한 abstraction에 있는것이 아니었을까 하는 생각.
(사실 윗글은 보다 나은 oop의 언어적 차원의 지원까지 얘기하고 있으므로 풍부한 경험으로 정말 많이 내다본;; 글쓴이의 내공에 감탄을 표할뿐;)
윗글에서처럼 다형성을 그렇게 사용한다면 실제로 if - else 의 분리(type query)는 if else를 다른방식으로 풀어놓은 것이 되면서도 if문 없는 브랜치라는 얘기가 실제 성립을 하긴 하지만 이 모든 것은 사실 abtraction을 지원하기 위한 method들이 아니었을까; 하는 생각이 든다.
oop의 polymorphism에 대해 주로 썰을 풀어놨는데 어떤 경우에 polymorphism이 적용되어야 하는지를 자세히 서술했다.
허나 이러한 polymorphism이 단순히 if - else 의 대체제냐고 물었을때 단연코 아니다.
중요하게 생각한 것은 polymorphism이 얼마나 그 class의 concept에 충실하냐는 것.
결국 oop는 이러한 code context의 정돈에 도움을 주는 도구나 방편이 아닐까 하는 것이 내 소견이다.
Login to comment