예전의 글에서 설명했던 것은 Factory 의 경우입니다. Factory 는 어떤 ID값을 받아와서 그에 해당하는 오브젝트를 생성해서 돌려주는, 일종의 new 를 대신할 수 있는 존재라고 생각하시면 됩니다. Factory 에 대해 처음 접하는 분은 '오브젝트를 만들려면 new 가 있는데 왜 Factory 를 쓰느냐?' 라고 생각하실 것입니다. 하지만 new 문장 다음에는 구체적인 클래스의 이름을 적어줘야 하고, 이것은 컴파일 하는 단계에서 정해져 버리는 것이기 때문에, 한가지 오브젝트만 만드는 것이 아니라, 여러가지 오브젝트를 만드는 경우에는 switch - case 문으로 여러가지 new 중에서 선택을 하게 만들어지는 것이지요.

switch-case 형태로 만들어놓으면, 새로운 오브젝트의 종류가 추가될 때마다 그쪽 문장도 계속 손봐주어야 하기때문에 귀찮아지는 것을 막기 위해서 factory 를 만드는 것이고, RTTI 가 도움이 되는 경우는 factory 중에서도 prototype 을 이용한 factory 생성방식입니다. prototype 방식은 간단히 설명하자면, 생성을 할 오브젝트들을 사전에 등록해놓고, 나중에 factory 에 오브젝트 생성요청이 들어오면 사전에 등록된 prototype 오브젝트가 Clone 을 하는 식으로 새로운 오브젝트를 만들어내는 것입니다. 이에 대한 자세한 예제는 Noel Llopsis 의 C++ for game programmer 라는 책에서 보실 수 있습니다. 이때 Prototype 의 id 를 자동으로 만들기 위해서 RTTI 를 사용할 수 있지요. 꼭 써야만 하는 것은 아닙니다.

그리고 RTTI 가 쓰이게 되는 경우중 가장 흔한 경우는 dynamic_cast 를 쓰는 경우입니다. 오브젝트들을 계층적으로 만드는 것은 중요한 일이긴 하지만 능사는 아닙니다. 예를 들어서 윈도우 시스템을 C++ 을 써서 만든다고 할때, 흔히 CWindow 같은 것을 만들고, CControl, CButton, CFramewindow 같은 세부 클래스들을 CWindow 로부터 상속받게 디자인하곤 합니다. 그런데 CWindow 에는 없지만, CButton 에서만 특별하게 쓰일 메소드 (예를 들면 GetPushedStatus() ) 를 만들게 된다면 어떻게 될까요? 이것을 CButton 상에 정의해 놓으면 CWindow * 로 받은 상태에서는 직접 GetPushedStatus 같은 메소드를 호출할 수가 없고, 그렇다고 CWindow 상에 정의해놓으면 계속 CWindow 쪽이 커져버리게 됩니다. 그럴 때 흔히 CWindow *로 받은 포인터를 CButton * 으로 강제 캐스팅해서 쓰곤 하는데, 만약 정말 CButton 이 아닌 다른 오브젝트의 포인터를 CButton * 으로 캐스팅할 경우 이게 틀린 것인지, 맞은 것인지 보장할 수가 없습니다. 이럴 때 dynamic_cast 를 사용하면, 만약 올바르지 않은 캐스팅을 한 경우 캐스팅의 결과값이 NULL 이 되어버리기 때문에 안전을 기할 수가 있는 것입니다.

짧은 답글에서 몇시간동안 설명해도 모자랄 복잡한 주제를 다루느라고 설명이 잘 되었는지 모르겠네요. 그럼..

빠르고 친절한 답변 감사합니다^^ 답변해주신것을 보고 Factory Method 패턴을 다시 보니 뭔가 흐릿하던것이 한꺼풀 벗겨진 느낌이네요. 참고자료까지 알려주셔서 더욱 감사합니다. 사실 최근에 이곳을 알게 된 후 게시판에 학규님이 올리신 추천서적들 능력닿는데까지 챙겨보려고 노력중입니다... 마는 원래 책이랑 그리 친한편이 아니라 쉽지 않네요.^^;;

지나가다 보게 되어서 실력은 없지만 한마디 쓰겠습니다.. ^^;; 단순 객체 타입체크는 typeid를 쓰면 됩니다.. 근데 이렇게 쓰게 되면 if else if.. 계속 추가시 추가해주어야 하는 부담이 커지게 되어 객체지향에 위배 됩니다. 그래서 보통 dynamic_cast를 쓰게 됩니다. 이유는 김학규님께서 쓰신것 같구요.. 체크도 NULL체크만 하면 되구요.. 이때 포인터 형이냐 아님.. 레퍼런스 형이냐에 따라 달라지는데.. 포인터 형일때만.. NULL체크를 하면 됩니다. 근데.. 보통 게임엔진에서는 dynamic_cast는 쓰지 않습니다. C++만드신분도 C++표준을 정하실때 dynamic_cast를 넣을때 고심을 많이 하셨다고 하더군요.. ^^;;(들은이야기..) 이유는 퍼포먼스에 상당히 악영향을 줍니다. 그래서 NetImmerse같은 상용엔진 같은 경우는 직접 동적캐스팅을 소프트워어적으로 구현하고 있습니다. NetImmerse같은 상용엔진을 구경하기는 힘드니.. 3D Engine Design 책에 객체지향의 하부구조인가하는 챕터보시면 나옵니다.. 애버리 교수가 지은 책인데.. 이분이 직접 NetImmerse엔진 제작에 참여하였더군요.. 그리구.. VC에 기본적으로 들어있는 MFC라이브러리도.. 소프트웨어적으로 동적타입캐스팅을 구현해 놓았습니다. MFC에 있는 이유는 VC컴파일러가 지원하지 않아서.. 직접 MFC제작팀이 소프트웨어적으로 구현하였다고 하더군요.. 전 예전에 류광님께서 번역하신 화이트그룹에서 나온 C++ How to라는 책을 보고.. dynamic_cast를 완벽하게 이해하였던 계기가 생각나네요.. 그후.. 팩토리패턴에 대해 이해하시면 빠를겁니다. 저두.. 요즘에 김학규님께서 추천해 주신 Noel Llopsis 의 C++ for game programmer 라는 책을 보고 있는데.. 단일상속, 다중상속, RTTI, STL등을 다각도로 분석하고 비교해 놓았더군요..

RTTI 라는 개념의 Design 자체는 절실한 필요성에 의해 만들어진 것이고 위에서 설명한 바와 같은 용도가 있지만, 실제 활용에 있어서는 C++ 자체의 implementation 을 쓰기보다는 위에서 MFC 나 Netimmerse 같은 식으로 자체적인 RTTI 를 사용해서 구현하는 경우가 많습니다. C++ 의 RTTI 와 자체 제작 RTTI 의 장단점을 비교한다면, C++ 의 RTTI 의 문제점은 컴파일러마다 지원여부와 방식의 세부사항이 차이가 나기때문에 표준 기능을 사용하는 것이 오히려 호환성 (예를 들면 다른 플랫폼으로 포팅한다던가..) 에 있어서 걸림돌이 된다는 점입니다. 그에 비해 자체 제작 RTTI 는 최소한의 C++기본 기능과 매크로만을 이용해서 만든 것이기 때문에 대부분의 C++ 컴파일러 (PC, Linux, 콘솔등..)에서 무리없이 쓸 수 있다는 장점이 있지만, 프로그래머가 일일이 코딩시에 매크로를 넣어줘야 한다는 단점이 있는 식이죠. 언어 표준이란 것은 호환성을 높이기 위해서 존재하는 것인데, 오히려 호환성이 떨어질까봐 표준기능을 쓰지 못한다는 것은 아이러니컬한 일이긴 하지만, 현실은 어쩔 수 없지요. 때는 2003 년인데도 불구하고 아직도 많은 사람들은 1998 년에 나온 비쥬얼씨 6.0 을 가장 많이 사용하고 있는, 첨단 기술과 비첨단 기술이 공존하는 세계이니까 말입니다..

보통의 상용엔진은 당장은 PC 만 지원하더라도 나중에 가서는 콘솔이나 리눅스 같은 제3 의 개발환경을 고려하지 않을 수 없기 때문에 자체적인 RTTI 시스템을 만들어주는 것이 일반화되어 있고, 그 영향으로 C++ 자체의 RTTI 의 유용성이 평가절하된 면도 고려해야겠지요.