객체지향 언어의 조건
저는 객체지향 프로그램이라면 논리적 대상을 객체로 묶을 수 있고 프로그래밍의 과정에서 그 객체라는 개념을 중심으로 코딩을 하는 것이라고 생각합니다.
C++ 에서는 객체를 정의할 때 클래스를 사용하고요. 다형성, 오버로딩, 오버라이딩 등등 모두 이 객체 중심적인 프로그래밍을 하는데 도움을 주는 언어적 기능이라고 생각하거든요.
다른 글타레(http://kldp.org/node/123275)에서 보면 제가 얘기하는 '언어의 오버로딩 지원이 코딩시에 객체의 표현력을 높인다'는 것에는 동의를 하시는 것 같아요.
그런데 거기까지만 동의를 해주시고 '하지만 오버로딩은 객체지향의 근본적인 특성에 포함되지는 않는다' 라고 하시는 것 같습니다.
이 시점에서 저도 하나 묻고 싶습니다.
그럼 객체지향의 근본적 특성이라면 무엇일까요?
상속, 다형성, 오버라이딩, 그런 것들일까요? 아니면 코드의 재활용성을 높인다. 높은 수준의 추상화가 가능하다 등등일까요?
아니면 상속, 다형성, 오버라이딩, 오버로딩, 높은 수준의 추상화와 그를 통한 코드의 재활용성의 향상의 특징들을 합친 것을 의미할까요?(이게 제 생각입니다.)
혹은 아직 존재하지 않지만 향후 등장할 수도 있는 또 다른 수단을 통해 객체를 코딩시에 더 잘 표현 할 수 있는 새로운 수단을 포함해야 할까요?(이것도 제 생각.)
객체를 코딩시에 더 잘 표현하기 위한 언어적 장치라면 객체지향을 위한 장치라고 봐야하지 않을까요?(역시 제 생각입니다 ^^)
이 글은 다른 글타레(http://kldp.org/node/123275)의 자식(?) 글타레 입니다. 새 주제가 되어 글타레를 새로 뽑았습니다.
오버로딩이나 오버라이딩은 편의성을 높이기 위한 도구라
오버로딩이나 오버라이딩은 편의성을 높이기 위한 도구라 할 수 있고,
객체지향 프로그램의 본질적 요건은 정적 특성과 동적 특성을 묶어 하나의 객체를 구성할 수 있다는 것과,
가상함수를 중심으로한 다형성을 이용하여 이러한 객체들을 통일성있게 운용할 수 있다는 점이지 아닐까요?
생성자 함수에서 오버로딩이 지원되지
생성자 함수에서 오버로딩이 지원되지 않는다면,
생성자의 인자의 개수와 타입에 따라 클래스를 따로따로 만들어야 합니다.
객체를 통일성 있게 운용하는데 가상함수를 통한 다형성만큼은 아니어도 오버로딩도 꽤 역할을 하는것 아닐까요?
오버로딩이 없다면, 생성자에서 필수적인 초기화만 하고
오버로딩이 없다면,
생성자에서 필수적인 초기화만 하고 부차적인 초기화 함수를 이용해서 생성자의 기능을 수행할 수는 있습니다.
불편할 뿐이죠.
아 그런데 이 글타레에서는 오버로딩만이 주제인 것은
아 그런데 이 글타레에서는 오버로딩만이 주제인 것은 아닙니다.
객제지향 프로그램 언어라고 부를 수 있으려면 어떤 조건이 갖추어져야 하겠는가 하는 것이 궁금한 것이었거든요..
이가 없으면 잇몸으로 살 수 있는 것이므로 말씀하신 것은 맞다고 생각합니다.
그래서 특정 언어들의 경우 default
그래서 특정 언어들의 경우 default argument, variable argument, named argument 같은 기능으로, 한 method에 충분히 몰아넣을 수 있게 해주기도 하죠.
바로 위에서도 언급됫습니다만, 오버로딩 없이도
바로 위에서도 언급됫습니다만, 오버로딩 없이도 그런일이 충분히 가능합니다.
제가 아는 언어로는 루비가 그렇게 이미 하고 있습니다.
객체지향의 특징을 꼽으라고 하면 객체
객체지향의 특징을 꼽으라고 하면 객체 아닐까요???
객체를 편하게 쓰기위해서 위에서 언급하신
'상속, 다형성, 오버라이딩, 그런 것들일까요? 아니면 코드의 재활용성을 높인다. 높은 수준의 추상화가 가능하다 등등일까요?'
가 쓰이는 것이라고 생각합니다.
그리고 객체지향적 장치라는 것에 동감합니다.
아마 소규모 프로그램 이었을 경우 프로그램이 복잡도가 낮았겠지만, 현대에 들어 수백명 이상이 개발하는 프로그램도 있습니다.
이런것에 대해 더 이해를 돕기 쉽게 프로그램을 짤 수 있지 않을까가 모티브가 되어 객체프로그래밍이 나온 것으로 알고 있습니다.
근본적으로만 따진다면 객체의 특성은 더 많은 사람이 프로그램에 대해 기존 절차지향적 프로그래밍에 비해 이해하기 쉽고 복잡도를 낮추기위해 배우는 나온 방법입니다.
하지만, 아이러니 하게도 객체지향 프로그래밍을 직접 하는 것은 어렵다고 생각합니다.
객체지향이 왕도는 아니죠.
C++가 좋고, overloading이 좋고, 연산자 overloading이 좋으면 좋은 거지, 좋다고 그게 객체지향은 아닙니다.
객체지향이 좋은 거고, 따라서 좋은 것은 객체지향이다라는 논리이죠. 그건...
추상화는 객체지향의 다른 단어가 아닙니다.
그리고 http://kldp.org/node/123275#comment-555603 에서 '자바와 C++ 에서는 연산자 오버로딩을 뺀다면,' 라고 하셨는데 Java는 연산자 오버로딩 지원하지 않습니다.
저는 C++의 연산자 오버로딩을 좋아하는 편이지만 그 이유는 template을 통해 형식 매개변수화를 할 때 내장형과 사용자 정의형을 구분하지 않고 활용할 수 있게 해주기 때문이죠. 하지만 template은 객체지향스타일이라고 하지 않습니다.
가끔은 프로그래밍 스타일들이 혼동이 가기도 하는데 뭐, 결국은 source를 잘 만들자는 목표를 추구하다보면 style은 조금씩 달라도 해결하고자 하는 바가 같기 때문이겠죠.
무엇을 객체지향이라고 부른다는 것은 조금씩 분명한 의미가 옅어지는데 C++, Java가 세상을 호령할 때는 4대 특징을 이야기하면서, 자료은닉, 캡슐화, 상속, 다형성을 말했었습니다. 이제는 자료은닉은 크게 염두하지 않는 것 같네요. 캡슐화도 그렇고요. 그리고 상속은 복제로, 다형성은 메시지로 동일하지만 조금은 느낌이 다른 기법으로 설명되기도 합니다.
객체지향도 그렇고, 최근까지 각광을 받았던 함수형
객체지향도 그렇고, 최근까지 각광을 받았던 함수형 프로그래밍도 그렇고,
결국은 어셈블리에 layer of indirection 을 몆겹 입혀 추상화 레벨을 높인 syntax 의 집합에 불과하다고 생각됩니다.
본질적으로는 폰 노이만 머신에서 한 발자국도 진화하지 못한 더미 머신 제어기에 불과할 뿐.
semantics 를 이해하는 인공 지능 머신과 지금의 더미 머신의 차이는 추상화 레벨을 높여 해결할 수 있는 문제일까요? 실제로 가능하기는 한 목표일까요?
C++ 이 백년은 갈 것 같네요.
'자바가 연산자 오버로딩 지원한다' 라고 말했던 것
'자바가 연산자 오버로딩 지원한다' 라고 말했던 것 때문에도 불안했었습니다.
아 불확실한 정보로 게시판을 흐려서 죄송합니다.
짐작만 가지고 해서는 안되는게 코딩 뿐만 아니라 개발자들과 대화할 때도 마찬가지인 것을... 저도 그렇게 틀린 말 하는 개발자들 싫어하거든요..
... __;
좋은 하루 되세요..
객체지향 근본 특성은 모르지만 일반적 특성은 객체 이름에 의한 기능에 대한 접근 편의성이 아닌가합니다.
객체 지향 근본 특성은 잘 모르겠네요.
다만, 객체 지향 언어만의 특성이라면,
객체에 이름이 부여되어 그 이름으로 부터 누구나 쉽게 원하는 기능을 꺼내 쓸수있다는 편의성이 아닌가 합니다.
이점은 하나의 언어의 문법적인 부분만 따지는것이 아닌
"표준 라이브러리" 체계화가 얼마나 잘 되어 있고,
사용자가 그 객체의 이름으로 부터 연상되는 기능을 얼마나 많이 제공해 주느냐? 라는 문제인듯하네요.
너무 근본에 매달리지 마세요. 솔직히 object
너무 근본에 매달리지 마세요.
솔직히 object == method(or action) + data 정도만 구현되면 충분히 객체 지향이라고 할 수 있지 않을까요?
prototype base냐 class base냐에 따라서 object를 서로 다른 시각에서 접근할 수도 있습니다.
심지어 lisp 프로그래머에게 object가 뭘까요? 하고 물어보면 "lambda"라고 할 겁니다.
..
C와 같은 procedural language라고해서 객체지향을 못하는 것은 아닌 것 같습니다. GTK같은 것에서는 C로 별 것은 다하는 것 같더군요. 제가 생각하는 객체 지향 언어의 조건은 요런 것 같습니다.
1. Method call을 하나의 객체에 붙을 수 있는가?
2. 기존 객체를 상속받을 수 있는가?
3. Polymorphism, 즉 상속받은 객체는 기존 객체와 같은 취급을 받는가?
A rose is a rose is a rose..
너무 형식에 집착할 필요는 없습니다. 객체를 적절하게
너무 형식에 집착할 필요는 없습니다.
객체를 적절하게 표현할 수 있다면 객체지향 언어 또는 객체 지향을 지원하는 언어라고 불러도 무방할 것같네요.
메시지니 메서드니 등등 형식의 구분에 얽매이다보면 큰 개념을 놓치는 경우가 있습니다.
OO design과 OOP 또는 OO언어는 구별되어야합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
교과서적 정의가 때로는 맞을 때도 있죠. OOP의
교과서적 정의가 때로는 맞을 때도 있죠. OOP의 공식적인(?) 특성은 encapsulation, inheritance, polymorphism입니다. OOP가 널리 통용되는 용어이니만큼 거기에 자신만의 의미를 덧붙이기보다는 용어에 이미 담겨 있는 의미들을 재사용(?)하는 게 좋겠지요. 용어는 용어대로 두고 그게 좋으냐 안 좋으냐, 어떻게 활용해야 하느냐 등의 논의는 분리해서 진행해야 하지 않을까요.
아뭏든 이런 이론적 관점에서 보면 polymorphism을 지원하는 가장 중요한 도구가 overriding이므로 overriding이 OOP의 특징이 맞고, overloading은 세 요소 어디에도 기여하지 못하므로 OOP의 특징이 아니라고 보는 게 맞겠지요.
일부 overloading이 polymorphism의 다른 형태이기도 하다는 주장을 하는 사람도 있긴 하고, 전혀 틀린 말은 아니긴 한데, 이런 형태의 overloading은 대개 encapsulation을 해치는 경우가 많아서 역시 OOP의 특징이라고 보기는 어려운 것 같습니다.
그리고 사실 파이썬, 자바스크립트 등의 언어에서는 파라미터 디폴트값, 가변 파라미터, duck typing 등을 조합해서 overloading의 needs를 해소합니다. static typing 언어에서만 overloading이 유용하다고 볼 수도 있습니다.
매우 공감합니다.
명쾌한 글이네요.
There is no spoon. Neo from the Matrix 1999.
익히 알고계신대로.
프로그램이 object를 기반으로 구성되며 object는 data structure와 method의 묶음이다.
딱 여기까지만 근본적인 특성이라고 봅니다. 그 이외에는 어떤것도 OO의 필수조건이라고 생각하지 않습니다.
[냉무] 동감합니다.
동감합니다.
예전에 어셈블리어로 OOP를 하는 것에 대한 책도 있었습니다.
OOP는 개념(모델)이지 특정 기능의 집합을 지칭하는 말은 아니라고 생각합니다.
--
Minimalist Programmer
어제 즉흥적으로 이 쓰레드를 열었었습니다. 이전
어제 즉흥적으로 이 쓰레드를 열었었습니다.
이전 쓰레드에 답글을 달 때도 그랬구요..
그런데 인터넷에 연결이 안되어있는 시간동안에도 계속 불안했었습니다.
아 내가 괜한 쓰레드를 열었구나... kldp에 계신 분들로 부터 혼나겠다..
이제 나도 트롤로 등극하는 것인가..
저는 C++을 처음 배운 것이 대학교 복학하고 '추윤식의 C/C++ 방학특강' 이라는 강좌를 통해서 였습니다. 한 5만원돈이었던 것 같은데 완전 박수갈채를 받았던 명 강의였죠. 저는 그 때 C++을 처음 배웠구요. 그런데 실상은 C 강좌였기 때문에 C++은 클래스에 대해서만 간단히 배웠었죠.
이후 약 15년 동안 C++은 넘볼 수 없는 벽으로 남은 채 개발자로 일하면서도 C 만 사용했었습니다.
C++에 눈을 뜬 것은 근래에 옆 동료가 '디자인패턴'이라는 얘기를 맨날 하길래 그게 몬가 하고 찾아보다가 C++을 일할 때도 사용하기 시작했어요.
그런데 처음 쓰기 시작하는 단계이다 보니 너무 재밌습니다.
이게 딱 제 수준인 것이죠.. 그동안 winner 님과 neocoin 님이 많이 알려주셨었고요..
오버로딩은 객체지향 언어들이 가지고 있거나 가지고 있지 않기도 한 하나의 장치정도로 생각하면 될 것 같습니다.
위에 어떤 분 말씀대로 객체지향은 데이타와 메소드를 묶어서 사용할 수 있기만 하면 되는 하나의 프로그램 방법론이다 정도로 생각이 정리 됩니다.
실상 C 언어로 객체지향 프로그램 할 수도 있으니까요. 프로그래머의 능력만 된다면요..
주관적일 수 밖에 없는 질문을 올려서 많은 분들이 글 쓰시느라 시간을 들이게 했으니 죄송하네요...
오버로딩이 무엇인가 하는 것은 그래도 제대로 공부한 것 같습니다. ^^;
모두들 좋은 하루 되세요...
여기는 수파리의 리 단계에 접어든 분이 너무 많아서...
http://lakumdo.com/208
이런 용어를 kldp에서 볼줄이야~ 혹시
이런 용어를 kldp에서 볼줄이야~
혹시 검도하시나요..? 맞다면 반갑습니다. :-)
언어 문법에 클래스가 있으면 OO언어아닌가요? C같이
언어 문법에 클래스가 있으면 OO언어아닌가요?
C같이 객체를 굳이 만들수는 있는 언어를 OO언어라고 하지 않자나요.
마찬가지로 어셈으로 OO를 해도 OO의 흉내라고 생각합니다.
LISP에서도 CLOS를 따로 패키지로 만들었듯이
언어에 OO를 위한 기능이 내장되어야 OO언어이며 이를 가지고 OO를 구현하면
그게 OO프로그래밍이라고 생각합니다.
GTK처럼 굳이 OO를 만들어서 OO프로그래밍을 했다면
편의상 OO를 흉내냈다거나 OO의 일부를 도입했다..라고 봅니다.
도구자체와 도구질(?)을 같은 선상에 놓고 보면
도구자체와 도구질(?)을 같은 선상에 놓고 보면 안됩니다.
망치로 땅을 파거나, 삽으로 무를 써는 일은 꽤나 많습니다.
클래스가 있으면 OO언어라고 부를 수 있지만, OO언어를 쓴다고 누구나 OO프로그래밍을 하지는 않지요.
하지만 위의 다른 분들이 말씀하신 것 처럼, OO언어를 쓰지 않더라도, OO철학에 의거해서 프로그램을 짠다면, OO프로그래밍이라 할 수 있습니다.
칫솔로 잇속을 건강하게 만드는 방법만 있는게 아니고, 가글이나 치실로도, 심지어 손가락만으로도 할 수 있는 방법은 있으니까요.
------------------------------
How many legs does a dog have?
예 저보다 OO를 더 잘 아시는 많은 분들께서 같은
예 저보다 OO를 더 잘 아시는 많은 분들께서 같은 말씀을 하시고 계시지요
그냥 제 생각에는 굳이 C나 어셈같은 언어로 OO를 구현했을때
그 코드를 재사용하는 입장이나 개발하는 입장에서 과연 OO 철학에 맞게
이용하고 개발할 수 있는가에 의문이 생깁니다.
리눅스 커널에서 VFS나 디바이스 드라이버 등에서 콜백함수나 플러그인 형태로
객체의 메소드처럼 서비스를 호출하는데 이걸 OO라고 말하면 아니라고 할 수도 없지만
제 생각에는 그냥 C언어가 언어 자체로 제공하는 특정 기능들을 멋있게 활용하는 것으로만 느껴집니다.
...그냥 제 생각입니다. 저도 한동안 C로 뭘 만들어놓고 이게 OO인가 아닌가
그럼 OO는 뭐고 안OO는 뭔가...하고 고민을 한적이 있어서 그냥 올려봤습니다.
OO 프로그래밍에서 Object는 Data
OO 프로그래밍에서 Object는 Data Abstraction을 극단적으로 한 모양을 띄는게 보통입니다.
함수조차도 Functor같은 걸 만들어쓰듯이, 대부분을 Data Abstraction을 통해서 프로그램을 만들려고 한다면 OO로 볼 수 있습니다.
모든 것을 Data Abstraction화 할 수 있다면 Pure OO가 되겠지요.
비슷하게 Functional 프로그래밍에서 Function(또는 Lambda)는 Procedural Abstraction을 극단적으로 한 모양을 띕니다.
간단한 데이터 조차도 Function으로 만들어지며, 대부분을 Procedural Abstraction을 통해서 프로그램을 만들려고 한다면 Functional로 볼 수 있습니다.
모든 것을 Procedural Abstraction화 할 수 있다면 마찬가지로 Pure Functional이라고 불리게 될 겁니다.
------------------------------
How many legs does a dog have?
질문이 있습니다. 제가 전자과 출신이라 SW쪽 개념이
질문이 있습니다. 제가 전자과 출신이라 SW쪽 개념이 거의 없어서 이해를 부탁드립니다.
데이터를 추상화한다는 것이 구체적으로 어떤 것인가요?
예를 들어 복소수를 표현할때 구초제를 만들어서 실수와 허수를 하나의 구조체안에 넣어서 처리한다면
이런게 데이터의 추상화가 맞나요?
이런 정도의 추상화는 어느 언어든지 지원하는 것인데 이걸 OO라고 하면 거의 모든 언어가 OO가 되는게 아닌지..
물론 그보다 더 높은 수준의 추상화를 말씀하시는 것이겠지요?
생각할수록 제가 object가 뭔지조차 모르는것 같습니다.
그냥 제 생각처럼 상태와 메소드를 묶어서 관리하는 정도가 아닌것 같네요.
갠히 모르면서 끼어들었다가 무식만 탄로났... :-(
> 예를 들어 복소수를 표현할때 구초제를 만들어서
> 예를 들어 복소수를 표현할때 구초제를 만들어서 실수와 허수를 하나의 구조체안에 넣어서 처리한다면
> 이런게 데이터의 추상화가 맞나요?
네 맞습니다.
하지만 Data Abstraction을 지원한다고 OO언어가 되는 건 아닙니다.
단지 OO를 쓸 수 있는 언어가 될 뿐이지요.
말씀대로 이정도 수준을 지원하지 않는 언어는 없으므로(Combination을 지원하지 않으면 언어가 아닙니다.) 모든 언어로 OO프로그래밍을 할 수 있습니다.
처음부터 설명하자면, Abstraction은 그저 복잡한 것에 이름을 붙이는 걸 말합니다.
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#%_sec_1.1
primitive expressions, which represent the simplest entities the language is concerned with,
means of combination, by which compound elements are built from simpler ones, and
means of abstraction, by which compound elements can be named and manipulated as units.
Data Abstraction만 따지자면, 그냥 Data에 이름을 붙이는 걸 말합니다.
더 쉽게 이해하기 위해 Functional을 보겠습니다.
http://en.wikipedia.org/wiki/Church_encoding#Church_pairs
처치 인코딩에서 pair는 함수로 정의합니다.
pair에 두 값을 넣으면, 들어간 상태로 저장되고, 계산되지 않습니다. (Normal-Order Application)
fst와 snd는 각각 첫번째 값과 두번째 값을 꺼내는 함수인데,
fst와 snd가 계산될 때, 인자로 들어간 pair application에 묶여있던 값이 풀려나오게 됩니다.
이것만 따지면, 각 함수에 Procedural Abstraction만 적용한 것입니다.
하지만 처치 인코딩에서는 숫자도 함수로 정의합니다.
http://en.wikipedia.org/wiki/Church_encoding#Church_numerals
이처럼 언어상에 존재하는 모든 것을 Function으로 보고, Combination과 Abstraction을 통해서 프로그램을 작성하면 Functional 프로그래밍이라 볼 수 있습니다.
---
다시 돌아가서, 앞서 본 Functional 프로그래밍처럼, 모든 것을 Object로 보고 프로그램을 짜야, OO 프로그래밍으로 볼 수 있습니다.
실수와 허수를 구조체에 넣는 것 뿐만 아니라, 복소수로 가능한 연산까지 구조체에 넣어야 합니다.(모든 것을 데이터처럼 취급해야 하므로;데이터 따로-함수 따로가 아니라)
가능하면, 숫자도 오브젝트로 보고((factorial 3)이 아니라 (3 factorial)로 쓸 수 있고), 심지어, 메소드나 메시지 조차도 오브젝트로 동작한다면 더 OO 같을 겁니다.
정리하자면, 말씀하신대로 "상태와 메소드를 묶어서 관리"하기만 해도 일단 OO에 발을 들여놓았다고 봐도 무방합니다.
하지만 그저 OO적인 기능을 쓰는 것일 뿐이며, 모든 것을 Object로 바라보지 않는 다음에야 그것만으로 순수하게 OO 프로그래밍을 한다고 말할 수는 없습니다.
예를들어서, Ruby의 경우 숫자는 실제로는 Object가 아닙니다. 하지만, 언어적으로 처리를 통해서 마치 숫자도 Object인 것처럼 동작하도록 메소드를 쓸 수 있게 되어있습니다.(실제로 Object는 아니지만, Object로 취급하겠다는 뜻이지요.)
하지만 현실적인 문제나 철학적인 문제, 또는 경험적인 문제로, 순수한 OO, 순수한 Functional은 학술적인 목적을 제외하고는 큰 가치가 없습니다.
요즘에는 OO에서도 몇가지 디자인패턴이나 Generic을 통해서 Functional을 쓰려고 하며, Functional쪽에서도 Object나 Class를 쓰기 위해 노력중입니다.
단지, 겉보기에 같은 기능이라도, 언어 깊숙한 곳에서 OO관점으로 바라보느냐(즉, 모든 것을 Object로 보느냐), 아니면 Functional 관점으로 바라보느냐(즉, 모든 것을 Lambda로 보느냐)의 차이가 있을 뿐입니다.
그러니 Object가 무엇인지 정의하는 것은 큰 의미가 없습니다. 쓰시는 언어 메뉴얼에서 "Object is ~"록 설명된 부분만 제대로 읽고, 쓰기 편한데로 프로그램짜면 됩니다.
------------------------------
How many legs does a dog have?
갠히 부족한 질문을 해서 시간만 뺏은것
갠히 부족한 질문을 해서 시간만 뺏은것 같습니다.
자세한 설명 감사드립니다 ;-)
...
저도 잘 모르지만 제가 생각하는 데이터 추상화는
복소수를 표현할때 구초제를 만들어서 실수와 허수를 하나의 구조체안에 넣어서 처리한 결과도 추상화라 할수 있지만,
복소수를 실수와 허수로 나눈다는 개념 자체를 데이터 추상화라고 생각합니다.
현실(?)의 객체를 데이터로 가공하기 위해 적절한 변수와 함수등으로 뽑아 내는 행위 자체를 데이터 추상화라고 생각하며
개인적으로 이 부분은 정말 어려운 부분이라고 생각합니다.
정말 좋은 글이네요.
'모든 것을 오브젝트로 본다'. 저는 전에 선구자들이 말한 비슷한 것을 글로 본 적이 있는데, 제 경우는 날카롭게 생각하기는 힘든거 같습니다.
가끔 프로그래밍이 '기술'이 아니라 '철학'일지도 모른다는 생각이 들 때마다, Oriented(지향)에 대해 생각하게 되는데,
이렇게 '기초 밑의 기초'같은 자주 볼 수 없는 이야기를 한 눈에 보게되니 마음이 새로워지네요.
감사합니다.
여기에 참전(?)해도 될지 모르겠습니다만...
저는 바이너리 쓰레기를 만드는 취미 개발자에 불과하기에 사실 여기에 끼어들기는 조금 그렇습니다.
하지만 OO의 조건에 'O' 말고는 필요할까라는 생각을 합니다. Object가 있기만 하면 거기에 어떠한 특성이 붙건 OO라고 묶을 수 있을 것입니다.
언어는 계속 발전하고 불편한 점을 보완하며 틈새를 개척해나갑니다. 살아 발전하는 것이 언어인데 그것을 극히 좁혀 생각할 필요는 없다고 봅니다.
OO 언어를 쓰면서 OO로 개발하지 않을 수도 있겠지만 '언어'의 특성으로서 Object 구조를 띠면 일단 OO로 불러야 한다는 것이 제 생각입니다.
추신: 그런데, 이렇게 조금만 무거운 주제가 되어도 익명분들의 참여가 극히 줄어드는군요. 리눅스를 욕하고 회원들을 욕하면서 이러한 주제에는 냉정한
그 분들의 사고 방식은 무엇인지 궁금합니다. 이런 주제에도 다른 스레드처럼 불타면 진짜 환영할만한 일일 것입니다만.
=================================
이 세상은 썩어있다!
- F도 F시 시가지 정복 프로젝트
홈페이지: 언더그라운드 웹진 18禁.net - www.18gold.net
이 쓰레드는 그냥 열어두려고 합니다. [완료]처리를
이 쓰레드는 그냥 열어두려고 합니다.
[완료]처리를 했었는데도 좋은 글도 올라오고 의견들을 계속 올리시니
그냥 열어두는 것이 좋겠다고 생각이 듧니다.
객체지향의 수단이라면
본질은 객체와 객체에게 보내는 메시지를 처리하는 방식입니다. 이 부분의 핵심적인 수단은 다형성입니다.
다형성을 구현하는 수단으로써, C++이나 JAVA는 공통 interface(혹은 공통 부모 클래스)에서 선언한 메써드가 메시지인 셈이고 그 메시지를 받는 객체가 자신의 클래스 안에서 정의된 대로 해당 메시지를 처리하는 구조입니다. (이것이 오버라이딩입니다.)
스몰토크나 Objective-C는 다른 개념으로 접근합니다. 어떤 메시지(코드상으로야 메써드로 나타나죠)에 대해 그것을 받는 객체(receiver)가 받아서 처리를 합니다. 공통 부모나 인터페이스가 필요없이 오직 메시지를 받을 수 있는 객체냐 아니냐만 따지게 됩니다.
객체지향 언어쪽에서는 개념상 흐름이 메시지와 그 메시지를 받는 리시버가 존재하는 것이고, 해당 리시버가 메시지를 처리할 수 있는 객체인지는 동적으로 결정이 되는 부분입니다. (메시지를 처리할 수 없는 객체에 메시지를 던지면 예외가 나던지 하겠죠.) 이런 부분 때문에 객체지향 언어에서 동적바인딩도 큰 특징 중에 하나가 됩니다. 엄밀히 말하자면 다형성을 지원하기 위한 하나의 수단인 셈이죠.
주제에서 벗어난 이야기를 한 이유는, 오버로딩과의 차이를 설명하기 위해서입니다. 오버로딩은 동적 바인딩이 아닌 정적 바인딩에 속하기 때문입니다. 같은 메시지로 오버로딩된 메써드가 바뀌어가면서 호출될 수가 없는 구조입니다. 오버로딩된 메써드는 완전히 별개의 메시지인 셈입니다.
C도 초창기 C버젼에서 호환성에 문제가 생겨서 그렇지, 최신 문법만 적용하면 오버로딩처럼 같은 이름의 함수에 인자만 바꾸어 선언하게 만들 수도 있는 구조입니다. (가능하지만 안 하는 것이죠.)
=================
잠못자는 한솔아빠
OOP의 개념은 이런 것이 킹왕짱
위엣분이 다형성을 말씀하셔서 검색을 해봤습니다.
역시나 kldp에 좋은 쓰레드가 있었더군요.
http://kldp.org/node/106790
http://alankang.tistory.com/249
http://kldp.org/node/75233
http://beyond.daesan.com/articles/2006/08/16/misunderstanding-and-truth-about-oop
http://beyond.daesan.com/articles/2006/08/17/misunderstanding-and-truth-about-oop-2
두번째 링크는 첫번째 쓰레드에서 소개가 되었는데 글 쓰신 분이 스스로 자신의 개념이 킹왕짱이라고 생각한다고 해서 이 글의 제목으로 삼았습니다.
다형성이 핵심인 것 같습니다.
그리고 다형성중에서도 서브타입 다형성인가요? 그것만이 객체지향적 패러다임의 핵심이라고 대다수의 분들이 인정하시는 것 같습니다. ad-hoc polymorphism 인 오버로딩은 비주류라고 봐야 할 것 같네요..
그리고 C++ 의 특징이 곧 OOP의 특징인 것도 아니라는 것도.. 잘 알아두어야 할 것 같습니다. ^^; 루비와 같은 OO 언어를 하나쯤 공부해두는 것도 좋겠다는 생각이 듧니다.
제가 어깨너머로 공부 많이 하는 것 같습니다. KLDP에 감사하죠..
'성공하는 사람들의 7가지 습관'에 보면 노파와 여인으로 동시에 판독되는 그림을 놓고 노파의 사진을 먼저본 사람은 그 그림을 노파라 하고 여인의 사진을 먼저 본 사람은 그 그림을 여인이라고 주장하게 된다는 실험 내용이 계속 머릿속을 맴돕니다. 노파와 여인의 사진을 모두 본 사람은 그 그림을 노파도 될 수 있고 여인도 될 수 있다고 얘기할 수 있을텐데 말이지요.. 이것도 폴리모피즘일것 같네요 ! 호..