태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
블로그 이미지
Lonewolf dlbo

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 30          

Notice

2008.12.02 12:48 (비정기) Dlbo's Post

ㅁ_ㅁ

지난번의 "객체지향 이야기"는 더 이상의 이야기를 하자면

"디자인 패턴"이라는 복잡한 분야로 들어가야 하는데

이는 이해하기도 상당히 난해하므로 일단 접어둡니다.

객체지향의 기본도 절차지향이므로 이번 포스트 부터는 절차지향과 객체지향의 공통분모인

프로그램의 설계에 대해 언급하겠습니다.

---------------------------------------------------------------------------------------

프로그래밍을 처음 공부하는 사람이나 조금 했던 사람이나 많이 하는 사람이나 모두 공통적인

고민을 가지고 있습니다.

"뭘 만들지?"



....

예.

그렇습니다. -_-

우리에게 가장 중요한건...

뭘 만드느냐 입니다 -_-;

프로그램을 도대체 무엇을 만들 것이느냐!

하는 문제는 종종 아래의 3가지로 나뉘어 처리되곤 합니다.

    1. 클라이언트나 다른 사람으로부터 개발을 의뢰받는다.
    2. 책을 보거나 기존의 프로그램을 벤치마킹하여 그 기능을 모방한다.
    3. 학교 과-_-제를 한다.

...

3번이 압권이군요.

이제 곧 분석 포스트가 올라올 Simple VI와 Mini Shell 역시 3번의 이유로 인해 개발된 사례입니다 -_-;

1번의 경우는 프리랜서나, 심심한 대학생들이 시간은 썩어나고 노는것도 질리고 해서 시작해보는 경우가

많습니다.

2번의 경우는 프로그래밍을 처음 시작하는 경우에 많이 접하게 되는 방식이지요.

게임을 만들거나 채팅프로그램을 만들거나 메신저를 만들거나 하는 모든 것도 이런 식으로 채택이 됩니다.

자...

이걸로 대충 뭔가를 만들어 보겠다고 결정이 났다면,

....

어떻게 만드실래요?-_-?

이것이 중요합니다.

일부를 들어 이부분만 전문적으로 하는 프로그래머를 "아키텍쳐"라고 부르기도 합니다.

프로그램을 만들기 전 도입부로서 프로그램의 내부 구조를 직접 설계해 코딩작업을 훨씬 수월하게 하는

과정이지요.

주로 "어떤 언어를 쓸 것이고, 어떤 라이브러리 사용이 필요하며, 어떤 부분의 학습이 필요하다."

라고 미리 정해두고, "언제부터 언제까지 설계를, 언제부터 언제까지 코딩을, 언제부터 언제까지 디버깅을!"

이라고 구체적으로 나눠 보는 것이지요.

이번 포스트에서는 이 설계부분중 "구조 설계"에 대해서만 언급합니다.

사용자 삽입 이미지

꺄앍 -_-

더럽게 큰 그림 하나 등장.

사람마다 다르긴 하겠지만 대부분의 최고의 프로그램은 메인함수 내에 문장이

많아봐야 5~6개라고 합디다. -_-;

아, 물론 변수선언부는 빼구요. 전역변수의 사용도 최대한 금한답니다.

저 부분은 메인함수 내부에서 권장하는 실질적 처리부분들 입니다.

각각 한 칸당 한개의 함수로 처리하는걸 권하고들 있지요.

고로 최고의 구조라는건 이렇게 생겨먹은 코드라고 누군가 그랬습니다만.

디버깅하긴 편하긴 하겠다만 왔다갔다 거리기 더럽게 귀찮을듯 합니다. -_-;



호오...

메인함수가 정말 깨끗해 보이긴 합니다.

이렇게 기본 뼈대는 설계 하고 자시고도 없습니다.

그런데, 이게 반복되는것이 있습니다.

바로 파일 로드 및 초기화 부분과 저장 및 정리부분.

기본 뼈대보단 좀 더 복잡하긴 하지요.

사용자 삽입 이미지
꺄울

-_-

파일 로드 및 설정 로드 부분은 코더의 입맛에 따라, 프로그램의 형태에 따라 다릅니다.

가령 예를 들면 게임을 실행시킬때 데이터 파일을 로드해 유저의 게임 정보를 메모리에 띄워야 할 땐

그냥 템플릿 벡터를 이용해 로드하면 되고, VI를 만들땐 템플릿 리스트를 이용해 파일의 각 줄을 하나하나

리스트에 삽입해 버리는 것이지요.

설정 로드 또한 유저의 게임 환경이나 vi의 표시 환경에 대해 메모리상에 로드 한 후,

다음에 있는 초기화 부분에서 이니셜라이즈 시키는 겁니다.

이 또한 한개의 사각형에 대해 1개의 함수 사용을 권장한다고 하는군요.

-_-;

이 부분은 사용자들의 입맛에 따라 다르니 코드를 생략하도록 하겠습니다.

사용자 삽입 이미지
멋있는 친구 하나 추가 등장.

기본 구조의 가장 마지막에 있는 "저장 및 정리" 파트입니다.

동적 바인딩 해제란 "동적 메모리 할당으로 붙잡아둔 메모리들의 정리"를 의미하며,

설정 및 파일 저장이란 "여태까지 사용한 설정과 편집된 파일의 내용을 기록함"을 의미합니다.

이 또한 각 한칸당 1개의 함수 구현을 권장하고 있습니다.

사용자 삽입 이미지
프로그램에서 가장 중요한 부분을 하는 "조작 및 실행"파트입니다.

전체 뼈대 구조에서는 2번째 위치에 자리잡고 있지요?

여기서도 1칸당 1개의 함수 구현을 요구하나, 저기 가운데 보시면 내부 동작 체크와 제어 함수 동작이

서로 맞물려 돌아가고 있습니다.

두 함수가 서로 상호작용적으로 동작해 프로그램을 돌리는 것이지요.

이 부분은 바로 프로그램의 핵이나 마찬가지이고, 프로그램 그 자체라고 볼 수 있습니다.

이로서 프로그램 기본 구조에 대한 4가지를 정리해 봤습니다.

여기서 공통점을 하나 발견할 수 있는데요.

"메인함수를 포함한 대부분의 함수가 초기화->조작->정리->리턴"의 패턴을 반복한다는 점과

함수 내부에서 3~4줄 이상으로 길어질 법한 부분은 모두 다시한번 함수로 처리한다는 것입니다.

이 방법의 장점은 "디버깅이 쉽다", "코드 읽기가 수월하다" 외에도

"이미 사용한 함수가 다시한번 사용될때 재사용이 가능하다"는 점과

"상향지향성 개발과 하향지향성 개발의 중간에 있어 객체지향과 절차지향을 모두 바라볼 수 있다."라는

점이 매력적입니다.

물론 저건 메인함수를 기준으로 함수를 호출하는 방식으로 했으나,

메인함수에서의 객체 생성, 혹은 전역객체생성으로 프로그램을 동작시킨다면 객체지향적인 입장에서

프로그램을 설계할 수도 있지요.

-----------------------------------------------------------------------------------------------

오호. 이번껀 스크롤 압박이 좀 있지 싶습니다. -_-;
posted by Lonewolf dlbo

댓글을 달아 주세요

2008.11.04 20:08 (비정기) Dlbo's Post





으흠.

시작부터 지저분한 소스코드가 널려있군요.

눈치 빠르신 분, 혹은 MFC를 공부해 보신 분은 아시겠지만

MFC의 Hello Window?!코드입니다.

4개의 파일로 나눴습니다.

각각 클래스에 해당하는 .h파일과 .cpp파일입지요.

왜 cpp파일이느냐... 하면...

MFC가 클래스 기반이니 C++로 쓸 수 밖에 없어서라는 답변밖에는 못하겠군요 ㄱ-;;

MFC는 윈도우즈 API를 객체지향적으로 재구성한 클래스의 집합입니다.

자세히 보시면 CHelloApp 클래스에서 생성된 theApp객체를 생성합니다.

메인함수가 생략된 대신, 이 객체를 생성하면서 프로그램이 시작되지요.

이 때, InitInstance라는 메소드를 이용해 내부에서 윈도우 객체를 하나 만듭니다.

이름하여 사용자가 CFrameWnd에서 상속한 CMainFrame.

afx_msg로 선언된 메소드들은 모두 MainFrame.cpp에 구현된 메시지맵과 매칭됩니다.

메시지맵은 해당 파일 맨 아래에 코드도 아닌것이 기묘하게 생긴 친구들이지요.

으흠... 쓸데없이 MFC 이야기만 했군요. MFC와 객체지향의 이야기를 해야 하는데 말이죠.

API는 Application Programming Interface를 의미합니다.

프로그래머들이 OS에 맞는 프로그램을 기계어 수준에서 컨트롤 할 필요 없도록,

OS 제작자들이 제공하는 인터페이스 셋이라고 볼 수 있습니다.

가끔 "리눅스는 시스템콜이고, 윈도우만 API라 부른다!"는 사람이 있는데요.

.....

리눅스 제작자인 토발즈 리누즈도 처음에 API라 했다는데요 뭐 -_-;

쌩까고 지나가자구요;

이 API는 C와 어셈블리를 기반으로 쓰여졌습니다.

정말 절차지향의 극치를 보여주는 구성이었지요.

물론 모듈화와 여러가지 과정을 거쳐서 객체형 코드로 변화하긴 했지만,

여전히 유지보수에 많은 어려움을 겪게 됩니다.

이에 따라 마이크로소프트는 대책을 강구하여, 객체지향에 맞도록 API를 묶(?)어버리는 촌극을 치룹니다.

비객체지향 언어인 C를 조금 발전시켜서, C++이라고 이름붙여 버리고는, API를 클래스화 시켜버린 것이죠.

이를 Microsoft Foundation Class라 부릅니다. 줄여서 MFC라고들 부르지요.

비주얼 스튜디오 6.0의 C++ 컴파일러에서는 MFC의 클래스들의 조상이 모두 같은 것이 아닙니다.

급하게 묶었으니 별 수 있나요 ㅡ,.ㅡ;

닷넷부터는 CObject클래스에서 모든 클래스가 파생되어 나오도록 바뀌었다고는 하지만,

너무 급하게 대충대충 묶었던 잔재가 아직 여전히 남아있습니다.

HWND(윈도우 핸들)을 인자로 요구하면서 HWND를 리턴하거나 알려주는 함수가 없어서

다시 API를 사용해서 찾아야 하는 촌극이 가끔 발생하지요. (말씀드렸듯, 닷넷에서는 많이 나아졌습니다.;;)

하.지.만.

마이크로소프트의 이 행동이 완전히 삽질만은 아니었습니다.

MFC는 API들을 객체지향적인 입장에서 해석해 묶어둔 터라,

조금 엉성해지긴 했어도 개발자들의 개발속도를 엄청나게 높여주었지요.

정말 객체지향에서 요구하는대로 "레고를 조립하는"수준의 프로그래밍을 하도록 해줬다고 해야 할까요?

--------------------------------------------------------------------------------------------------

왠지 모르게 요즘 점점 글빨이 안받습니다. ㄱ-;;;
posted by Lonewolf dlbo

댓글을 달아 주세요

2008.10.28 19:11 (비정기) Dlbo's Post

일상적인 생활 속에서도 객체지향을 만나 볼 수 있습니다.

(이 글은 픽션입니다 -_-)

----------------------------------------------------------------------------------------

컴퓨터공학과인 A군은 F학점을 면하기 위해 귀찮은 수업을 들으러 학교로 나섭니다.(-_-;;)

그리고는 하나의 객체를 마주하게 되지요.

사용자 삽입 이미지


자동차라는 객체. 아니, 자동차라는 클래스에서 '상속'된 경차 클래스의 객체중 하나입니다.

속성으로 제조사와 연식, 엔진의 배기량 및 여러가지가 있고...

현재 상태는 "과속"이네요.

A군은 한마디 내뱉고 갑니다. "니가 뭔 스포츠카냐."(-_-...)

그리고는 학교에 도착합니다.

사용자 삽입 이미지


완벽한 군용 건물처럼 견고하기 그지없는 학교 건물을 보며, 한숨을 쉬고 A군은 강의실로 향하지요.

그리고....

출석만 체크하고 슬그머니 빠져나옵니다.(-_-....)

지하철을 타고 집으로 돌아와 침대에 누워서 다시 달콤한 잠의 세계로....

------------------------------------------------------------------------------------

자. -_- 여기서 객체는 몇개나 나왔을까요?

......

놀라지 마시라. 셀 수 없이 많습니다.

사진에서만 해도 사진에 잘 안나온 개미부터 해서...(-_-...)

객체라는건 정말 간단합니다. 가운데 상속이라는 말이 나왔지요?

이는 객체의 '틀'인 클래스가, 서로 모양이 비슷할 경우 기능이 더 적은 클래스를 모방해 기능을 추가하는

방식을 말합니다. 부모로부터 유전자를 상속받은 자식이라 하더라도, 자식만의 고유 특성이

새로 생기지요? 그런 원리라고 보면 됩니다.

저~어기 학교를 가지고 객체지향적으로 분석해 보지요.

일단 저 학교는 "대학교"라는 클래스에서 생성된 "B대학"이라는 객체입니다.

그리고 이 "B대학"이라는 객체는 "입학, 수업, 졸업, 등록금 걷기"라는 기능을 가지고 있지요. -_-

기능만 가지고 있는 것이 아닙니다. 속성으로 대학의 이름과 주소, 전화번호 등을 가지고 있고,

"강의실", "학생", "교수", "식당", "도서관" 등의 객체를 가지고 있습니다.

이를 Has-A 관계(영어의 He has a book.에 has a와 같습니다.)라고 부릅니다.

저기 나오는 "강의실", "학생", "교수", "식당", "도서관" 등의 객체 또한 각자의 속성을 가지고 있고,

각자의 기능을 가지고 있습니다.

"강의실"객체의 경우 "방" 클래스에서 상속된 클래스로 만들어진 객체이며,

기능으로 "문열기", "문닫기", "불 켜기", "불 끄기" 등의 기능을 가지고 있습니다.

동시에 제한 학생 수, 칠판의 사이즈, 넓이 등의 속성을 가지고 있구요.

이는 학생, 교수, 도서관, 식당 등의 객체들 또한 자기만의 고유한 속성과 기능을 가지고 있음을 의미합니다.

여기에서 더 상세히 들어가면 밑도 끝도 없어요~ -_-;

------------------------------------------------------------------------------------------------

일상 속에서 보는 객체들, 참 쉽죠? -_-

하다못해 여러분이 두드리는 컴퓨터나 들이마시는 공기조차도 객체랍니다.
posted by Lonewolf dlbo

댓글을 달아 주세요

  1. 주체를 제외하면 결국 다 객체란 소린가..

  2. 응? 주체가 어찌 객체가 될 수 있는건지 설명 가능함?;;

    • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2008.10.31 23:05  Addr Edit/Del

      객체지향에서는 프로그램을 동작시키는 주체조차도 객체임. 객체끼리의 대화가 프로그램이고, 그게 세상이라는게 객체지향이다 ㅁ_ㅁ

  3. ..뭐 그런 샓뷁놝 한 .. 덕분에 견문을 한층 넓히고 간다 :D

2008.10.07 20:27 (비정기) Dlbo's Post
객체지향에 처음 입문하는 사람들에게 상당히 설명해주기 어려운 한가지.

-_-

클래스와 객체의 차이점입니다. -_-;;

----------------------------------------------------------------------------------------



으흠.

저 코드를 보면 클래스와 객체의 차이점을 볼 수 있습니다.

클래스는 "객체를 찍어내기 위한 틀"입니다 -_-!

수많은 객체지향 책들을 보면 참 난감하게 글들을 써놨습니다.

어떤 책은 "클래스는 곧 객체요, 클래스의 소통으로 이루어진게 객체지향형 프로그램이다."

또 어떤 책은 "클래스와 객체는 서로 다른 개념이며, 객체의 소통으로 프로그램이 구성된다."

또 어떤 책은 "클래스를 생성해 메모리에 상주시키고, 절차지향으로 조합하는게 객체지향이다."

또또 어떤건 "객체에 클래스를 포함 시킬 수 있고, 클래스에 객체를 넣어 프로그램을 만든다."

.........

뭔 개소링미 -_-?

객체지향 개념이 대두된지는 오래됐지만,

아직 객체지향이 이거다!! 하고 딱 집을만한 기준은 없습니다.

객체지향의 큰 틀인 "모듈간의 완전한 분리"만이 정확하게 정의되어 있지요.

그리하여 클래스와 객체의 차이점을 논하는건 어찌 보면 뻘-_-짓일지도 모릅니다.

하지만,

......

적어도 같은 저자가 쓴 책에서 클래스와 객체의 차이에 대해 다른 입장을 보인 책이 2권씩이나 있으면

좀 난감하지 않습니까?-_-?;;

잡설은 집어치우고,

일반적인 객체지향 프로그래밍에서는 클래스와 객체를 서로 다른 존재로 봅니다.

클래스는 객체를 분류하고, 기본형 FM을 생산하기 위한 하나의 틀이라고 봅니다.

객체는 클래스라는 틀을 통해 만들어낸 하나의 생산품이구요.

객체라는것도 상당히 추상적인 개념입니다만,

"클래스는 객체보다 더 추상적이고 존재하지 않는 형태에 대한 개념이다."라고 보시면 될 겁니다.

수많은 객체지향 책을 보면서 정리한 제 결론은 그냥 이렇습니다 -_-;

이렇게 생각해버리면 좀 더 편합니다.

클래스에 대한 변수를 선언하면, 그 변수가 객체가 되는 것이고,

고로 그냥 쌩 클래스로 뭔가를 하려 하면 컴파일러가 에러가 나니깐요.

이해하기 쉽지요?-_-?

---------------------------------------------------------------------------------------------

요즘 계속 잠을 제대로 못잤더니 시험기간이 다음주부터인데 몸이 아작났습니다 -_-;

작품전시회도 곧 있을텐데 API로 아날로그 시계나 하나 대충 해서 내던지 해야겠군요;

다들 몸조리 잘하시구요. 저처럼 끙끙대지 마세요~ -_-;
posted by Lonewolf dlbo

댓글을 달아 주세요

  1. Favicon of http://klone.tistory.com BlogIcon Mr.K 2008.10.07 22:13  Addr Edit/Del Reply

    .. 요즘 객체2와 자료구조를 배우고 있는 입장에서 얘기해보건대,


    배열과 List ADT를 대응시켰을 때 배열의 cell을 리스트에서는 node라고 하는 것처럼

    구조체와 Class를 대응시켜보면

    '클래스'라는 것은 단순히 변수와 클래스간의 메소드(함수)를 모아놓은 '구조체'이고,

    '객체'라는 것은 그런 클래스를 가지고 선언하게 되는 '구조체 변수'라고 생각하면 어떨지?

  2. Favicon of http://minsangk.com BlogIcon 민상k 2009.03.25 21:19  Addr Edit/Del Reply

    비얀스트라우스트럽(철자는 죽어도 기억 못할 이름;) 이 처음 C++ 에 객체지향 개념을 도입했을때 Object 와 Class 의 개념을 확실히 잡아주지 못했지요. 물론 그가 OOP 의 주창자라고는 할 수 없지만 확산에 선두에 섰던 사람으로서 그 부분을 명확히 집어주었다면 좋았겠단 생각이 들더군요.

    학교에서 객체지향을 가르치는 몇몇 교수님들은 아직도 Object 와 Class 는 동일하다고 설명하십니다. Class 와 Instance 의 차이를 설명하기도 바쁜데 그 와중에 Object 까지는 무리다- 라고 생각하신듯 했지만 (또 그런 느낌을 상당히 받았지만-) 단순히 여러 사람들이 많이 쓰고 있다는 이유로 배우고 있는 한 언어의 syntax 보다는 좀 더 거시적인 시각의 접근으로 설명했으면 어땠을까 하는 아쉬움이 들었지요.


    어쨌거나 현재의 관점으로 볼 때 C++ 은 객체지향언어라고 하기에 무리가 따를 만큼 OOP 의 방법론이 구체화 되고 분명해진 것은 사실입니다. 원래 만든 사람보다는 보고 배우고 쓰는 사람들이 이름 짓기를 잘하니까 그렇겠죠? ㅋ

    • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2009.03.25 21:36  Addr Edit/Del

      비얀의 -_-ㅋ 빨간책 시리즈 집에 아직도 고이 모셔두고 한번씩 힐끔힐끔 봅니다만 ㅋㅋ
      객체지향이 뭔지 정말 대충 제껴버리는 대학 수업도 정말 문제 있는것 같습니다. 저도 객체지향 수업 하나 듣다 그냥 그 과목 학점을 접었지요 ㄱ-

  3. Favicon of http://minsangk.tistory.com BlogIcon 민상k 2009.03.25 21:42  Addr Edit/Del Reply

    제대하고보니 1학기에 몰아배우던 객체지향을 두학기에 쪼개 학과교양필수로 만들어놓았더군요. 그래서 떄아닌 객체 수업을 지난 학기 들었습니다. 교수 수업은 짜증나서 듣다말다 했고, 실습은 조교 디버깅 해주느라 바빴으며, 중간기말퀴즈까지 뭐 하나 빠진 거 없이 완벽했는데. 귀찮아서 실습 몇번 빠졌더니 A0 받았습니다. 학번 높으면 점수를 까더군요 -_- 누가 높고 싶어 높나-_-

2008.09.30 20:45 (비정기) Dlbo's Post

객체란 뭐....

별거 아니구요.

"데이터를 중심으로 무언가 행동을 하는 주체" 입니다.

기존의 절차지향에서는 "데이터"란 단지 "다뤄야 할 대상"이었지만,

객체지향에서는 "객체"가 "데이터"를 가지고 있고, "주체적으로 다른 객체와 대화하는" 형태입니다.

이 객체들간의 대화나 상호 작용이 프로그램이 된다고 전 포스트에 써두었지요?

사용자 삽입 이미지
인간이라는 객체의 형상화입니다. (원래 포토샵으로 해두었으나 날라갔습니다. 죄송 ㄱ-;)

인간은 "이름, 성별, 키, 몸무게, 나이"라는 데이터를 가지고 있고, "말하기"라는 동작을 통해 자신의

데이터를 다른 인간객체에게 알려주거나, 다른 인간객체의 데이터를 수집합니다.

그리고 다른 인간객체와의 상호작용을 통해 "때리"거나, "걷어차"거나....

.......

예시가 좀 격한가요?

-_-;

뭐. 가장 예시를 들기 편하더군요 -_-;

아래는 "싸운다"라는 프로그램의 형상도입니다.
사용자 삽입 이미지

으흠.

간단하지요?-_-;

컴퓨터 세상이라 한다면, 이 객체가 인간을 지칭하지 않고, 컴퓨터와 컴퓨터,

프로그램과 프로그램, 변수와 변수처럼 서로 동등한 수준의 관계는 물론이고

컴퓨터와 유저, 변수와 프로그램처럼 서로 크거나 작은 관계로도 나타낼 수 있답니다.

------------------------------------------------------------------------------------------------

오늘의 결론.

"객체는 스스로 활동하는 데이터다." 라는 간단한 내용.
posted by Lonewolf dlbo

댓글을 달아 주세요

  1. 제길슨 ㄱ- 다음부터는 포토샵으로 똑바로 그려두겠습니다 -_-;

  2. leo 2009.02.13 12:47  Addr Edit/Del Reply

    덕분에 객체 이야기가 이해하기 쉬워지고 있습니다. 다들 이렇게 쉬운걸 어렵게 표현해주셔서 아주 젠장이었다는 결론이 있었습니다. 감사합니다.

    • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2009.02.14 11:03  Addr Edit/Del

      다들 '뭔가 있어보이려고' 어렵게 말하고 쓰고 그러는게 다 그렇죠 뭐... ㅡ,.ㅡ; 대학 강의에서도 분명 아는 내용인데 뭔 소린지 이해하기 힘든 경우가 꽤 있더군요 ㅋㅋ

2008.09.23 21:49 (비정기) Dlbo's Post

갑작스레 시작하는 객체지향 이야기.

그것도 시리즈물 이에요 -_-;

---------------------------------------------------------------------------------------------------

처음 프로그래밍이 탄생한 순간, 기계에 천공카드를 원하는 규칙에 맞춰 뚫어서 넣어 컴퓨터를 가동하던 그 때.

무식하게 느린 컴퓨터이지만 복잡하고 귀찮은 계산들을 손쉽게 처리해 주었기에, 수많은 사람들이 열심히

천공카드에 하나 하나 구멍을 뿅 뿅 뚫어가며 프로그램을 만들었습니다.

이 후, 기계어 단위로 0, 1을 직접 우겨넣다 못해, 어셈블리 언어가 생겼지요. 정말 단순했습니다.

그냥 순서대로 컴퓨터가 해야 할 일을 프로그래머가 알아먹을 수 있도록 기계어와 1 : 1로 매칭시켰으니깐요.

기계코드로 0, 1을 일일이 우겨넣던 옛날과는 많이 달랐습니다. 알아 보기가 매우 쉬워졌고,

프로그램을 만드는 시간이 상당히 빨라졌지요.

설사 코드에서 틀린 부분이 있더라도, 예전보다 손쉽게 고칠 수 있었습니다.

이 어셈블리어가 더 간결해지고, 사용하기 쉽게 변해가면서 자주 사용하는 라이브러리 등을 합쳐 놓은 것이

바로 C언어. 시스템을 강력하게 컨트롤 할 수 있으면서도 다루기 쉬운 언어였지요.

자. 여기까지가 바로 절차지향 언어의 역사입니다.

위의 언어들은 "시작과 끝은 하나, 여러 조건과 상태의 분기에 따라 다른 가지를 타고 흐를 뿐".

이라는 공통점을 가지고 있습니다.

순차적으로 하나 하나 처리되는 형식이 되어, 데이터는 하나의 "취급 대상"일 뿐이었고,

그로 인해 코드 또한 점점 엽기적으로 변해갑니다.

마치 구멍난 독에 반창고 바르듯, 원천적 구조 변형 보다는 필요한 부분만 조금 조금 고쳐나가는

사람들이 생겨나고, 그로 인해 아래 사진처럼 언밸런(-_-?)스한 상황이 벌어지지요.

사용자 삽입 이미지


.....

저거야 잘 만들어 졌으니 그렇다 칩시다.

-_-;;

사용자 삽입 이미지

......

많이 언밸런스 하지요?;;;

이런 프로그래머들의 "귀차니즘"에 의해, "자주 쓰는 부분들은 따로 모아놓자!"라는 의견이

내세워집니다.

이리 하여 "모듈화" 라는 방식으로, 자주 쓰는 라이브러리 아닌 개인 라이브러리들(-_-?)을 따로 묶어놓고

DLL 등으로 끌어 쓰거나 함수를 잘게 잘게 쪼개버리는 시도가 성행합니다.

그.러.나.

사용자 삽입 이미지

티코에다 람보르기니 마크 붙여도 티코는 티코입니다 -_-;

결국 프로그래머들은 "객체"를 만들어서, 메모리상에 둥~둥~ 띄워두고,

객체 간의 상호 작용으로 원하는 데이터를 얻자! 라고 합니다.

이 객체는 "데이터"를 중심으로 "데이터"가 뭔가를 "하는" 것으로 다른 객체들과 소통합니다.

혹은 그 자체로서 들어온 인풋에 따라 아웃풋을 내 뱉지요.

이런 방식을 채택함으로써 프로그램에 문제가 생길 경우 문제가 있는 객체만 고치면 되므로,

완전히 환골탈태 한 것이지요.

자. 참 쉽죠?-_-?

--------------------------------------------------------------------------------------------------

오늘의 결론. "객체지향"은 프로그래머들의 "귀차니즘"에서 생겨났습니다. -_-
posted by Lonewolf dlbo

댓글을 달아 주세요

  1. Favicon of http://studyinglw.tistory.com BlogIcon Reuent 2008.09.23 22:33  Addr Edit/Del Reply

    '개인' 라이브러리 라기 보단 '사용자 정의' 라이브러리라는 표현이 낫지 않았을까? -_-?;

  2. Favicon of http://klone.tistory.com BlogIcon Mr.K 2008.09.24 09:14  Addr Edit/Del Reply

    .. 이 글 보러 들어오는 사람은 죄다 저 혐짤을 보겠군 -_-;;

  3. 우웃, 내용을 읽다가 사진보고 화들짝...ㅎ 람보르기니 마크를 붙이는 순간 티코는 레벨 업한거야~

  4. Favicon of http://afeleia.tistory.com BlogIcon Afeleia 2008.11.07 10:29  Addr Edit/Del Reply

    재밌으면서도 쉽게 표현이 되있네요 ^^ 잘보고 갑니다.

prev 1 next