블로그 이미지
레인레테
연락처 : rainlethe@rainlethe.com 영혼을 잃어버리다.

calendar

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

'개체지향'에 해당되는 글 2

  1. 2009/03/30 Everything is Object. 객체지향이라고?(4)
  2. 2009/03/11 OOP 를 배울 때 기억해야 할 단 한가지.
2009/03/30 15:25 RL.C omputer
Everything is Object.

모든것은 개체다.

객체지향 최대의 원칙.

말로는 쉽다.

그런데 이해하기는 어렵다.

그닥 도움도 안돼는것같다.

.. 왜일까?


지나치게 추상적이기 때문이다.


간단하게 생각해보자.

내가 쓰고 있는 글은 개체다.

글을 쓰는 수단인 키보드도 개체다.

그걸 보여주는 모니터도 개체다.


... 무슨 소리냐 대체?

못알아듣는게 정상인것같다.

프로그래밍 언어의 역사를 뒤척거릴 필요는 없지만

여기서 '개체'라는게 뭔지는 좀 짚고 넘어가야 할 듯 하다.


모든 프로그래밍 언어는 작은 덩어리의 집합으로 이루어져 있고,

이런것을 보통 '언어의 코어' 라고 부른다.

쉽게 예를 들면

1,2,3 같은 숫자. "하" 같은 문자. "안녕"같은 문자열. 등의 자료구조.(기본 타입)

if, for, while ... 등의 분기 및 반복구조.

실은 이 두개가 전부다.

전에 함수형 언어에 대한 오해 에서도 말했듯이 

프로그램은 자료구조와 알고리즘으로 이루어지고,

여기서 알고리즘을 기술하는 방법이 '자료구조를 이용한 분기, 반복' 등이다.


다시 개체 이야기로 돌아와서.

여기서 '개체'라는 건 단순히 자료구조 + 알고리즘 이다.

이전에 '구조적 프로그래밍 기법'에서는 '자료구조'와 '알고리즘'이 각자

'구조체'와 '함수'로 나누어져 있던 부분을

개체지향에서는 하나로 묶어서 기술한 것이다.

조금 심하게 말하자면

상속, 오버로딩, 오버라이딩, 캡슐화...  이런건 그냥 개체지향을 구현하다 보니

이것도 편리하겠는걸..싶어서 붙여놓은 것 뿐이다.

구조적 프로그래밍이나, 함수형 프로그래밍 패러다임에 따르면
'함수가 어떤 자료구조를 받아들일지 결정한다.'
(복잡하게 들어가면 한도끝도 없지만, 어쨌든 함수형 언어나 구조적 언어나
자료구조와 알고리즘을 분리하는것은 동일하므로 이 문맥에서는 다루지 않는다.)

반면 개체지향에서는
'개체가 메세지를 받을 지 결정한다.'
고 말한다.

뭐가 다르냐고?

거의 똑같다.(...)

개체지향에서 단어를 치환해서 [개체 -> 자료구조 | 메세지 -> 함수] 로 바꿔보면

자료구조가 함수를 실행할 수 있는지 결정한다.

로 바뀌게 된다.

그냥 바라보는 시선이 다른 것 뿐이다.

예를 들어볼까?

함수형이나 구조적 언어에서는 숫자를 문자로 바꿀 때 다음과 같이 사용한다.

IntToString(1); // Pseudo Code like c
Int->String(1) // Pseduo Code Like Haskell. 여기선 Int->String이 실제 함수 이름.

개체지향에서는 이렇게 사용한다.
1.toString(); // Pseudo Code Like Java or c#

어떻게 쓰는 결과는 똑같다.

그냥 우리는 각자 패러다임을 나누고 아옹다옹하고 있을 뿐이다.


개체지향의 진짜 장점은 '개체가 메세지를 받네 마네 ' 가 아니라

각각의 개체마다 (정확히는 클래스 지향 개체지향언어에서의 인스턴스마다)

자료구조로 이루어진 '상태'를 가질 수 있다는 점인듯하다.

즉 사고를 전환해서. '어떻게 실행할까?'라고 생각하는 것이 아니라

'어떤 데이터를 다루어야 할까?' 를 생각하게 하는 것이 패러다임의 변화다.

어떤 데이터를 다루는 일은 그 데이터에게 맞기자... 라는 것이 개체지향이라는 것이다.




여담.1. 오버라이딩.

여기서 한발짝 더 나가서. '서로 다른 데이터라도 비슷한 일을 한다면 같은 이름으로

함수를 불러도 되지 않을까?' 가 오버라이딩의 실체다.


여담2. 상속.

위에 기술했다시피, 개체지향에서 '할일'을 기술하는 메서드(함수)는 개체에 속한다.

그러니까 바꿔 말하자면 (이론적으로) 전역적으로 존재하는 함수같은건 없다는 말이 된다.

그럼 어디서나 갔다 쓸 수 있는 함수들은 일일이 다 개체마다 적어줘야 하는건가?! 라는

엄청난 압박이 생겨버리고 만다.

상속은 이런점을 해결하기 위해서
 
'공통되는 특성을 모아놓은 상위집합을 정의하는 개체'를 만들어놓고,

이걸 '확장'해서 사용할 수 있도록 시스템적으로 지원하는 것이다.

.. 이게 전부다.


여담3. 농담반 진담반. 내가 생각하기에 개체지향의 최고 장점은 '인텔리센스'인듯.
데이터 타입만 결정되면 멤버필드나 메소드가 튀어나와주니, 길고 긴 함수 목록을
안외워도 되서..


여담 마지막.
쓰다보니 아겔님 본문하고는 전혀 관계없어져버렸다.. 난감한데?;

2009.03.30 By RL.C
저작자 표시 비영리 동일 조건 변경 허락
posted by 레인레테
2009/03/11 10:31 RL.C omputer
Message Passing.


상속. 다형성. 캡슐화. 같은 건 그냥 Message Passing을 지원하기 위한 도구에 불과함.

클래스와 인스턴스 개념도 마찬가지.

모든 행동 양식은 '개체가 메세지를 받아들일 수 있느냐'로 결정된다.



-- 이런 관점에서 보면 Common Lisp이나, Erlang 같은 함수형 언어.
 Javascript나 IO 등의 ProtoType Base 언어.
등도 모두 OOP의 핵심개념은 관통하고 있다.

특히 Erlang의 메시징 프로세스는 최초의 개체지향 언어인 SmallTalk와 유사하다.

오히려 c#, Java, C++ 등은 . Message라는 것을 Function Call 화 시켜 버렸다.

그리고 나서 그걸 래핑해 둔 것을 개체지향의 특성이라고 우기고 있다.


이제 제발

아무것도 모르는 프로그래밍 신입생들을 데리고 나서

개체지향의 3대 장점은 '상속. 다형성. 캡슐화' 라고 책에서 본 대로만 읊어대지좀 말자..

저작자 표시 비영리 동일 조건 변경 허락
posted by 레인레테
prev 1 next