<코딩을 지탱하는 기술>이라는 책을 읽다가 클래스에 대한 궁금증이 생겨 질문글을 올리게 되었습니다.
C++ 설계자인 Bjarne Stroustrup은 본인의 책에서 C++에서 클래스는 "사용자 정의형을 만들기 위한 구조" 라고 이야기했고, "Simula의 상속 구조가 문제 해결의 키"라고 이야기했습니다. 반면에 Smalltalk 설계자인 Alan Kay는 객체지향에 대해서 "형에 반대하지는 않지만, 고생하지 않는 형 시스템을 본 적이 없다", "Simula의 상속 방법은 좋지 않다"라고 이야기했다고 해요.
이 책에서는 "객체 지향에 대해 정의를 내리지 않겠다"고 이야기하고 앞으로 더 이에 대해 논하지는 않고 있습니다.
이 글을 읽으시는 분들은 객체지향과 클래스가 무엇이라고 생각하시는지 궁금해요.
0개의 의견 from FB
4개의 의견 from SLiPP
지난 번에 객체, 클래스, 인스턴스(http://slipp.net/questions/126)의의) 차이에 대해 이야기한 적이 있다. 이 글도 같이 한번 읽어보면 좋겠다. 질문 의도와는 약간 다를 수 있지만 객체 지향에 생각해 볼 여지는 있다고 본다.
simula의 상속 구조가 어떤지 전혀 몰라서 거기에 대해선 할 말이 없네요.
다만 본문에서 언급된 Stroustup의 말은 class 자체에 대한 설명이구, 뒤에 '문제 해결의 키'라고 한 건 그냥 번역상 그렇게 된 거 같구, 실제로 중요한 의미를 두고 말한 건 아닌 거 같아요. 그냥 그렇다는 말이지요.
반면, Kay의 발언은 동적이냐 정적이냐 하는 type 시스템에 관한 본인의 견해입니다. 어느 타입 시스템이 좋냐?는 건 결국은 영화 후기와 같은 본인의 취향 문제라(농담이 아니라 진짜 그렇습니다. 정답이 취향) 그냥 그렇구나 받아들이면 되는 말이죠.
객체지향은 프로그래밍의 단위가 객체인 거구, 클래스는 객체의 blue-print라 생각합니다. 저도 아는 거 하나 없지만, 어렵게 생각하실 필요는 없습니다~
자바지기님이 주신 링크에 말하고자 하는 이야기가 더 자세히 나와있으니 객체와 클래스가 차이에 대해서는 넘어가고
Bjarne Stroustrup는 객체 지향의 장점을 어떤 형태의 특징(형,type)에서 찾고 있습니다. Alan Kay는 객체간 관계에서 찾고 있고요. 앞선쪽은 80년대 객체지향프로그래밍에서 주류가 되었던 관점이고 뒤쪽은 90년대 객체지향 프로그래밍에서 주류가 되었던 관점이라고 봅니다. (시기 기준은 언어 생성, 설계 기준) 둘다 묵과 할수 없는 객체 지향 프로그래밍의 특징이라고 보고요... 어느쪽을 더 중점적으로 보는 것의 차이라고 봅니다.
일단 제 생각은 Objective Oriented ... 라고 하는데 Objective 라는 것은 객관적으로 인지 할수 있는 무언가. 그 느낌을 맞춘(oriented 한) 프로그래밍이다. 용어 자체가 굉장히 추상적이고 모호한 정의라고 봅니다. 즉 현실세계에서 인지할 수 있는 것들을 차용해서 프로그래밍을 하자. 이런 느낌인데 이래서 현실에서 인지하는 것에 대한 느낌이 달라지고 어떤 것들이 현실 인지에 도움이 되는지 다들 다르게 느껴지는 것이 이토록 객체지향 프로그래밍을 어렵게 만드는 요소라고 봅니다.
그래서 저자가 따로 정의하지 않겠다라고 한 것 같네요. 반대로 객체 지향이란 것을 정의한다면 객체 지향 기반 기술들이 발전하는데 오히려 저해될 수 있다고 봅니다.
결론으로 제가 생각하는 객체지향이란 현실 세계에 있는 것들을 추상화, 모델링하는 기법이라고 봅니다. 이쯤에서 예가 나와야 하는데 좋은 예가 안떠오르네요...
구매 행위를 객체화 한다면 그냥 "구매"라는 것을 뽑을 수도 있겠지만 지갑에서 현금을 꺼내는 행위를 "구매 준비" 라고 정의한다면 지갑에서 카드를 꺼내는 행위도 "구매 준비" 뱅킹앱에 계좌 번호를 입력하는 행위도 "구매 준비" 엄마에게 전화해서 돈 가져와 달라고 하는 것도 "구매 준비" 이렇게 "구매 준비"라는 객체를 특징을 간추려볼 수 있을 것이고 돈을 받는 사람이 "구매 준비"를 보고 "상품 확인"이라는 행위를 한다고 하면 "구매 준비"와 "상품 준비"간 서로 주고 받는 행위 들이 있겠죠. "구매 준비"가 구매 의사를 나타내고 "물품 하자 검출"를 수행해본다던지, 식당에서라면 "상품 준비" 시 선불인지 후불인지, 등등
간단하게 시간의 흐름으로만 프로그래밍 할 수 있는 문제를 몇가지 객체들을 도입하므로서 그들간의 관계를 나눠 전부를 한꺼번에 검토하지 않고 부분적으로 검토해 최종적으로 전체를 검토할 수 있게 하는 단위로서 장점이 있다고 봅니다.
그냥 생각을 정리하는 도구라고 보는게 좋겠네요. 계약 관계, 함수형, 관심도... 등등 그런 도구들을 더 찾아보세요...
https://www.facebook.com/javajigi/posts/10204355580392675 이 글에서도 이와 관련한 다양한 의견들이 올라오고 있으니 참고해 봐라.
한번에 모든 것이 이해되기 힘들겠지만 다양한 시각의 글들을 읽다보면 대략적인 개념은 잡을 수 있을 거다. 그런 식으로 개념 잡은 후에 추후 경험이 쌓이면서 좀 더 구체적으로 이해할 수 있다고 본다. 대략적인 개념이 잡히면 어딘가에 한번 정리해 봐도 좋겠다. 머리로 생각하는 것과 글로 정리하는 것은 다르거든.
의견을 남기기 위해서는 SLiPP 계정이 필요합니다.
안심하세요! 회원가입/로그인 후에도 작성하시던 내용은 안전하게 보존됩니다.
SLiPP 계정으로 로그인하세요.
또는, SNS 계정으로 로그인하세요.