잉여들을 위한 클래스설계 이야기 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년차도 잉여취급한다.

사실 어떤 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가 굳건히 자리를 지킬 것인가?

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

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

출처 : http://rhea.pe.kr/238