지금 보기 시작했는데 얼랑 창시자 죠 암스트롱이 OOP의 대표적인 특징으로 캡슐화와 메시징을 뽑으면서 객체, 클래스, 메서드는 사소하다고 한 점이 마음에 든다. 10.11.24 10:24
스칼라, 얼랑, F# 창시자가 모여 함수형 언어를 논하다 by fupfin
17 개의 댓글이 있습니다.
전 영어라서 못봤어요 oTL
마사키군 인터뷰 한 내용이 밑에 글로 써 있어요. ㅎㅎ
Toby 객체는 캡슐화의 결과이고 메서드는 메시징의 방편이라는 뜻이지 대략 이런 뜻
Toby 캡슐화가 핵심이라는 거지 그게 다라는 말은 아니삼. 캡슐화와 메시징을 "강조"해줘서 고맙다 정도?
Toby 음... 암스트롱가 마이너하다고 한 걸 내가 사소하다고 한 건데 좀 느낌이 다를려나? ㅋㅋ 암튼 OOP가 캡슐화라는 더 근본적인 프로그래밍 원칙의 산물이라는 점을 간과하는 경향이 있어서 쓴 글이라능...
Alan Kay가 쓴 글 도 참고해보세요. 메세징과 다형성이 OO에서 가장 중요한 개념인 것 같습니다.
클래스나 상속은 확실히 사소한 것 맞는 것 같고요. 다형성과 일반화/특수화를 하기 위한 여러 매커니즘 중 하나인 것 같습니다.
다른 유명한 매커니즘으로는 프로토타입과 복제가 있고요.
클래스 기반 프로그래밍 기법이 OOP의 구현 방식으로 등장한 거니깐요. 홍민희옹이 말씀하신 것 처럼 OOP의 origin은 클래스 기반 프로그래밍과 거리가 있습니다. Toby님의 비판은 OOP 대가들의 주장과는 매우 거리가 있는 것입니다.
FP에서도 다형성은 존재합니다만 메시징에 의해 발현되는 다형성과는 다릅니다. 모델을 캡슐화를 해서 메시징을 보내는 것이 핵심이지요.
달리나음 음... 클래스나 객체가 OOP의 원형과 거리가 있다는 건 좀 과격(?)한 주장 같습니다. 적어도 연대기적으로 보면 시뮬라에서부터 스몰톡까지 분면 클래스와 객체 구조는 전통적인 OOP에서 있었구요. 오히려 프로토타입이 나중에 나왔다고 할 수 있죠.
홍민희 분명히 OOP의 전형인 시뮬라 67 때만해도 메세징은 중요하지 않고 캡슐화를 차원애서 클래스와 객체가 고안되었는데 스몰톡에 와서는 메시징이 오히려 더 강조되게 되게 되었죠. 그런데 경험해 본 프로토타입 언어는 JS 밖에 없네요. ^^
JavaScript는 pseudo constructor 때문에 프로토타입을 제대로 경험해보기 힘든 것 같아요. 요즘에는 Class-based OO 프레임워크 위에서 개발하는 경우가 많으니 더 그렇고요. Self나 Io를 해보시면 감히 더 잘 와요.
애초 OOP를 생각하던 이들의 방향이 메시징이었기 때문입니다. 객체는 애초에 메시징이 핵심이었는데 오히려 구현에서 발현된 클래스가 더 관심을 가지게 된 것이죠. 시뮬라의 클래스가 오히려 객체와 메시징 보다 더 큰 관심을 가지게 된 모양이라 생각합니다.
초기 레거시가 초기 OO의 의도와는 다르게 클래스라는 도구에 사람들을 얽매이게 한게 아닌가 아쉬운 생각이 듭니다.
달리나음 클래스를 별로 안 좋게 생각하시나보군요. ^^ 전 아직 클래스도 잘 못 쓰는 사람이라서... ㅠㅠ 좋은 글 고맙습니다.
fupfin 단순히 객체라는 개념과 다형성이 중요한 것이다!라고 생각했는데, 댓글을 보니 정말 구체적인 생각들이 있으신 것 같네요. 또 한번 자극 받고 갑니다.
전 영어라서 못봤어요 oTL
10.11.24 10:25마사키군 인터뷰 한 내용이 밑에 글로 써 있어요. ㅎㅎ
10.11.24 10:27Toby 객체는 캡슐화의 결과이고 메서드는 메시징의 방편이라는 뜻이지 대략 이런 뜻
10.11.24 10:53Toby 캡슐화가 핵심이라는 거지 그게 다라는 말은 아니삼. 캡슐화와 메시징을 "강조"해줘서 고맙다 정도?
10.11.24 11:08Toby 음... 암스트롱가 마이너하다고 한 걸 내가 사소하다고 한 건데 좀 느낌이 다를려나? ㅋㅋ 암튼 OOP가 캡슐화라는 더 근본적인 프로그래밍 원칙의 산물이라는 점을 간과하는 경향이 있어서 쓴 글이라능...
10.11.24 11:28Alan Kay가 쓴 글 도 참고해보세요. 메세징과 다형성이 OO에서 가장 중요한 개념인 것 같습니다.
10.11.24 14:12클래스나 상속은 확실히 사소한 것 맞는 것 같고요. 다형성과 일반화/특수화를 하기 위한 여러 매커니즘 중 하나인 것 같습니다.
10.11.24 14:14다른 유명한 매커니즘으로는 프로토타입과 복제가 있고요.
10.11.24 14:14클래스 기반 프로그래밍 기법이 OOP의 구현 방식으로 등장한 거니깐요. 홍민희옹이 말씀하신 것 처럼 OOP의 origin은 클래스 기반 프로그래밍과 거리가 있습니다. Toby님의 비판은 OOP 대가들의 주장과는 매우 거리가 있는 것입니다.
10.11.24 14:31FP에서도 다형성은 존재합니다만 메시징에 의해 발현되는 다형성과는 다릅니다. 모델을 캡슐화를 해서 메시징을 보내는 것이 핵심이지요.
10.11.24 14:41달리나음 음... 클래스나 객체가 OOP의 원형과 거리가 있다는 건 좀 과격(?)한 주장 같습니다. 적어도 연대기적으로 보면 시뮬라에서부터 스몰톡까지 분면 클래스와 객체 구조는 전통적인 OOP에서 있었구요. 오히려 프로토타입이 나중에 나왔다고 할 수 있죠.
10.11.24 14:44홍민희 분명히 OOP의 전형인 시뮬라 67 때만해도 메세징은 중요하지 않고 캡슐화를 차원애서 클래스와 객체가 고안되었는데 스몰톡에 와서는 메시징이 오히려 더 강조되게 되게 되었죠. 그런데 경험해 본 프로토타입 언어는 JS 밖에 없네요. ^^
10.11.24 14:48JavaScript는 pseudo constructor 때문에 프로토타입을 제대로 경험해보기 힘든 것 같아요. 요즘에는 Class-based OO 프레임워크 위에서 개발하는 경우가 많으니 더 그렇고요. Self나 Io를 해보시면 감히 더 잘 와요.
10.11.24 14:54애초 OOP를 생각하던 이들의 방향이 메시징이었기 때문입니다. 객체는 애초에 메시징이 핵심이었는데 오히려 구현에서 발현된 클래스가 더 관심을 가지게 된 것이죠. 시뮬라의 클래스가 오히려 객체와 메시징 보다 더 큰 관심을 가지게 된 모양이라 생각합니다.
10.11.24 14:57초기 레거시가 초기 OO의 의도와는 다르게 클래스라는 도구에 사람들을 얽매이게 한게 아닌가 아쉬운 생각이 듭니다.
10.11.24 14:59달리나음 클래스를 별로 안 좋게 생각하시나보군요. ^^ 전 아직 클래스도 잘 못 쓰는 사람이라서... ㅠㅠ 좋은 글 고맙습니다.
10.11.24 17:14fupfin 단순히 객체라는 개념과 다형성이 중요한 것이다!라고 생각했는데, 댓글을 보니 정말 구체적인 생각들이 있으신 것 같네요. 또 한번 자극 받고 갑니다.
10.11.25 01:52