C로 클래스 흉내낼 수 있나여?

class TestClass
{
 public:
    int badMember;
    void test(int x) {...}
};
int main()
{
    TestClass testClass;
    testClass.test(3);
}

...
struct TestStruct
{
    int badMember;
    void (*test)(TestStruct*, int);  
};
void TestStruct_test(TestStruct*, int x) {}...

int main()
{
    TestStruct testStruct;
    testStruct.test = &TestStruct_test;
    testStruct.test(&testStruct, 3);  // or TestStruct_test(&testStruct, 3);
}

encapsulation은 대강 다음과 같이 할 수 있습니다.

/* in header */
struct PrivateInterface;

struct PublicInterface
{
    PrivateInterface* privateDataOrFunction;
    int publicData;
}

/* in code */
struct PrivateInteface
{
    ....
}

C++ 소스

class Person {
 int age;
public:
 void setAge(const int age);
 int getAGe() const;
};

이걸 C로 구현하면 아래와 같습니다.

#include <stdio.h>

struct Person {
 int age;
 void (*setAge)(struct Person * this, const int age);
 int (*getAge)(const struct Person * this);
};

void Person_setAge(struct Person * this, const int age)
{
  this->age = age;
}

int Person_getAge(const struct Person * this)
{
 return this->age;
}

void Person_init(struct Person * this)
{
 this->setAge = Person_setAge;
 this->getAge = Person_getAge;
}

void Person_destroy(struct Person * this)
{
}

int main()
{
 struct Person minsu;

 /* 생성자 호출 */
 Person_init(&minsu);

 minsu.setAge(&minsu, 10);
 printf("%d\n", minsu.getAge(&minsu));

 /* 소멸자 호출 */
 Person_destroy(&minsu);
 return 0;
}

this는 인자로 들어가죠.

Person * this 말씀이신가요?
struct Person * this 로 바꿨습니다.^^

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

정확하게 <결합>이란 의미를 설명하자면 프로그래머가 function과 그 대상인 데이타를 하나의 자료구조(그것이 structure든 class든 간에)로 인식될 수 있어야 한다는 말입니다.

실제로 class든 structure든 data와 method는 process 내부 공간안에 존재하기 때문에 process 내부 메모리에 같이 존재한다는 의미에서는 동일한 메모리에 위치한다고도 할 수 있습니다.

하나 그 동일한 메모리 공간에 위치한다는 말씀이 class에서 보여지는 것처럼 바로 인접한 메모리에 method와 data가 존재한다는 의미로 오해할 수 있는 소지가 충분히 있습니다.

데이타와 코드 모두 동일한 메모리 공간에 저장되어 있다고 하셨지만 제가 말하고자 했던 것은 실제 메모리상에서 활성화된 process 단위에서 데이타와 코드가 class에서 보여지는 것처럼 실제로 인접하고 있느냐 하는 점을 말씀드린 것입니다.

가령 structure 안의 pointer to function과 data들이 인접주소에 있을 수 있겠지만 pointer to function이 가리키고 있는 function과 data가 인접공간에 즉, 0001 0002 0003 0004 이런식으로 저장되어 있다면 그것은 사실이 아닙니다.

또한 일반적으로는 객체지향을 C++로 구현하는 것이 C로 구현하는 것보다 OO를 <더 쉽게!> code상에 구현하는 것은 맞지만 그렇다고 C로 구현한 OO가 모두 불완전하다고 단정하는 것도 또한 무리입니다.

그렇게 말씀하신다면 C로 매우 우아하게 객체지향을 구사해놓은 linux kernel의 설계자들은 안하니만 못한 코딩을 하는 저급 코더로 전락할 수 밖에 없겠지요.

의문이 있습니다. C++의 객체지향은 Objective C에 비해 미흡합니다. 그럼 객체지향을 할 때는 C++을 쓰지 말아야 할까요? 아니면 객체지향에 더 적합한 언어로 바꾸어야 할까요?

C 언어로 시도한 객체지향이 C언어로 짠 다른 코드에 비해서 복잡도가 낮아지거나 추상화가 될 수 있다면 안할 이유가 없지 않느냐 생각합니다.

C 뿐 아니라, Perl에 구현된 개체지향의 개념도 잘 보면 C와 유사합니다.
오히려 Perl이 초기에 개체를 지원하지 않다가 구겨(?)들어가면서 고민하는 것들이
C의 개체지향적인 코딩과 다르지 않다는 것을 알 수 있습니다.

초창기 JavaScript에서 클래스 만드는 것도 생성자라는 것이
그저 함수안에서 this를 가지고 변수를 만드는 것으로 가능한 것도
처음엔 쉽지않은 개념이지만 생성자도 단지 함수에 불과하다는 생각을 심기에 충분하고요,

python에서도 클래스 지원은 self가 반드시 들어가야되 것으로 보면,
언어에서 고민하는 흔적이 대부분 비슷하다는 것을 알 수 있습니다.

이렇게 따지면, 본쉘 스크립트에서도 비슷한 것을 만들수 있겠거니! 하는 오버도 하고.
10년쯤된 마소의 안철수님의 개체지향적인 어셈블프로그래밍 기사도 비슷한 고민들입니다.

C언어를 써서 객체지향적인 코드가 C언어로 짠 절차지향적인 코드보다 복잡도가 낮아지거나 추상화가 된다면이라는 의도로 말한 것 입니다.

개발 방법론으로 인한 비용 상쇄 보다는 개발 인력의 수준에 따른
비용 감쇄가 오히려 더 큰 위험 요소죠.

어떤 개발 방법론을 따르냐 보다는 개발시 어떻게 잘 협력이 이루어지고
개발자들 사이에 통신이 잘되냐가 더 큰 요소인거 같습니다.

우리가 프로그래밍을 하는 것은 '어떤 패러다임으로 구현'하는 것이 아니라 '어떤 문제를 구현하기 위해 어떤 패러다임을 이용'할 것인가 입니다.
즉, 문제 해결법을 찾고 그 해결법을 구현하기 위한 방법으로 객체 지향 패러다임을 이용할 수도 있고 함수형 패러다임을 이용할 수도 있는 것입니다.
제가 말씀드리고 싶었던 것은 바로 그런 패러다임의 선택이 자신이 배운 언어에 영향을 가장 크게 받는 다는 점입니다.
객체 지향 언어를 익히지 못한 사람이 어떻게 객체 지향 패러다임을 가지고 프로그래밍을 할 수 있겠습니까? 함수형 패러다임을 접해보지 못한 사람이 어떻게 함수형 언어의 패러다임을 가지고 문제 해결법을 구현하겠습니까?
최초 질문하신 분도 기존에 객체 지향 언어를 접했었기 때문에 C를 이용해서 클래스를 구현해 보고자 하는 생각을 하신 것입니다. 그렇지 않았다면 그런 생각을 하기가 매우 힘들 것입니다.
언어는 사고를 구체화하는 도구일 뿐아니라 사고의 틀 자체이기도 합니다.
제가 생각하기에 C를 이용해서 객체지향을 흉내낸다는 것은 단지 언어적 유희에 불과합니다. 객체 지향 패러다임을 이해하는 데 도움이 전혀 되지 않을 뿐더러 마치 우리말, 우리글을 가지고 어설픈 번역체 말투를 사용하는 것과 같이 어색할 뿐입니다.

아래의 예제를 봅시다.

myRect->primaryColor()->getRed();

C++의 코드입니다. myRect->primaryColor()는 Color 객체의 포인터를 반환한다고 합시다. 여기에서 primaryColor()가 객체의 포인트가 아닌 null을 반환했다면 어떻게 될까요? C++의 경우에는 이런 부분에 대해서 의식적으로 절차지향적인 방법으로 잡아주거나 언급하신 NullObject 패턴을 사용해야만 합니다. 반면에 Objective C에서는

[[myRect primaryColor] red];

이 코드가 문제를 일으킬 가능성은 없습니다. myRect 객체에서 primaryColor를 호출하면 어떤 형태이든 객체를 반환할 것입니다. Objective C는 C와 같이 암묵적으로 int를 반환하지 않고 (implicit int) 모든 객체를 가리킬 수 있는 id를 반환합니다. 그리고 호출이 실패했을 경우에는 POD인 null이 아닌 객체 nil을 반환할 것입니다. 이제 red라는 메시지를 처리해야 할 것입니다. Objective C에서 메시지를 처리할 때는 Smalltalk 처럼 상속과 서브타입 모두를 다룹니다. 간단히 말하면 red라는 메소드가 있고 인자의 "명칭":이 같다면 무조건 실행가능합니다. (위의 소스에는 두번의 메시지 모두 인자가 없습니다.) 그래서 결국 nil 객체의 red 메소드를 다루는 메시지로서 실행이 될 것입니다. 그런데 nil 객체의 red 메소드가 없으니 문제를 일으키겠군요? 하지만 아무런 문제가 없습니다. nil 객체를 향하는 모든 메시지는 nil 객체를 반환하도록 "메시지가 규정" 되어 있습니다. Objective C의 메시지는 C++의 메소드와는 달리 물리적인 레이어에서 떨어져 있습니다. 개발자는 primaryColor 메시지가 성공적으로 수행이 되었는지만 관심을 가지면 됩니다. 성공하지 못했다면 nil 객체를 가지고 있을 것입니다. nil 객체를 확인하는 방법도 간단합니다. Color를 받았다고 가정하고 객체로 할 일을 수행하면 nil이 전파될 것입니다. 서브타입과 개념적인 메시지 호출, nil 객체는 C++의 객체 구조보다 더 유연하며 더 강력한 다형성을 보장합니다.

보통은 토론의 행방은 알 수 없지만 앞으로 토론이 계속되면 어떤 이야기를 나누게 될지는 알 수 있을 것 같습니다. 캡슐화가 추가된 60년대생 Simula의 후예와 70년대생 Smalltalk의 후예에 대한 이야기겠지요.

이렇게 말씀하시는 분이 계시군요. 과연 그럴까요?

우리가 C++라는 언어가 일반화 된 지금에 와서는 C++사용경험을 통하여 C로 객체지향의 장점을 구현할 수 없을까 하는 고민을 하게 된다는 점에서 일반적으로는 맞는 말일수 있습니다.

하지만 반드시 그런것만은 아닙니다.

가령 assembly에 익숙한 사람에게 있어서는 모든 가치판단기준이 assembly이기 때문에 C program을 보면서도 "이건 assembly로 구현하면 어떻게 구현될까?"라는 자연스런 질문을 던지게 됩니다.

그래서 그러한 고민의 끝에 결국 C program을 보고서 그와 상응한 기능을 assembly로 구현해보고 그 장점을 취하게 됩니다.

이러한 경향은 assembly programmer가 반드시 구조적 프로그램 기법에 익숙하거나 C를 많이 사용해서 얻어진 결과물이 아니라 단지 사람이란 존재가 무언가 새로운 것을 익혔을 때 늘 과거 자신이 지니고 있던 지식의 틀에 비교하는 본능적인 무엇이 있기 때문입니다.

마찬가지로 C에 익숙한 사람은 C++ 코드를 보면서도 과연 C로는 이것이 어떻게 구현되어 있을까? 라는 자연스러운 질문을 던지게 됩니다.

그런 자연스런 질문의 결과로 C++의 class는 structure로 매핑되고 method는 pointer to function으로 상속은 pointer to structure로 매핑된다는 사실을 추론하게 됩니다.

위의 assembly programmer의 예와 마찬가지로 이러한 경향은 C programmer가 반드시 OO 프로그램 기법에 익숙하거나 C++를 많이 사용해서 얻어진 결과물이 아니라 단지 사람이란 존재가 무언가 새로운 것을 익혔을 때 늘 과거 자신이 지니고 있던 지식의 틀에 비교하는 본능적인 무엇이 있기 때문입니다.

C++에 익숙해져서 혹은 C++에서 OO개념을 철저히 학습한 결과로 C progammer들이 C++을 C식으로 바라본다는 것은 이러한 의미에서는 자연스런 인간의 본능적 성향을 망각한 성급한 단정이 아닐까 생각해 봅니다.

그리고....

C++창시자는 처음에 객체지향을 C로 구현하려고 노력했고 그러한 노력의 결과 그는 성공하였으며 그결과물이 바로 C++이란 언어입니다.

이러한 과정은 최초 C++이 C로의 precompile과정을 거쳤다는 것만 봐도 확연히 알수 있는 사실입니다.

만약 모든 사람이 C++을 배웠기 때문에 C로 OO를 구현하려고 시도한다는 말이 사실이라면 지금의 C++은 생길 수도 없었다는 점을 말씀드리고 싶습니다.

다른 사람도 아닌 C++ 창시자 자체가 원래는 C로 객체지향을 구현하였고 이를 바탕으로해서 C++이란 언어가 탄생하게 되었다는 역사적인 사례는 C++을 배우지도 않고 C를 통해서 객체지향을 생각할 수 있다는 가장 명확한 일예가 아닐 수 없습니다.

뭔가 오해하셨군요. 제 주장의 요지는 언어는 단순한 도구가 아니라 사고의 틀을 제공한다는 것입니다.

예를 드신 것 처럼 C프로그래머가 C++을 접했을 때 C에 적용해 보려고 하는 것은 C++라는 언어를 통해서 객체 지향 개념을 접했기 때문에 가능한 것입니다.
게다가 class는 structure로 매핑되고 method는 pointer to function으로 매필된다는 식의 사고 방식을 같는다는 것 자체가 이미 C언어의 패러다임에 영향을 받았다는 것을 뜻합니다. 이것 모두 언어는 단순한 도구가 아니라는 사실을 의미합니다.
즉, C프로그래머가 C++를 학습한 결과로 C++를 C식으로 바라보는 것이 아니라 반대로 C에 익숙하기 때문에 C++를 C식으로 바라보는 것입니다. C++에 익숙하다면 굳이 그런 비교를 할 필요가 없습니다. 자연스럽게 패러다임이 몸에 배어 있기 때문입니다.
그리고 C++가 C로 구현된 역사적 사실은 님의 주장에 적절한 예가 못된다고 생각합니다. C++가 객체지향 언어라고 해서 C++언어를 구현하는 작업 자체가 객체 지향 패러다임을 가질 필요는 없기 때문입니다.
프로그래밍은 '문제를 해결하는 방법(알고리즘)' 과 '해결 방법을 구현하는 방법(패러다임)'으로 나뉩니다. 그리고 언어는 후자에 영향을 끼칩니다.
C++는 '객체 지향 프로그래밍이 가능한 언어를 구현하는 방법'에 대한 결과물이고 그 결과물을 구현하기 위한 방법으로 C를 선택한 것입니다.
다시 말하면 '객제 지향 프로그래밍 방법(언어)'를 구현하기 위한 방법이 C언어였지, '객체 지향 프로그래밍 방법'이 C는 아니였다는 말씀입니다.
게다가 객체 지향 패러다임은 C++가 세상에 나오기 십 수년 전에 이미 있었던 개념이고 simula와 같은 객체 지향 언어가 이미 세상에 존재하던 시기입니다.
물론 최초에 객체 지향 패러다임은 어떻게 생겨났는가에 대한 의문이 들 수 있습니다. 그러나 그건 어느 순간 불쑥 떠오는 생각도 아닐 것이고 기존 패러다임을 조금씩 확장하는 과정에서 나왔을 것입니다.
어쨌든 언어의 패러다임과 그 언어를 구현한 방법과는 별개라는 점을 말씀드리고 싶습니다.

비 객체 지향적인 시각에서 봤을 때 클래스는 code과 data의 결합, 다시 말하면 함수와 변수의 결합으로 보일 것입니다.
그러나 객체 지향에서의 클래스는 그런 외향적인 것이 '결코' 아닙니다.
단순히 C의 구조체와 함수 포인터를 이용해서 클래스를 흉내내는 것이 바람직하지 못하다고 주장하는 것은 바로 이런 오해를 할 수 있기 때문입니다.
'클래스 = 함수 + 데이터' 이런식의 개념은 이미 - 객체 지향 패러다임이 제대로 이해되지 못하던 - 80년대에 버려진 개념입니다.
그리고 위에 예시한 것처럼 다형성을 흉내내는 것은 객체 지향이 표방하는 '인터페이스에 의한 설계' 개념에 오히려 해가 될 것 같습니다.

님이 말씀하신 근원적인 관점에서 바라본다면 클래스나 구조체나 결국은 메모리 처리에 불과합니다. 그렇게 따진다면 이 세상의 모든 컴퓨터 작업은 결국 전기를 껐다 켰다 하는 스위칭 작업에 불과한 것이 되고 맙니다...
기계에적인 관점에서 C와 C++이 같다고 말한다면 세상에 어느 언어가 다르겠습니까? 심지어 배열과 구조체의 차이는 무엇이며 분기문과 함수의 차이는 무엇입니까? 모든 언어 문법의 차이는 무엇이겠습니까? 결국 0아니면 1입니다...
우리는 문학을 시, 소설, 수필 등등으로 구분합니다. 그러나 결국 이것은 한글의 초성, 중성, 종성으로 이루어진 문자 집합에 불과합니다. 그렇다면 결국 시나 소설이나 수필은 모두 같은 것입니까?
한 단계 더나아가 같은 시이지만 한글로 된 시와 영문으로 된 시는 근원이 되는 문자가 다르므로 다른 문학 장르가 되는 것입니까?
만약 어떤 A라는 컴파일러가 클래스 내부에 있는 멤버 변수들을 같은 메모리 블럭에 두지 않고 각 타입 별로 다른 메모리 블럭에 위치하도록 구현하였다면 그 컴파일러에서의 클래스와 일반적인 C++컴파일러의 클래스는 이제 다른 것이 되는 것입니까?
패러다임이라는 것은 그런 근원적인(로우레벨) 관점에서 바라보는 대상이 아닙니다.

syntactic approach는 객체 지향 언어를 설명할 때 사용하는 관점이 될 수는 있습니다. 그러나 객체 지향 패러다임을 설명하는데에는 필요가 없는 개념일뿐더러 오히려 때론 객체 지향적 사고 방식을 방해하는 요소가 될 수도 있습니다.
예를 들어 '클래스'를 함수+구조체식으로 바라본다면 단위 전략 클래스나 인터페이스를 어떻게 이해할 수 있겠습니까?
객체 지향적인 사고에서 클래스는 '책임을 지닌 것'입니다. '객체 = 책임'이라는 패러다임을 가져야 객체 지향적인 사고가 가능합니다.

상속은 구현적인 관점에서 봤을 때 결국 copy&paste에 불과합니다. 부모 클래스의 public/protected 멤버들을 자식 클래스가 고스란히 복사한 것입니다. 그러나 이런 식으로 이해한다면 절대 올바른 객체 지향적인 상속 관계를 구현할 수 없습니다. 90년 대 이전에 객체 지향은 바로 그런 식으로 이해가 되었었기 때문에 상속을 단순한 기능 확장의 목적으로 남용하였었고 이제 이런 것들은 잘못된 설계라는 것이 널리 알려져 있습니다.

'캡슐화'는 구현적인 관점에서 단순히 관련있는 함수와 데이터를 묶어놓은 것처럼 보입니다. 그러나 '캡슐화'는 더 방대하고 추상적인 개념입니다.

'다형성'은 어떻습니까? 어찌어찌 함수 포인터를 조작해서 '다형성'비슷한 기능을 구현했다고 할 때 그것이 다형성이 가진 패러다임을 뜻하는 것은 아닙니다.

근원적인 것을 따져 들어가는 것도 좋지만 보다 사고의 수준을 높이기 위해서는 추상화가 반드시 필요합니다. 그리고 그런 추상화를 도와 주는 것이 그런 패러다임에 걸맞는 언어인 것입니다.

객체 지향 패러다임에 맞지 않는 언어를 이용해서 객체 지향을 이해하려하면 외형적인 형태를 흉내내는 것에 사고의 초점이 맞춰질 수 있기 때문에 객체 지향적 사고에 방해가 되는 것입니다.

이해가 안되는 부분이 있어 반대로 질문을 드리겠습니다. [nil someMethod]이 nil을 반환하는게 무엇인 문제인가요?

먼저 앞의 글에서 대답이 될만한 부분에 Bold 표기를 하고 시작하겠습니다.

1. 상속이 부모 자식 관계를 벗어나서 전체 객체 사이에 범용적으로 적용될 수 있습니까?

2. A 클래스를 상속받은 B 클래스만 제공 받았다면 B 클래스의 중복없이 상속으로 B 클래스의 내용을 제거할 수 있습니까?

2. 상속이 부모 객체의 private 메소드를 자유롭게 다룰 수 있습니까?

코드를 제시하지 않았던 것은 Objective C의 코드가 creativeidler님에게 실질적으로 도움이 안될 것이라고 믿었고 C++에서 비슷한 코드가 구현이 불가능하거나 현실적으로 힘들어서 상대적인 비교가 되기 힘들어서라고 판단했기 때문입니다. 소스를 보여주지 않고 기능의 나열로 이야기하는 것이 더 현명하다고 생각했습니다. 내 생각엔 안되는 것 같은데 creativeilder님은 된다고 하시니 이전의 글에 체크를 해두고 질문을 드리겠습니다.

1. C++ 언어에서 제공해주는 런타임이 얼마나 되나요? 그리고 그것을 신용할 수 있나요? type_info::name() 함수가 int형에 대해서 "int"라는 문자열을 반환해주실 것으로 믿습니까?

2. 위의 모든 것을 이식성을 버리고 creativeilder님이 구현하였다고 가정합시다. 또 모든 객체에 대하여 레퍼런스 카운터만이라도 다형성을 보장할 수 있습니까?

3. 템플릿의 도움을 받지 않고 인터페이스가 공유되지 못하는 서로 다른 두 객체를 받아와서 같은 이름의 메소드를 수행할 수 있겠습니까?

4. 만약 템플릿의 도움을 받는다면 가상 함수에 대해서도 다형성을 보장할 수 있겠습니까? 그리고 동적으로 다른 객체를 템플릿에 받을 수 있겠습니까?

5. A<-B<-C<-D간의 상속관계를 가진 객체가 있다면 암시적으로 D의 객체의 메소드를 실행시키는 것 이외에 명시적으로 A,B,C의 메소드를 실행시킬 방법이 있을까요? 거기에다가 호출하는 측에서 B와 C의 메소드만 호출한다는 식의 정책을 정할 수 있나요?

6. 그것 역시 해내셨다면 이제는 상속관계가 없는 여러 객체들 사이에서 원하는 메시지에 해당하는 메소드를 복수개 실행시킬 방법이 있나요?

제 글을 직접 인용하시진 않았지만 저에게도 해당되는 말씀으로 생각하고 답변 드립니다.

제가 어셈블리어를 깊게 알지 못해서인지 몰라도 'data segment와 code segment의 결합'이라는 말이 '데이터 + 함수'라는 말과 어의적으로 얼마나 큰 차이가 있는지는 잘 모르겠습니다.
어쨌든 '객체가 data segment와 code segment의 결합이다'라는 말이 틀렸다는 것이 아닙니다. 그렇게 바라보는 관점이 비 객체 지향적이라는 것입니다. 님의 표현대로라면 '구현방식에 대한 기계어적인 관점'인 것이지요...
제가 처음 언급했었던 객체 지향 언어가 아닌 언어로 객체 지향을 흉내내는 것이 바람직하지 못하다는 이야기는 결국 그런 관점이 객체 지향 개념을 이해하는데 도움이 되지 못한다는 뜻입니다.
단지 '아 클래스라는게 이렇게 구현될 수 있겠구나'하는 정도일 뿐이며 이것은 객체 지향 패러다임을 이해하는 것이 아니라 그냥 클래스 구조에 대한 로우 레벨 차원의 이해가 될 뿐입니다.

저는 어셈블리어를 잘 모르기 때문에 분석을 못하겠군요. 하지만 아마 어셈블리어 수준에서 본다면 님의 말씀이 맞을 겁니다. 객체 - 뿐만이 아니라 프로그램 자체 - 라는 것이 결국 data segment와 code segment 외에 무엇이 있겠습니까? 어차피 - 어떤 언어를 가지고 프로그래밍을 하든지 - 컴파일(혹은 인터프리팅) 후에는 다 똑같은 것일테니까요...
그런데 프로그램을 assembly차원에서 찬찬히 훝어 보는 것이 과연 객체 지향을 이해하는데 도움이 될까요? 그것은 assembly 차원에서 이해하는 것이지 객체 지향 차원에서 이해하는 것이 아닙니다.
왜냐하면 어셈블리어는 객체 지향 패러다임에 적합한 추상화를 제공해 주지 못하기 때문입니다.
모든 것을 객체가 아닌 data segment와 code segment단위로 바라 보고 함수 호출을 레지스터 및 세그먼트 제어로 바라 보는 것은 어셈블리어가 제공하는 패러다임의 시각입니다.
이런 시각에서 봤을 때 객체와 '구조체+함수 포인터'는 차이가 없어 보입니다. 그러나 바로 그 점이 잘못됐다는 것입니다. 올바른 객체 지향 프로그래밍을 위해서는 객체를 다르게 봐야 합니다. 그런데 C와 같은 객체 지향 패러다임이 없는 언어로 객체를 구현하게 되면 바로 그런 점을 혼동할 소지가 높다는 것입니다.

왜 수많은 패러다임을 가진 언어가 세상에 만들어지겠습니까? 그것은 어떤 패러다임을 가지고 프로그래밍을 하기 위해서는 그 패러다임에 적합한 언어를 가지고 프로그래밍 하는 것이 가장 바람직하기 때문입니다.
모든 사람들이 고도의 지능을 가지고 있어서 어셈블리어를 가지고도 아니면 전기 스위치의 조합만으로도 충분히 추상화된 사고가 가능하다면 그럴 필요가 없을 것입니다.
그러나 사람의 사고 수준은 한계가 있기 때문에 추상화와 계층화가 필요한 것입니다. 그리고 그런 추상화나 계층화를 도와 주는 것이 언어이고 플랫폼이 아니겠습니까?

이전 글 하나 인용하겠습니다.

OO를 제대로 이해했다면 어떤 언어를 선택하든 상관없다는 말은 일면 타당해 보이지만 제 생각에는 최대한 패러다임에 적합한 언어를 선택하거나 혹은 자신이 가장 잘하는 언어에 적합한 패러다임을 가지고 프로그래밍 하는 것이 옳다고 봅니다.
C를 이용한다면 굳이 객체 지향 프로그래밍을 할 필요가 없습니다. C에 적합한 패러다임으로 '문제 해결 방법을 구현'하면 됩니다.
종이를 자르기 위해서 가위를 이용할 때는 가위질을 하면 되고 칼을 사용할 때는 칼질을 하면 됩니다. 굳이 가위의 한쪽 날을 가지고 칼질을 흉내내거나 칼 두개를 연결해서 가위질을 흉내낼 필요는 없습니다.

용어가 좀.. 런타임은 RTTI를 의미하는 것인가요? 1번은 의도하신 바가 무엇인지 잘 모르겠습니다. 2번도 잘 모르겠네요. 3번은 RTTI로 가능한 것 아닌가요? 4번도 질문의 의도가 뭔지 모르겠네요. 가상 함수는 다형성을 보장하기 위해 존재하는 것 아니던가요? void*라면 템플릿 아니더라도 다양한 객체를 저장할 수 있죠.
5번은 그 객체가 D 타입이라는 가정을 한 것인가요? D타입의 객체를 실행시키면서 부모 객체의 메소드를 실행시키고 싶어하는 경우? 이런 요구사항이 생기는 것 자체가 비 OOP적인 것으로 보입니다만.. 6번도 RTTI로 어느 정도 가능하죠.

CN님 말씀을 듣고 보니 Objective C가 C++보다 기능이 더 많다는 건 알겠습니다. 그런데 더 객체지향적이란 건 동의할 수 없군요. 오히려 객체지향에서 피해야할 것들을 너무도 많이 지원하고 있다는 생각이 드는데요. 사실 OOP에서 문법적으로 어떤 기능들을 더 많이 지원하느냐는 그리 중요하지 않습니다. OOP의 핵심 문법만 잘 지원하면 오히려 간결한 문법일수록 좋죠. Java는 다중 상속도 안되고 operator overloading도 안되는데 왜 C++보다 더 객체지향적인 언어로 평가받을까요? 따지고보면 C++이 훨씬 객체지향적인 문법 지원이 많은데 말입니다. 그것은 아마도 Java가 좀더 객체지향적으로 좋은 코드를 만들도록 유도하기 때문일 것입니다. 지금까지 CN님에게 얻은 정보만으로는 Objective C는 C++보다도 더 해로운 요소가 많은 것 같아 보입니다.

그리고, 제가 Objective C 코드를 읽을 수 없을 것 같아서 코드를 제시하지 않으신 거라면 염려 마시고 제시해주세요. 어차피 같은 패러다임의 언어는 다 비슷비슷한 것 아니겠습니까. 충분히 두 코드를 비교해서 어느 것이 더 좋은지 설명할 수 있고 저도 이해할 수 있을 것입니다. 모르면 제가 잠깐 ㅤㅎㅜㅌ어보고 쳐박아두었던 Objective C 책을 뒤져서라도 이해하려고 노력할 것이니 코드로 제시해주세요. 어차피 CN님의 주장이 Objective C에서 같은 내용으로 C++보다 더 객체지향적으로 구현할 수 있다는 것이니 가장 쉽고 편리한 입증 방법은 코드 비교 아니겠습니까.

흠. 중간에 조금 이상하게 흘러간 감이 있는데 최초에 C++을 쓸 수 있는 상황에서 굳이 C로 객체지향을 할 필요가 없다는 주장에 대해 C에서 객체지향을 하는 게 뭐가 나뻐..하는 식으로 반론이 제기되면서 오해가 오해를 낳는 것 같습니다.

단순히 C만 써야하는 상황과 C/C++을 모두 쓸 수 있는 상황으로 나눠서 생각해보는 것이 어떨까요? 다음처럼 의견을 분류해볼 수 있을 것 같습니다.

1. C만 써야하는 상황
1-1. C에서도 OOP가 낫다.
1-1. C에서는 OOP보다 SP가 낫다.

2. C/C++을 모두 쓸 수 있는 상황
2-1. OOP를 하고 싶다면 C++을 쓰는 것이 좋다.
2-2. OOP를 하고 싶더라도 굳이 C++을 쓸 필요는 없다.

제 경우는 1-1, 2-1입니다.

질문의 의도를 잘 모르겠습니다. fopen(), fwrite(), fread()가 무슨 문제가 있나요?
그런 함수들은 객체 지향이든 다른 어떤 패러다임이든 그냥 함수일 뿐입니다...

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

대단히 죄송하지만 이글을 읽는 순간 님의 인식의 한계가 눈에 금방 보이는군요.

님은 그저 user interface적인 관점에서 즉, 단지 fopen을 불러다 쓰는 입장에서 fopen은 C함수인데 갑자기 무슨 객체지향 어쩌고 저쩌고를 따지느냐라는 말씀을 하신 것으로 보입니다.

그러나...

fopen(), fread(), fwrite는 VFS에서 돌아가는 함수이며 이것은 device와 독립적인 system call입니다.

또한 이 device라는 놈들은 실시간적으로 binding 되어야 하는 글자 그대로 동적 binding이 필요한 그런 구현이 되어야 한다는 것이지요.(insmod, rmmod)

따라서 이것은 user interface적인 관점에서 보면 그냥 C함수이지만 구현입장에서 생각해보면 OO에서 말하는 pure virtual function이며 다시말해 Componant를 구현하기 위한 Interface역할을 의미합니다.

그런데 이것을 kernel에서는 C로 구현하고 있다는 겁니다.

결국 위의 VFS system call은 구현방법으로 보면 C로 OO의 pure virtual function을 성공적으로 구현한 것인데 이것은 C++로만 객체를 구현해야만 좋다는 논지에서 보면 이러한 LINUX의 kernel code는 그야말로 어설픈 객체 흉내내기에 불과한 쓰레기 코드가 되는 것이 아니냐고 되묻고 있는 겁니다.

제가 파악한 바, 님의 한계는 진실로 C로 구현한 객체란 어떤 것인지 실제적인 예를 아직 한번도 제대로 검토한 적도 없으면서 일반적인 C사용에 대한 기초적인 상식과 C++의 문법이나 객체에 대한 몇가지 이론만 가지고 무조건 객체는 C++로만 구현해야 하고 C로 구현하면 제대로된 객체는 구현 불가능하다라고 말하고 있는 것입니다.

지피지기면 백전 백승이라는 말도 있는데 님께서는 계속 원론적인 부분만 말씀하시지 마시고 가령 위에 예로 들었던 C로 구현된 객체의 전형적인 예제인 VFS kernel source 정도만이라도 직접 분석해 보시고 나서 님의 주의 주장을 펴시는게 훨씬 더 현명해 보이는 것 같습니다.

상대방 주의 주장의 근거가 되는 kernel source나 그 체계가 뭔지 전혀 모르시는 상황에서 무조건 <객체는 C++로만 구현해야 제대로 된 객체다>라고 반복하신다면 그건 결국 일방적인 자기 주장일 뿐이므로 그 어떤 상대도 설득할 수 없지 않을런지요?

C++은 멀티패러다임 언어이기 때문에,
객체지향 언어인 Obj-C보다 우수하다고 주장합니다.
(적어도 비-OOP 분야에서 -_-;;; ㅈㅅ)

-명예의전당자료발굴단-

http://kldp.org/node/31629 - gtk와 객체지향에 대해 재미있는 쓰레드가 있습니다. 읽어보세요.

> 최초의 C++ 컴파일러는 C언어의 preprocessor로서 구현되었다고 알고있습니다.

예, 맞습니다.

> 즉 C++의 각종 메커니즘들이 macro 치환등을 통해서 완벽한 C언어로 바뀐 후, 기존의 C 컴파일러를 통해서 binary code화 된 것이죠.
> 저도 1990년에 이런 preprocessor 형 C++ 컴파일러를 써본적이 있습니다.
>

preprocessor 라고 해서 C 언어에서 정의하는 preprocessor 를 의미한다기
보다는, 일단 (해당 환경에서) 번역 가능한 완전한 C 소스로 변환하는 중간
과정을 거쳐 binary code 를 생성했다는 것을 의미한다고 볼 수 있습니다.

> 물론, 지금의 C++ 표준도 이런 preprocessor 형태로 처리 가능할지는 모르겠네요.
>

따라서 지금의 C++ 표준도 동일한 행동을 보이는 C 프로그램으로 거쳐
binary code 를 생성하도록 구현될 수 있습니다 - 다만, 현실적인 이유로
다소(?) 뒤쳐지는 성능을 보이게 됩니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

사실 C에서도 클래스와 비슷한 자료형 얼마든지 만들 수 있습니다.
그렇게 쓰는 것이 좀 불편할지는 몰라도 규칙적으로 사용하면 별 문제 안됩니다.
그리고 개체지향적 설계를 C로 구현하는 것 얼마든지 가능하고 미련하거나 무의미한게 아닙니다.
콜백 개념을 사용하는 C 라이브러리들 중엔 this 포인터와 같은 개념을 구현하는 것들도 있습니다.

오히려 개체지향 언어를 사용해야 하는 이유는 따로 있습니다.
상속체계에 따른 형변환 규칙을 적용해준다는 것이죠.
부모 클래스의 변수에 자식 클래스의 인스턴스를 대입할 수는 있지만 다른 것은 막아준다는것.
이걸 통해서 강력한 형 검사를 하면서도 상속의 개념을 그대로 사용할 수 있는거죠.

C에서는 그런 것이 안되기 때문에 강제 형변환을 통해서 강력한 형 검사를 항상 무력화시킬 수 밖에 없는데
그로 인해서 컴파일 시에 잡아야 할 에러들을 잡지 못하게 됩니다. 경험상 이게 가장 큰 문제더군요.

C++에서 구현할 수 있는 것은 C에서도 구현할 수 있습니다.
(조금만 생각하면 당연한 것일 수도... ^^a)

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.