'클래스'에 해당되는 글 2건

  1. 2009.12.11 잉여들을 위한 클래스설계 이야기 2/4
  2. 2009.12.11 잉여들을 위한 클래스설계 이야기 1/4
2009.12.11 09:05

잉여들을 위한 클래스설계 이야기 2/4

본론으로 가기전 여기에서 MFC 클래스 구조도를 함 봅니다~*

적절한가?

적절한가?


Rhea君을 포함한 우리 잉여들에게, MFC는 참 많은 것을 이야기해준다.
그중 하나가 클래스 구조이다.
잘만든 상용 C++ 클래스 설계를 어디가면 볼수 있을까? 파랑새는 1px옆에 있다, 바로 MFC가 그것이다.

MFC는 좆뉴비들이 착각하듯, 게임 스프라이트 툴 만드는 도구가 아니다.
그속에서 적절히 훔쳐와야 할 것이 무궁무진하다.
니 친구가 만든 듣보잡 3D 엔진의 구조를 파악하기보다는 차라리 MFC의 구조를 파악하고 숨겨진 의미를 알아내는게 프력증강에 도움이 된다.

일단 여기에서 훔쳐올 것은 최상단 클래스와 파생 클래스들의 관계이다. 우리가 잘쓰는 CView, CFrameWnd등은 아래와 같이 상속을 받았다.
파워포인터까지 동원한 포스트...

파워포인터까지 동원한 포스트...

왜 이렇게 나누었을까?
또 CView 이전에 클래스는 무슨 역활을 하나?

CObject : 거의 모든 MFC 클래스의 기반 클래스로 직렬화(Serialization), 런타임 클래스 정보(Runtime class information), 객체 진단 출력(Object Diagnostic Output) 기능을 제공한다.
CCmdTarget : 명령 메시지를 받는 기능을 갖고 있다.
CWinApp : 프로그램을 구동하는 기능
CDocument : 데이터를 저장하는 기능
CWnd : 눈에 보이는 속성을 지닌 객체에 관련한 모든 기능
CFrameWnd : 윈도우 프레임 와꾸을 관리하는 기능
CView : DC를 포함하여 데이터를 보여주는 윈도우를 관리하는 기능

이중 가장 유명한 것이 바로 CWnd일 것이다. 300개 이상의 멤버 함수를 갖고 있는 이 클래스는 눈에 보이는 모든 윈도우 객체들이 CWnd를 상속받는다. CView는 물론이고 CDialog나 CContolBar, CEdit, CButton 등 친숙한 각종 클래스들을 낳고 낳은 인기 최고, MFC의 퀸 에일리언, 컨트롤 클래스의 여왕벌 정도 되시는 클래스겠다.

그리고 CObject는 최상단임에도 불구하고 잘 알려지지 않고 있다. 오죽했으면 CWnd를 최상단 클래스라고 믿는 뉴비들이 많을 지경이니까. 아마 직접 사용하는 일이 없기에 그럴지도 모르겠다. 그러나 DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC, DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE, DECLARE_SERIAL/IMPLEMENT_SERIAL등의 매크로를 이용하여 클래스 런타임시 클래스 정보와 객체 생성 여부, 그리고 직렬화를 사용할 수 있게 해준다.
굳히 기존의 자신의 MFC 프로젝트를 뒤져보지 않더라도 MSDN에서 http://msdn.microsoft.com/ko-kr/library/38z04tfa.aspx를 살펴보면 CObject에서 직접 상속받아 객체를 관리하는 모습을 볼수 있다.

이렇듯 MFC에서 1차적으로 배울수 있었던 것 하나는 가장 최상단 클래스는 직접 눈에 보이거나 입출력을 하는 일을 하지 않는다 하더라도 객체 관리를 위한 작업 준비를 해둔 것임을 알수 있다.

이 싯점에서 지난 시간 만들다 멈춘 클래스를 좀더 작업해보자. 지난 시간, 우리는 CCharacter에서 CGameCharacter를 상속받은후, CAmazon과 CAssasion과 CSorceress를 각각 상속받았다. CObject 와 같은 일을 해줄 클래스를 CGObject라는 이름으로 하나 만들었다. 특별히 'G'를 더 추가한 이유는 MFC의 CObject와 혼선을 막기 위해서이다.
또한 CGameCharacter는 저절로 MFC의 CWnd와 같이 눈에 보이는 것을 다루기 위한 클래스가 되었음을 잊지말자.

객체 관리를 위한 클래스가 최상단으로.

객체 관리를 위한 클래스가 최상단으로.

다시 게임으로 되돌아가보자. 아마존, 어새신같은 직업을 나타나는 클래스가 있지만 아직 이 녀석들에게서 직접 객체를 선언하는 것은 안된다. 지난 시간에 언급한 것처럼 적이라도 아마존이나 어세신, 소서리스같은 특성을 나타낼수 있기 때문이다. 비단 적뿐만이 아니다. 아이템을 주고 도움을 주거나 경비를 서주는 NPC 역시 직업을 가질 수 있다. 

"얼래? 제가 만들 게임에서는 NPC 직업은 상인인데요, 플레이어는 절대로 상인이 되지 못하거든요?"
라는 질문이 있을수 있다. 그럴 경우 "상인"이라는 클래스 역시 CChraracter나 CGameCharacter의 파생 클래스로 넣으면 된다.

또한 싱글 게임이 아니라 네트워크 혹은 MMO 게임이라면 상대편 역시 이들 클래스에서 파생된다. 따라서 아직도 CAmazon같은 직업 클래스는 추상 클래스로 나타내주어야 한다. 그럼 필요한 것은 아마존, 어세신같은 직업을 상속받은 클래스가 실제 플레이어인지, NPC인지, 적인지를 구분할수 있어야 한다.

다시 말해 플레이어, NPC, 적이란 것도 각각의 클래스도 나타내야 한다는 것이다. MO를 위한 "다른 플레이어"도 클래스로 나타낼수 있으나 이 강좌에서는 일단 싱글 플레이용이라 간주하자.
아 복잡해진다 ㅠㅠ

아 복잡해진다 ㅠㅠ


이제 실제 눈에 보이는 캐릭터(인스턴스가 존재하는 진짜 객체!)를 위한 마지막 파생 클래스가 필요하다.
이때 다중 상속을 하면 된다. 오호~ 다중 상속 구현 숙제는 이렇게 구현이 되었다.

사실 Rhea君은 극단적인 다중상속 반대주의자다. 그렇다고 다중상속을 100% 안한다는 이야기가 아니라,
엔진과 같은 UI부분과 데이터 처리를 위한 패턴 구현으로 인해 결국 다중상속을 받게 되게 되므로
가급적 설계단계에서는 논리적인 다중상속은 피하자는다는 이야기이다.
결국 편하게 가자는 이야기인데 이건 다음 시간에 마법 속성이 들어가며 다시 논하겠다.

예컨데 CPlayer와 CAssassin을 다중 상속 받게되면 플레이어를 위한 어세신 캐릭터가 만들어진다.
CNPC와 CMerchant를 다중 상속 받게되면 CPU가 움직여주는 상인 NPC가 만들어진다.
CEnemy와 CSorceress를 다중 상속 받게되면 마법사 적이 만들어진다.

어세신 하악하악

어세신 하악하악



그런데 어느날, 기획자가 달려와 고민이 하나 생길 수도 있다.

쵝오의 먼치킨 급 캐릭터인데요, 아마존과 소서리스, 혹은 어세신과 아마존의 능력치를 동시에 쓸수 있는 새 캐릭터를 하나 넣기로 하지요, 아, 물론 현질 해야하는 유료 캐릭터로요!

라는 막장으로 가는 기획이 끼어들수 있다.

막장에 대해 좀더 자세히 알고 싶다면
이 문서(http://ko.uncyclopedia.info/wiki/%EC%95%84%EB%82%B4%EC%9D%98_%EC%9C%A0%ED%98%B9) 를 추천한다.

아마 분명 상속을 써먹을 좋을 기회라 판단한 뉴비 개발자는 CPlayer + CAssassion + CAmazon을 다중 상속 받아 CPlayerAssassinAmazon 클래스를 만들 것이다. 그림으로 보면,

이른바 죽음의 다이아몬드!

이른바 죽음의 다이아몬드!

CPlayer를 배제하더라도 CPlayerAssassinAmamzon은 이른바 죽음의 다이아몬드(DOD, Diamond of Death. 게임프로그래머를 위한 C++ 2장 참조)라는 다중 상속의 폐해, 즉 모호성 문제를 고스란히 떠안게 된다.

그럼 CPlyaerAssassin과 CPlayerAmazon을 상속받으면 어떻게 될까?
엎어치나 메치나~란 단어가 적절하다.

엎어치나 메치나~란 단어가 적절하다.

이렇게 해본들, 다이아몬드가 길어질 뿐, 나아지진 않는다.
의도하지 않게 CGameCharacter는 CPlayerAssassinAmazon의 부모 클래스가 되어 예측하지 못한 결과를 초래하는 결과를 낳는다. 이건 좆망하는 실패 사례로 가는 지름길이며 KGC에서 우린 이렇게 망했어요~라며 작년처럼 울부짖을수 있는 아이템이 된다.

이를 해결하는 방법으로 가상 상속(vitual inheritance), 추상 인터페이스의 사용(AddRef(), Release()), 플러그인 기법 등이 있지만 지나치게 복잡도을 증가시키게 되며 배보다 배꼽이 더 커질 수도 있다.
여고생치킨 : IT전문 용어로 배보다 배꼽이 더 큰 경우를 가르킨다. 그래도 강남에서 12만원이면 아주 적절한거다(응?).

여고생치킨 : IT전문 용어로 배보다 배꼽이 더 큰 경우를 가르킨다. 그래도 강남에서 12만원이면 아주 적절한거다(응?).

따라서 Rhea君 기준으로 가장 좋은 방법은 이 구조를 피하는 것이다!
이처럼 CAssassin과 CAmazon이 동시에 필요한 경우에는 CAssAmazon(어? 뜻이 좀 -_-;;;)라는 클래스를 아예 하나 만드는 것이다. 어차피 똥꼬아마존AssAmazon은 하나의 캐릭터 클래스이기 때문이다. 마치 C같네~, 멤버가 겹치네~, 같은 함수를 사용할 수 있네~라는 유혹이 뒤따른다. 하지만 그 개발자스런 유혹을 벗어나야 유지보수 단계가 편해진다.
이 단계에서 이런 일이 발생한다.

이 단계에서 이런 일이 발생한다.

사실 방금의 사례는 실제 개발자 혼자 개발하는 기간에도 자주 일어난다.
흔히 보아온 사례중 하나가 CRecordset 같은 DB 테이블을 하나의 클래스로 생성시킨 경우이다.
두가지 이상의 CRecordset 파생 클래스(의 객체)를 갖고 놀다가 어느 순간 두 클래스를 하나의 클래스로 다중 상속 시켜 작업을 하는 사례가 있다. 무엇 때문에 어떤 설계 방침을 갖고 그런 구조가 나오게 되었는지 모르겠지만... 상상력 하나만큼은 끝내준다.
이 이외에도 소켓 객체를 따로따로 갖고 놀다가 하나로 합치거나 아주 기가막힌 것을 볼때가 있는데 이런 경우 대부분, "왠지 그렇게 하면 될것 같은" 유혹에 빠져서가 아닐까 생각해본다.

또다른 다중상속의 슬픈 예

또다른 다중상속의 슬픈 예


아뭏든 본론으로 돌아와보면,
이게 정답이다.

이게 정답이다.


상기와 같은 클래스가 정답이다.
이는 IS-A, HAS-A 공식과도 맞아 떨어진다.

갑자기 나온 IS-A, HAS-A? 이게 뭘까?
이 이야기는 다음 시간 아이템을 다루며 상속과 포함이야기에서 다시 언급하겠다.

탐구생활 :
Rhea君은 귀찮아서 클래스 관계만 기술했을뿐, 각각의 멤버 함수와 멤버 변수를 적지 않았다.
또한 public과 protected, private 도 명시하지 않았다.
이제까지를 설명한 아래 소스에서 각자가 생각하는 멤버들을 채워보자.
또한 인스턴스를 직접 생성할 수 없도록 특정 클래스는 추상 클래스로 만들어보자.

class CGObject
{
};

class CCharacter : public CGObject
{
};

class CGameCharacter: public CCharacter
{
};

class CNPC: public CCharacter
{
};

class CPlayer: public CCharacter
{
};

class CEnemy: public CCharacter
{
};

class CAmazon: public CGameCharacter
{
};

class CAssassin: public CGameCharacter
{
};

class CSorceress: public CGameCharacter
{

};

class CAssassinAmzon: public CGameCharacter
{
};

class CMerchant: public CGameCharacter
{
};

class CPlayerAssassin : public CPlayer, public CAssassin
{
};

class CPlayerAmazon : public CPlayer, public CAmazon
{
};

class CNPCMerchant : public CNPC, public CMerchant
{
};

class CEnemySorceress : public CPlayer, public CSorceress
{
};



'소프트웨어 > C# & ASP.NET' 카테고리의 다른 글

C# 강좌  (0) 2010.01.12
C# 4.0의 새로운 기능  (0) 2009.12.15
잉여들을 위한 클래스설계 이야기 2/4  (0) 2009.12.11
잉여들을 위한 클래스설계 이야기 1/4  (0) 2009.12.11
Data Access Application Block  (0) 2009.12.09
문자열 비교 - 팁  (0) 2009.12.09
Trackback 8 Comment 0
2009.12.11 09:03

잉여들을 위한 클래스설계 이야기 1/4

며칠전, 한 뉴비 5년차(뉴비 3년이면 이미 잉여이다.)에게서 C++ 클래스 설계 과제에 대한 도움을 해주게 되었다.
보편적인 OOP 숙제답게 언제나처럼 상속 + 다중상속 + 은닉(캡슐화) + 다형성(폴리모피즘)이 구현되어야 하는 숙제.

생각해보면 OOP나 C++ 수업에는 이런 경우가 상당히 많은 것 같고
한번쯤 클래스 설계에 대한 포스팅을 하고 싶기도 했기에
다른 뉴비와 잉여들을 위해 클래스 설계 이야기를 포스팅해본다.

원래 구조적  프로그래밍 언어의 대명사였던 C가 있었고 80년대에 들어 OOP, 즉 객체 지향 프로그래밍이 고개를 들었다.

어떤 언어에 객체 지향 개념을 주입할까 고민하던중,
가장 인기 있던 언어인 C에 객체 지향을 주입하였고 우리는 이것을 C++이라 부른다.

물론 C++만 객체 지향이 아니다.
GW-BASIC은 Visual Basic으로 변모하고 클래스와 객체 개념이 생겨났고
90년대 초반까지 C와 쌍벽을 이루던 Pascal 역시 OOP의 영향아래 Object Pascal, 즉  Delphi가 생겨났다.

그리고 사람들이 그 정체를 모르는 객체 지향의 사생아(?) 라이브 스크립트는,
지가 낳은 자식을 넷스케이프에 의해 자바스크립트라 불리게 되는 기가 막힌 팔자를 겪었으며,
새로 새끼친 자식까지 Adobe에 의해 액션 스크립트(플래쉬!)로 불리게 된다.

C 역시 C++뿐만 아니라  Objective-C란게 있다는 것을 기억하자.
C++은 OOP를 첨가한 가장 성공적인 언어일 뿐이다.

레포트 자료 찾아서 들어온 좆뉴비분들, 베낄 소스는 안나오고 참 지겨우시죠~~?

레포트 자료 찾아서 들어온 좆뉴비분들, 베낄 소스는 안나오고 참 지겨우시죠~~?

그런데 바로 여기에서 문제가 발생한다.
C++은 구조적 프로그래밍 언어인 C에 OOP를 강제주입(?) 하며,
C의 모든 사양을 그대로 수용했기에 아직도 "보다 객체 지향 다운 C++"에 대한 토론이 끝날 줄 모르게 되기도 한 것이다.

더우기 OOP의 이상과 구현이라는 현실에서 서로 맞지 않는 부분이 꽤 많다!
(그래서 C++은 코딩 트랜드가 꽤나 자주 바뀐다. STL이나 TR1같은 새로운 라이브러리도 추가되어 주시고.)
정말로 이것 때문에 현재에도, 회사 내에도 개발자들끼리 머리털 붙잡고 치고 박는다. -_-;;;;

인터페이스 사용 여부를 두고 싸우는 세명의 개발자. - 이전에 다른 포스트에서 썼다고 따지지 말것. 짤방이 부족합니다.

인터페이스 사용 여부를 두고 싸우는 세명의 개발자. - 이전에 다른 포스트에서 썼다고 따지지 말것. 짤방이 부족합니다.

아, 그런데 이 시점에서 오래된 낚시글에는 떡밥을 물지 않길 바란다.
아주 유명한 뻥이거든.
http://www.okjsp.pe.kr/seq/54602

낚기면 10년차도 잉여취급한다.

낚기면 10년차도 잉여취급한다.

사실 어떤 C++책에서도 이상과 현실이 맞지 않는다고 명시한 책은 없지만,
가장 유력한 증거가 바로 C#의 탄생이다(이 이야기는 또 나~~중에.).

즉, Anders Hejlsberg 아저씨가 OOP를 위해 기존 C를 버리고
ADA같은 좆망한 잊혀진 언어 스펙까지 들고온후 언어 스펙을 완전히 재작성한 것이다.
(Anders Hejlsberg 에 대해 더 잘 알고 싶으면 http://www.dreamsvc.com/?p=10 으로 ㄱㄱㅆ~)

예컨데 C#이나 JAVA에서는 다중상속이 아예 불가능하며 심지어 포인터조차 없다.
C++을 대표하는 기능중 하나인 다중상속과 C를 대표하는 기능인 포인터가 현대적인 환경에는 맞지 않을수도 있다는 이야기이다.
물론 명시적인 스펙상 불가능하지만 언제나 뒷길이 있다. 하지만 이 포스트는 C++이야기니까 일단은 여기까지만.

자, 역사 수업은 여기서 마치고 C++ 수업이란 두가지 목표를 가진다.
하나는 OOP 개념을 잡자는 것이고
두번째는 C++ 언어자체를 배우는 것이다.
하긴 머, 요즘은 교수가 컴맹이라 JAVA 따위로 새로운 시대를 맞아 JAVA로 OOP를 배우는 불쌍한 학생들도 있다고 카더라~
따라서 거의 대부분의 C++ 수업의 중간고사는 클래스 설계가 중심인 과제가 나오게 된다.

그럼 클래스 설계를 해보기로 하자.
래셔날 로즈같은 툴을 생각하는 분도 있겠지만 사실 별 쓸모가 없다.
지난 달 달력 뒤장과 네임펜이 궁극의 클래스 설계 도구이다.

단, 상기의 언급은 클라이언트 환경에 국한된다.
서버는 UI가 없어서 래셔날 로즈나 UML로 제법 그럴싸하게 만들어 낼수 있다.
그래서 서버팀 문서가 클라이언트팀 문서보다 항상 있어 보인다.

클래스 설계는 어떻게 하면 잘할 수 있을까?
우선 OOP의 마음 가짐 한가지를 기억하자.
OOP는 현실세계를 투영한다는 철학이다.
따라서 평소 철학책도 좀 읽어주시고, 깊이있는 사고를 할수 있는 능력이 있어야 한다.
개발자라도 니체의 "짜라투스트라는 이렇게 말했다" 나 카뮈의 이방인, 페스트 정도는 읽어주는게 좋다.

서론 너무너무 길었다,
Rhea君은 클래스 설계라는 초딩용과제를 맞이하여 어떤 게임을 생각하고 클래스다이어그램을 그려보았다.
여기서 어떤 게임이란 아마존, 소서, 어세신이라는 미소녀 1명과 아줌마 2명이 데커드 케인이란 노인을 납치한후, 메피스토, 디아블로, 바알을 쥐어패 삥을 뜯는다는 사회 폭력에 관한 게임이다.
남자도 등장했던 것 같은데 남자로는 한번도 안해봐서 잘 모르겠다.

사진설명 : 기둥 뒤에 숨어 디아블로에게 삥을 뜯을려는 아마존과 소서리스. 지들 힘으로 안될 것 같아 아는 오빠를 부르고 있다.

사진설명 : 기둥 뒤에 숨어 디아블로에게 삥을 뜯을려는 아마존과 소서리스. 지들 힘으로 안될 것 같아 아는 오빠를 부르고 있다.

기본 구조는 다음과 같다.
모든 플레이 가능한 캐릭터와 몬스터는 다 같은 캐릭터란 클래스에서 출발한다.
캐릭터는 기본적으로 HP, MP가 있을 것이고 능력치를 가질 것이다. 공격도 하고 속성도 가지고 머 암튼 생각해보면 엄청 비슷하다. 그래서 CCharacter에서 CMonster와 CPlayerCharacter가 파생되었다.

시작!

시작!

그런데... 뭔가 아리까지한 것이 생긴다.
잘 생각해보면, 또한 ACT1의 용병 Rogue나
엉덩이 탱탱한 비키니 입고선 활쏘고 죽창들고 달리던 언냐들, 사실 아마존이 하는 짓이랑 똑같지 않은가?


이거 적은 적이되, 속성은 플레이어와 비슷하거나 똑같다는 사실을 느끼게 된다.
이거 아주 중요한 발견이다. 즉, 단순히 몬스터와 플레이어를 나눠선 안되겠단 생각이 든다.

개조하자~

개조하자~

자...그런데 이넘의 아마존, 어세신, 소서리스는 적이 될수도 있고 플레이어가 될 수도 있겠다.
그리고 게임의 가치를 더하는 아이템은 어떻게 처리할 것인가?
최상단 클래스는 CCharacter가 굳건히 자리를 지킬 것인가?

포스트가 너무 길게 쓰니 립흘을 안달아줘  독자들의 집중력을 위해 오늘은 여기까지!

다음 시간에는 캐릭터와 아이템에 도전해보자!

Trackback 0 Comment 0