Object Oriented Programming

객체 지향 프로그래밍.

OOP의 어머니 격인 Smalltalk를 1972년에 만든 Alan Kay는 생물의 세포에서 OOP의 힌트를 얻었다고 한다. see also http://ootips.org/history.html (흥미롭게도, OOP의 정수라고 할 수 있는 DesignPatterns는 건축가 ChristopherAlexander의 사상에서 힌트를 얻은 것이다.)

최초의 OOP는 Ole-Johan Dahl과 Kristen Nygaard에 의해 만들어진 SIMULA67라고 공식적으로 알려져 있는데 나름대로 논란의 여지가 있다. 어찌되었건 OOP의 역사는 약 30년을 넘고 있다.

아직도 이러한 OOP의 발전과 성과를 도입하지 못한 곳도 많은데, 현재 활발히 논의되고 있는 OOP의 대안으로는 Component Base Development, AspectOrientedProgramming, Intentional Programming, Subject Oriented Programming, Multi Paradigm Programming, Generic Programming 등이 있다(배타적 분류는 아님).

OOP의 아버지

Ole-Johan Dahl과 Kristen Nygaard는 OOP의 아버지로 불리운다. 그 공로로 2001년에 두 사람 모두 TuringAward를 수상했다. 공교롭게도 Dahl은 2002년 6월에, Nygaard는 2002년 8월에 작고했다.

[edit]

1. 객체지향 프로그래밍에 대한 토론 ¶

객체지향의 장점은 많은 사람들이 잘 알지만, 정말 그렇게 프로그래밍하고 있는지는 모두가 한번 되돌려봐야 할듯. 실제로 많은 사람들이 그 좋다는 재사용성을 COPY and PASTE로 해결하고 있지는 않나요?? 오히려 중요한것은 프로그래밍이 아니라 OOAD 에 있다고 봅니다. --아무개

객체지향의 단점 한가지. 클래스안에 클래스의 속성(데이터)와 행위(함수)가 함께 묶여 있다는 점. 클래스는 데이터와 함수를 꽉 붙잡고 있어서 다른 클래스에서 필요한 부분만 가져다 쓸 수 없다. 상속이나 인스턴스화 하지 않는한... --아무개

그건 ObjectOrientedProgramming의 단점이 아니라 장점 아닌가요? --퍼키

데이터와 함수를 꽉 붙잡고 있을 수 있다는 점이 OO의 장점 중 하나(캡슐화:Encapsulation)입니다. A 클래스에서 필요할만한 부분을 B 클래스에서 가지고 있다는 것은 B 클래스의 응집도가 낮다는 뜻인데(A의 입장에서 보자면 FeatureEnvy smell), 이러한 경우에는 그 A, B 클래스를 합치거나 B 클래스를 분리해서 두 개의 클래스로 나눌 수 있습니다. 상속(구현상속)이나 인스턴스화(아마도 컴포지션을 말씀하시는 듯) 역시 OO에서 코드를 재활용하기 위해 쓰이는 방법들입니다. --아무개

객체지향을 적용하는 것이 상황에 따라 장점이 될수도 있고 단점이 될 수도 있겠죠. 객체지향을 쓰는 것이 이득이 될 경우에만 사용하면 되겠죠. 객체지향이 방해가 되는 경우는 아직까지 겪어 본적이 없네요. 구체적으로 어떤 경우에 그런가요? --응주

부언하자면, 최근에도 간혹 객체라는 것은 자료(data)와 함수(function, behavior)의 묶음이다는 식의 설명을 볼 수 있는데, 이는 80년대에 한창 유행했던 상당히 제한적인, 구현(implementation) 중심적인 객체 개념입니다(분석할 때 명사와 동사를 중심으로 객체를 추출하는 방법도 같은 한계를 갖고 있죠). 요즘은 좀 새로운 시각에서 보고 있습니다. 보통 "Things with responsibilities"라는 정의를 합니다. OOSC에서 Meyer같은 사람은 "a set of responsibilities"라고 합니다. --김창준

예를 들어 설명하면.

강의시간에 들은 설명이다. 평소 어떻게 객체지향에 대해서 설명을 할까 생각했었는데, 좋은 예라고 생각하는데 기억을 더듬어 쓰는거라... --Dennis

컨퍼런스 장소이다. 연사와 청중들이 있다. 한 섹션이 끝났다. 참가자 들은 각자 신청한 다음 섹션으로 이동해야 하는데, 그들은 다음 섹션의 제목만 알지 장소는 모르며 연사는 각 섹션에 대한 장소를 알고 있다. 어떻게 장소를 각각의 사람들에게 알려줄것인가?

절차중심 : 연사는 청중을 한사람씩 부른다. 연사: "다음 섹션 뭐 들어요?" 청중1: "Database요" 연사: "Database는 ... Room 3오!", 다음사람... "다음 섹션 뭐 들어요?" 청중2: "Network이오" 연사: "Network는 ... Room 1오!" ...
객체지향 : 연사는 각 섹션에 대한 장소가 적힌 테이블을 벽에 붙이고, "여기에 각 섹션에 따른 방번호가 있소!", 사람들이 테이블을 본다. 청중1: "내가 Database지... 아하 3번방이군", 청중2: ...

그렇다. 다음 강의실을 알아야 하는것은 연사의 책임이 아니라 청중의 책임인것이다. 이 예에서는 청중, 연사, 테이블등의 객체가 존재하며, 각 객체는 자신들의 책임을 가지게 되는데 이들은 크게 알아야하는것(Knowing Responsibility, 다음 섹션의 제목등...), 해야하는것(Doing Responsibility, 테이블을 본다, 이동한다, 듣는다, 등...)으로 나뉘게 된다. 자신이 알고 있는것들(다음 섹션의 종류, 장소등...)은 다른 사람에게 말해주지 않는한 다른 사람에게 알려지지 않으며, 그럴 필요도 별로 없다. Encapsulation

청중은 같은 책임을 공유하게 되므로, 이를 Class라는 개념으로 묶기도 한다.

그런데 청중중에 대학원생들은 섹션이 끝난후 설문지를 청중들에게서 받아 사무실에 넘겨줄 의무가있다.

절차중심 : 연사는 청중을 한사람씩 부른다. 연사: "다음 섹션 뭐 들어요?" 청중1: "Database요" 연사: "Database는 ... Room 3오! 그런데 당신 대학원 생이오?" 청중1: "아니오" 연사: "다음장소로 이동하시오", 다음사람... "다음 섹션 뭐 들어요?" 청중2: "Network이오" 연사: "Network는 ... Room 1오! 그런데 당신 대학원 생이오?" 청중2: "그렇소" 연사: "설문지를 취합해서 사무실에 넘겨주고 다음장소로 이동하시오" ...
객체지향 : 연사는 각 섹션에 대한 장소가 적힌 테이블을 벽에 붙이고, "여기에 각 섹션에 따른 방번호가 있소!", 사람들이 테이블을 본다. 청중1: "내가 Database지... 아하 3번방이군 3번방으로 이동해야지", 청중2: "내가 Network이군. 아하 1번방이군. 설문지를 취합해서 사무실에 전해준다음 1번방으로 이동해야겠다." ...

연사는 각각의 청중들이 대학원생인지 알 필요가 없다. 강의가 끝난후 대학원생이라면 설문지를 취합하는 일을 할것이다. 이와같이 각자의 상황에따라 청중들은 약간씩 다른 행동을한다. Polymorphism
그런데 대학원생또한 청중이다. 즉 모든 대학원생은 청중이 가지는 모든 책임을 공유한다. Inheritance

저는 개인적으로 OOAD에 유용한 점이 많다고 생각합니다. 하지만 저는 머리가 그다지 좋지 못해서 현실을 관찰, 분석하는 것을 오랫 동안 하고 거기서 그리 좋은 결과를 얻지 못합니다. 그래서 저는 FastFeedback과 IncrementalDevelopment에 의존합니다. 어차피 머리 속의 관념이 언젠가는 컴퓨터가 이해하는 말로 옮겨져야 할 것이고, 번역의 과정에서 상당한 제한이 가해질 것이라면 더더욱 그렇습니다. 저는 컴퓨터로 문제를 해결하는 것에 관한 한, 컴퓨터로부터 떨어진 순수한 사변적 사고에 큰 믿음이 없습니다.

80년대 후반과 90년대 초기, OO기법에 이런 선전 문구가 많았습니다. "현실을 그대로 모델링 하기만 하면 된다.", "문제공간(problem space)에서 해결공간(solution space)으로의 전환이 필요없다.", "객체는 이미 거기(problem world에) 있다. 단지 고르기만 하면 된다." 지금 와서는 "자연언어가 프로그래밍 언어를 대신할 것이다"는 말 정도 밖에는 평가받고 있지 않지만 -- 야망이 너무 컸습니다.

분명 도메인의 어휘를 고대로 사용하는 데에서 얻는 이득이 있긴 합니다. 하지만 그것이 반드시 총수익에서 플러스가 되지만은 않았습니다. 게다가 객체적 사고방식은 많은 한계를 갖고 있습니다. 세상은 OO적이지 않습니다. 아니, 그렇기엔 너무도 비효율적입니다.

너무 자주 인용되어서 식상해진 느낌까지 드는 Steve Cook과 John Daniels의 인용구가 이 점을 재미있게 지적하고 있습니다.

{{|
...in summer lots of birds will start to sing around sunrise... Does the sun send a message to all of the birds individually? If so, in what order? ... These are silly questions, because they are questions about software execution, not the sunrise.
여름에 해가 뜰 때에면 많은 새들이 노래하기 시작한다. 그렇다면 태양이 모든 새들에게 각각 메시지를 보낼까? 만약 그렇다면 어떻게? 바보같은 질문이다. 그것은 소프트웨어가 동작하는 원리지, 세상이 돌아가는 원리가 아니다.
|}}

문제공간을 OO적으로 인식하는 순간 우리는 이미 한 쪽으로 전환을 혹은 왜곡을 하고 있습니다.

JSD, JSP로 유명한 요구사항 분석의 대가 마이클 잭슨은 다음과 같이 말합니다.

{{|
In many developments, important parts, aspects and properties of the problem world simply do not fit at all well into the straitjacket of an object-oriented view. Inevitably, those parts would be ignored, or treated only in a distorted way. The result is that many descriptions that ought to be about the world, and are offered by their makers as descriptions of the world, are really about the computer and its software and, especially, about its database and iternal object structure.
|}}

--김창준

"저는 컴퓨터로 문제를 해결하는 것에 관한 한 컴퓨터로부터 떨어진 순수한 사변적 사고에 큰 믿음이 없습니다." 동의합니다.(이런 표현은 정말 어떻게 해야하는 건지, 동의를 하고 싶으나 내가 동의하고 말고 하는 게 그리 대수로운 건 분명 아닌데, 글쓰기어려움의 한단면입니다.) 어떤 접근방법에 대해 믿음의 수준까지 도달할 필요는 없을 것이고 또한 "컴퓨터로 푸는 문제"란 전제는 참으로 현실적고 현명한 지적입니다. 그렇다면, 객체를 이해하기 위해 삶에 의존하자던 제 생각에 대한 변명도 해야 합니다. "컴퓨터로 문제를 해결 하고자 하는 것, 그것은 삶의 문제입니다." 현존하는 많은 개발방법론들이 인간의 삶의 문제와 별개인 것들은 없을 것이고 또한 그 모든 아이디어들은 모두 사변적인 것으로부터 얻지 않았나 생각합니다.

"세상이 OO적이지 않다."는 것에 대해서는 아직은 잘 모르겠습니다. 어쩌면 이에 관해 영원한 바보가 되어버릴지도 모른다는 불길한 생각도 듭니다. '객체' 지속성이 있는 모든 존재. '행동' 지속성이 없는 모든 과정. 이렇게 두고 보면 설명 안되는 게 없어 보이는데, 행동을 따로 정의할 필요가 없다고 지적하셔서, 저는 계속적으로 뭔가 맴돌기를 하게 됩니다. 세상을 통틀어 하나의 객체로 봐 준다면 어떻게 되나? 역시 바보 재 확인하는 소리. 뭔가 벗어 던져야 할 아주 두꺼운 껍질을 뒤집어 쓰고 있는 듯 너무도 답답한 느낌인데, 제가 가진 그 껍질이 도대체 뭔가요? (역시 사변이란 것이 제게도 별 도움이 못되는군요.) 행동이 있음으로 해서 감정이란 것이 생기는 것인데, 컴퓨터를 사용할 때는 더욱이 '만족'이라는 감정을 목표로 접근하는 것이니, 아무리 생각해도 그것에서 벗어나지지가 않습니다. 우리 모두는 객체지향적방법론이든 뭐든 객체 혹은 데이타 그 자체보다는 그로 인해 유발되는 행동에 대한 기대를 하는 게 아닐까 합니다. "바보"를 기대하는 게 아니라 "바보 도 트이는 소리"를 기대하는 것이지요. 흔히 말하는 "참을 수 없는 존재의 가벼움" 이란 것도 같은 맥락에서 파악된다고 생각됩니다. 존재 그 자체에 대한 한탄이 아니라 "할 일 없음"으로부터 오는 절망이 아닐까 하는.

"OO기법에 대한 선전문구" 말입니다. 그 선전문구에 현혹된 사람은 아직까지는 한명도 보지 못했습니다. 제 견문이 좁은 탓도 있긴 하지만요. 객체지향적방법에서 객체는 분명 목적도 아니고, 객체를 잘 뽑아서 컴퓨터에 잘 옮겨뒀다고 해서 문제가 풀리는 것은 아닌 건 분명하지 않습니까. 모델링이란 건 어차피 "현실의 문제를 풀기 위해서는 현실의 문제를 최대한 현실적으로 컴퓨터에 옮겨 놓자." 라는 것 아닌가 합니다. 문제를 컴퓨터로 옮겨놨을 뿐이지 아직 풀지는 않았습니다. 그 다음에 직접적으로 문제를 풀어야지요. '현실'과 '객관'을 구분해서 쓰고 있습니다. 어떤 방법이 한계를 가지고 있는 것에 대해 그 한계를 그렇게 심각하게 바라보지 않습니다. 어차피, 인간은 객관을 획득할 수 없다고 봅니다. "가장 현실적으로" 라는 말은 인간의 입장에서 "가장 주관적으로"일 가능성이 높다고 봅니다. 아무튼, 한계가 발견되었으면 다른 방법을 찾으면 될 것입니다. 한계가 있든 없든 어떻게든 문제를 컴퓨터 속으로 가져가야 하는 것만은 분명합니다. 모델링이란 것은 그 정도 선에서 봐주면 되지 않나 생각합니다.

"문제공간을 객체지향적으로 인식하는 순간 이미 왜곡하고 있다." 는 지적도 충분히 그럴 수 있다는 생각입니다. 그러나, "정말 왜곡 했는가." 라는 되물음에 정확히 대답하려면 "인간은 객관적일 수 있는가"하는 문제부터 풀어야 하지 않을까 생각합니다. '한계'를 인정하는 것과 '왜곡'을 주장하는 것은 어감부터가 다릅니다. 항시 "답 없음"이 답이고 "답 있음"이 답이었던 것 아닌가 생각합니다. 답이 없으니 영원히 답을 찾아 헤맬 수 밖에 없고, 답이 있으니 영원히 답을 찾아 헤매는 것이 아닌지. (궤변일까, 진실일까)

분명한 것은 한가지 옷이 모든 사람에게 잘 어울릴 수는 없는 노릇 아닌가 하는 것입니다. 또한 전 객체지향 옹호자가 아닙니다. 그런 방법이 있다는 데 그것을 제대로 알아 보고 싶었을 뿐이었이구요, 이리저리 대 보았을 때 옷이 안맞으면 찢어버릴 것이 아니라 그 옷을 안입으면 됩니다. 그 옷은 다른 사람에게는 맞을 수도 있으니까요. 또한 우리는 불편할 때 "그 옷의 불편함을 지적하고"(찢어버리는 것과는 다릅니다.) 언제라도 다른 옷으로 갈아입을 수 있습니다. 그러나, 갈아입을 옷이 없다면 상당히 부끄럽고 또한 겨울이 되면 굉장히 추울 것 같습니다. 불편하다고 투정을 부릴지언정 입고 있을 옷이 있다는 것, 얼마나 고마운 일인가요.

백가지 방법 중에서 자신에게 혹은 그룹에게 가장 잘 어울리는 방법을 선택하여 최단시간에 최대만족을 얻어내는 것이 최저비용이 아닐까 생각합니다.

(삶은 계란) --bullsajo

평면. 대부분의 학문 영역에서는 현실을 모두 평면화 하는 것 같아요. 그림을 통한 이해란 것도 역시 마찬가지. 현실을 모두 판대기에 늘어 놓는 겁니다. 수학도 논리를 수식이라는 형태로 평면화를 시도합니다. 그러니 물리는 어쩔 수 없는 노릇이고. 사학은 연대표로 역시 평면화를 시도하지요. 전산학은 납작한 코드란 형태로 역시 평면화합니다. 토목에서는 하중이란 중요한 부분을 시뮬레이션이란 방법을 쓰기 보다는 역시 수학공식을 통한 논리식의 해답찾기에 손이 먼저 갑니다. 건축에서는 제도와 모형이란 방법을 쓰는 것 같던데, 모형이란 걸 만들기 위해 또 평면에 제도를 해야 하네요. 음악이라는 예술분야는 또 오선지라는 판대기를 사용하지요. 개발방법론을 이해하고 연구하는 데도 마찬가지인 것 같아요. 이것을 보나 저것을 보나 구구절절한 기술들도 그것들의 내막을 힘겹게 읽었을 때, 나름대로의 이해 결과물은 또 결국 "평면 도해"로 남게 됩니다. 왜 그런 것인가를 "참으로" 많이 생각하게 됩니다. "

"그럴 수 밖에 없음이 현실일 수도 있겠지만, 그럴 수 밖에 없기 때문일까."

우리는 지구의 지도 역시도 판대기에 그립니다. 지구는 평판이 아닌데. 우리는 그 지도 말고 지구본이란 것도 가지고 있습니다. 지구본이 지구의 울퉁불퉁함과 바다속, 지구 내부까지 다를 표현해 주지는 못하겠지만 부족한 대로 평면을 벗어난 모델인 것은 사실이고 선택의 여지는 분명히 있는 것이지요. 그러나 '지금까지 기나 긴 논의를 했는데, 그 일을 하려면 우린 아프리카로 가야해. 누가 지도 좀 가져와 봐" 이런 대화가 오갔을 때, 절대 다수는 "평면지도"를 내 놓지 "지구본"을 내 놓는 사람들은 극히 드물죠.

어떤 학문분야를 불문하고 이러한 평면적 표현법은 감추어진 많은 것들을 그런대로 어떻게든 모두 나열해 보고자 피나는 노력을 해 보나, 모두 담아내기에는 역부족일 것이 사실입니다. 그것이 가능한 일이기나 할까요. 평면에다. 가장 먼저는 지면상의 문제도 걸리겠고.

"현실을 평면화시키는 이유는 도대체 무엇이며, 그럴 수 밖에 없는 것인가."

이러한 의문을 늘 달고 다닙니다.

(병든 꼬꼬) --bullsajo

bullsajo님께서 평면화라고 하시는 건 제가 알고 있는 모델링이란 말과 동인한 뜻인 것 같군요. 맞나요? 모델링이란 걸 하는 이유는 복잡한 대상을 가능한한 단순하게 만들어서 분석하여 그 결과를 이용할려고 하는 것입니다. 모델링이라는 걸 하는 이유 자체가 대상의 모든 특성을 반영하는 것이 아닙니다. UML을 설명하는 책 같은데 보면 각 장마다 똑같이 나오는 얘기가 있습니다. 중요한 모든 부분을 모두 표현하고 중요하지 않은 부분은 표현되지 않게 말은 쉽지만 실제로 하기는 엄청 어렵죠.

중요하다고 생각하는 것이 무엇인가에 따라 똑같은 대상을 모델링하더라도 결과는 판이하게 다를 수 있습니다. 평면지도는 평면지도가 나타내고자 하는 지구의 모델을 표현하고 있고 지구본도 지구본이 나타내고자 하는 지구의 모델을 나타내고 있습니다. 항상 지구본이 좋은 모델도 아니고 항상 평면지도가 좋은 모델도 아닙니다. 역사 연대표 같은 것도 역사의 일부분을 시간의 순서에 따라 역사를 표현한 모델 뿐입니다. 역사책에는 연대표 외에도 많은 모델들이 있습니다. 다른 분야도 마찬가지겠죠. UML 같은 것에서도 소프트웨어를 모델링하기 위해서 여러가지 표현수단을 제공하고 각 표현수단마다 부각시키고자 하는 부분이 다릅니다. 즉 현실을 하나의 평면(모델)만으로 나타내지는 않는 다는 겁니다.

모델링한 결과물들은 도대체 왜 대부분 평면(2차원)에 표현되는가라고 물으신다면 현재까지는 가장 좋은(현실적으로 유용한) 표현의 전달수단이 대부분 평면이기 때문이지 않을까요? 종이도 평면이고 모니터도 평면이고.

RonJeffries는 기계어 프로그래밍 시절에 이미 OOP로 작성을 했다고 합니다. --아무개

그 예제가 있으면 아주 흥미있지 않을까 한다. 좋은 학습자료가 되지 않을까? --아무개

예전.. 한 93~4년경의 마소에 보면 터보 어셈블러로 OOP하는게 나와있었던 기억이 나네요. 어셈이나 기계어까지는 아니라도 GTK에서 쓰이는 [http]

GObject는 C로 object system 같은 걸 만들어서 잘 쓰고 있습니다. 쉽고 어려움의 차이는 있겠지만 OOP는 어떤 언어에서도 할 수 있습니다. XP같이 방법론이라면 더욱 더 개발언어에 대한 의존도가 낮아지겠죠. --아무개

저도 93~4년 경에 성안당 혹은 인포북에서 나온 "매크로어셈블러바이블"이라는 제목의 파란책에서 MASM으로 OOP를 하는 예제를 본 기억이 납니다. RobertCecilMartin도 AgileSoftwareDevelopment에서 "It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design"이라는 말을 했습니다. --아무개

[edit]