2개월차의 시작, 객체 지향 프로그래밍?

사실 2개월차의 진정한 목적은 클래스이지만 클래스를 다루기 전에 클래스는 객체 지향 프로그램이기때문에 객체 지향 프로그래밍이 뭔지부터 말해야겠다.

 

일단 프로그래밍에는 절차지향과 객체지향이 있다.

 

절차 지향은 말 그대로 내가 코드를 쓸때 해야하는 동작의 순서대로 적으면 되는것이다.

 

쥬신에서는 숙제로 "텍스트RPG"게임을 만들으라고 하는데(누가 게임학원 아니랄까봐 숙제도 게임형식이다.), 하는 행동은 동일하다.

텍스트 RPG란 콘솔에 아무런 이미지 없이 그저 글자들만으로 진행하는 게임이다.

 

처음 이 숙제를 받은것이 구조체를 배운 뒤였는데

프로그램을 시작하면 캐릭터를 선택하고 전투필드에 진입하고, 몬스터의 난이도를 설정한 뒤 그 몬스터와 싸우는 형태이다.

이제 각자 이해한 대로 구조체를 이용하여 텍스트RPG를 만들어 오면 이제 다음엔 동적배열을 배워서 플레이어와 몬스터를 동적할당한 뒤, 필요시점에 할당, 해제하는 과정을 추가하여 다시 만든다.

그리고 파일 입출력을 배우고서는 세이브, 로드를 만들어 추가한다.

 

이런식으로 그날 배운 요소를 사용하여 동일한 과정을 거치는데 이렇게되면 그 과정을 숙달하는데 도움이 되었다.

어쨌든 내가 말하고 싶은건 모든 프로그램에는 순차가 있다는것이다.

 

게임을 시작하여 캐릭터를 만들고 난 뒤, 훈련장에 들어가 몬스터를 만들고, 몬스터와 싸우고 몬스터를 잡으면 다시 몬스터를 만들어 싸우고, 플레이어가 죽으면 다시 체력을 채우고 훈련장 바깥으로 돌아간다.

이를 한국어코드로 만들면 다음과같은 구조일것이다. 오류가 있을지 모르지만 중요한건 코드의 구조이다.

 

무한 반복{
    게임시작

    플레이어가 없으면{
        플레이어의 직업과 능력치를 고른다.
        선택에 맞는 플레이어를 만든다.
    }
	플레이어가 있으면{
    	싸움터에 갈지 게임을 종료할지 정한다.
        
        싸움터를 선택했으면{
        	몬스터의 능력치를 고르고 그에 맞는 몬스터를 만든다.
            
            반복{
            	몬스터와 싸운다.
                
                몬스터가 죽으면{
                	동일한 능력치의 새로운 몬스터와 연이어 싸움을 진행한다.
                }
                플레이어가 죽으면{
                	체력을 최대로 채운다.
                	처음으로 되돌려 훈련장,종료를 선택한다.
                }
            }
            
        }
        종료를 선택했으면{
        	종료한다.
        }
    }
    
}

물론 이 한국어코드는 함수도사용하지 않았고 대충 짰기 때문에 이해하기 힘든 코드이기도 하다.

하지만 만약 함수를 사용했다면 프로그램이 현재 어느 위치를 읽는지 찾기 위해 코드를 올렸다 내렸다 하며 찾아야하니 더 번거로울것이다.

 

내가 말하고싶은건

절차지향은 하고싶은 행동이 있으니 그 순서대로 코드를 적고 분기문과 반복문을 이용해 코드의 흐름을 조절하는것이다.

이 경우 만일 오류가 나더라도 어느부분에서 오류가 났는지 찾기 쉽지 않으며, 코드의 흐름을 한눈에 보기 어려워 각 변수에 어느시점에 어떤 값이 입력되는지 알아보기가 번거롭다.

 

만일 몬스터와 싸우는데 어느시점부터 소멸하지 않고 -인 체력을 가지고 계속 싸우게 된다면 몬스터에게 잘못된 데이터가 들어간것이 몬스터 난이도를 선택했을때의 문제인지, 싸움을 시작했을때인지 죽이고 나서 새로운몬스터를 만들때의 문제인지 한눈에 보기 어렵다.

 

내가 짠 코드임에도 어려운데 만일 게임회사에 취업했는데 절차지향적 코드에서 문제가 생겼다면, 그리고 정작 그 코드를 짠 사람이 퇴사한 이후라면 이걸 찾아내 고쳐낼 수 있겠는가??

아마 다 지우고 새로 짜는게 나을지도 모른다.

 

이렇게 협업적 측면에서 절차지향은 불리한 면이 있다.

 

그래서 나온것이 객체 지향 프로그래밍이다.

 

 

객체 지향프로그램을 이야기하기 전에 객체에 대해 먼저 알아보겠다.

 

객체란 무엇인가?? 뭔진 모르겠으나 대충 머릿속에 뭔가 떠오르긴 한다.

 

다음 검색의 경우 객체를  "주체로부터 독립되어 있는 인간의 인식과 실천의 대상" 이라고 말한다. 말이 더 어려워졌다. 주체는 또 뭔가??

 

선생님이 뭐 북한의 주체사상 뭐시기 하며 객체를 설명했는데 난 단순히 이렇게 정리하고싶다.

 

객체="명사로 표현될 수 있는 모든것"

 

단순히 프로그램에서의 정의이다. 다른데가서 객체란 명사에요!!하면 이상한눈으로 쳐다볼지도 모른다.

객체가 주체로부터 독립된 인식과 실천의 대상인데 프로그램을 짜는사람의 입장에서 이미 게임내 캐릭터가 프로그래머가 아니기 때문에 모든것이 객체가 된다.

 

위의 텍스트RPG에서 메인캐릭터는 객체이다(게이머 입장에선 주체일지 모르지만 프로그래머 입장에선 객체이다.)

몬스터또한 객체이다.

흥미로운것은 훈련장이란 요소 또한 객체일 수 있다. 명사로 표현 가능하잖아.

 

이렇게 모든 명사를 객체라고 할 수 있다.

 

하지만 그렇다고 모든 명사마다 객체를 만들 수는 없을것이다. 몬스터가 한종류만 있는것도 아니고, 수백마리 있는 게임이라면 객체가 수백개가 된다는것이니 비효율적이다. 아이템의 경우 더하다. 부위별 아이템들이 백개씩 있다고 하면 그것들을 다 만들자면 몇백개의 객체들이 나온다.

 

그래서 우리는 추상화라는 과정이 필요하다.

 

 

추상화란 비슷한 특징을 가진것을 모은것이다. 추상화의 거장 파블로 피카소의 그림을 보자.

어찌보면 개떡같다고 느낄 수 있다. 톡특한 화풍인건 인정한다만 르네상스 시대의 초현실주의 그림에 비하면 너무 아이가 그린 그림같고 현실적이지 못하다.

 

하지만 피카소의 진면목은 그 그림을 보는 사람이 떠오르는것에 있다.

피카소의 "우는 여인" 그림을 보면 누구나 그 이상한 물체가 사람이고, 어디가 눈이고 어디가 코이고 심지어 울고 있다는 (적어도 행복한 상태는 아니라는) 사실을 알 수 있다. 제목을 보지 않고도 말이다.

 

이것이 추상화이다. 사람의 얼굴이라면 모두 가져야 하는 요소들이 무엇이 있을까?? 눈 코 입, 귀가 있을것이다. 더 디테일하게 들어가자면 턱선또한 얼굴이라면 가질만한 요소이고 눈썹, 앞머리 등이 있다. 이렇게 공통적인 요소들을 추출해내는것이 추상화 과정이다.

 

 

이 추상화라는 단어는 객체지향에 키워드가 되는 단어이다.

 

 

이쯤에서 클래스에 대해 설명하고 가보자.

 

클래스란 객체의 속성들을 추상화하여 정리해놓은것이다.

 

예를 들어 만일 내가 타임머신을 타고 조선시대에 가서 휴대폰을 여러가지 보여준다고 하자. 조선인들은 이것이 무엇인지 모를것이다. 그러니 최고의 과학자들이 나와 휴대폰을 가지고 실험을 할 것이다.

 

가로는 몇센치, 세로는 몇센치, 어떤 재질인지를 보고 이제 볼게 없으면 부숴도 볼것이다. 대충 어느정도 힘을 가하면 부숴지더라.

 

이것이 클래스의 데이터이다.

 

걱정말자 휴대폰은 무한히 있다.

 

그러다가 우연히 전원 버튼을 켜고 화면에 빛이 나올것이다. 소리도 나올것이다. 터치스크린을 만지니 빛이 나오는게 달라지고 어쩌다가 어플을 켜기도 하고 소리를 키우기도하고 하는 등 휴대폰으로 할 수 있는 일들을 알아낼 것이다.

 

그렇게 얻어낸 기능들이 함수이다.

 

그렇게 모든 데이터와 기능들을 모두 적어놓은것이 바로 클래스이다.

 

즉 클래스는 어찌보면 객체의 사용 설명서와 같다.

사용설명서를 보면 기기 제원부터 기능까지 모든 정보가 담겨있으니 크게 다를거 없다.

 

 

 

그러니 클래스의 추상화를 위해서는 이런 과정을 거칠것이다.

몬스터라면 가져야할 요소들 체력, 공격력, 이름이 대표적일것이고, 게임에 따라 타입(언데드인지 고블린인지 등), 혹은 속성, 이동속도등이 몬스터라면 가져야하는 요소(데이터)들일것이다.

 

그리고 몬스터라면 가져야하는 기능들이 있을것이다. 몬스터가 공격당했을때 체력을 깎는것, 몬스터가 공격했을때의 데미지, 몬스터가 죽었을때 해야할 행동

이것들이 몬스터라면 가져야할 기능(함수)일 것이다.

 

 

이렇게 공통된 요소들을 가질만한것을 모아 이것은 몬스터클래스 라고 구분할 수 있을것이다.

 

 

그리고 그 객체 간의 대화(상호 작용)를 통해 프로그램이 작동하는 것이 바로 객체 지향 프로그래밍이다.

 

즉 캐릭터가 훈련장에 가면 캐릭터의 정보가 훈련장에 들어가고, 훈련장은 몬스터 정보또한 가지고 있고 이제 몬스터와 싸우며 서로 상호작용이 일어나게 되는것이다.

 

 

설명이 복잡하다 느껴질 수 있다. 맞다. 또한 그런 프로그램을 만드는것도 매우 복잡하다.

이전엔 코드가 움직이는 흐름만 알면 통제가 되었는데 이번엔 각각의 객체가 어떤 움직임을 하는지 모두 조절해야한다.

 

그럼 왜 굳이 이런작업을 거칠까??

단순하다. 유지보수가 미친듯이 쉽다. 이전과 같은 예로 몬스터와 싸우다가 몬스터 데이터가 이상한 값을 가지고 있다면, 몬스터 객체로 가서 그 데이터를 조작하는 부분만 검사하면 된다. 플레이어 클래스나 훈련장 클래스는 특별히 안봐도 되는것이다.(경우에 따라 훈련장에 오류가 있을 수도 있지만 어차피 거기서 몬스터데이터가 조작되는 모든 경우는 몬스터클래스 내에 있을것이다.)

 

 

만일 내가 쓰던 휴대폰이 고장나면, 삼성이든 애플이든 내 기종(클래스)에 맞는 서비스센터로 가면 되는것과 같다.

 

이래서 객체지향을 설명하기가 쉽지 않다. 이미 우리는 객체 지향의 우주에 살고있기 때문에 어떻게보면 당연한 일인것이다.

 

이렇게 클래스를 설명하기 전 준비단계인 객체 지향 프로그래밍? 를 마친다.