디자인패턴 해석자(Interpreter)

황제낙엽 2007.11.25 11:42 조회 수 : 89 추천:89

sitelink1 http://blog.naver.com/gamediz/20043075803 
sitelink2  
sitelink3 http://1 
extra_vars4 ko 
extra_vars5  
extra_vars6 sitelink1 

해석자(Interpreter)

1)    정의

언어에 따라서 문법에 대한 표현을 정의한다. 또 언어의 문장을 해석하기 위해 정의한 표현에 기반하여 분석기를 정의한다.

 

해석자 패턴은 게임개발 전반에 걸쳐서 굉장히 많이 사용되는 패턴중에 하나이다.

쉽게 말해 해석하기 위한 패턴으로 어떤 규칙을 해석해서 리소스를 줄이고, 개발 효율성을 높이는 패턴이라고 할 수 있다.

게임개발에 사용되는 스크립터, , 언어 컨파일러 등을 해석자라고 할 수 있다.

해석자는 굉장히 명확한 개념이기 때문에 해석자를 개념자체를 이해하는 것 보다는 해석자패턴을 사용했을 때 얻는 이익? 이나 해석하지 않으면 어떻게 될까? 라는 식의 접근을 통해 언제, 어떻게 해석자를 사용하면 좋을지에 대해 고민해보는 게 더 많은 것을 얻을 수 있다.

 

2)    예제

이런 문장이 있다고 해보자. (이건 GOF가 아닌 딴 책에 나온 예제이다)

 

오리가 뒤뚱뒤뚱 걷다.                                                               

 

이 문장을 프로그램에 넣고 실행시키면 오리가 나와서 뒤뚱뒤뚱 걸어갈 것이다.

즉 실제 프로그램에서 저 문장을 엔진에 통으로 등록 시켜서 결과물을 뽑아 낸 것이다.

하나일 때는 그럴 수 있는데 만약에 이런 경우라면 어떨까?

 

오리가 뒤뚱뒤뚱 걷다.                                                               

오리가 팔랑팔랑 걷다.

오리가 살랑살랑 걷다.

오리가 뒤뚱뒤뚱 뛰다.

오리가 깡충깡충 눕다.

 

뭐 이런식으로 문장이 많아진다면, 5개의 문장을 엔진에 등록시켜서 사용을 해야 하며, 문장이 추가 될 때 마다 엔진에 추가되기 때문에 엔진에 부하도 많이 걸리고 같은 부분이 반복되기 때문에 리소스의 손해도 있을 것이다.

 

그럼 이러면 어떨까?

위의 문장은 보다시피 3가지 구조로 이루어져 있다.

오리가 뒤뚱뒤뚱 걷다.                                                               

[누가] [어떻게] [행동]

 

위의 3가지 구조를 개별로 객체화 해서, [누가], [어떻게], [행동]으로 나눠서 설계를 하면, 엔진 입장에서는 앞으로 모든 문장을 신경쓰지 않고, [누가], [어떻게], [행동]으로 모듈화 해서 처리를 하게 된다. 이렇게 문장을 개별 객체화 한 후에 모듈화 해서 해석하는 방식을 해석자 패턴이라고 한다.

 

3)    /단점

해석자 패턴의 단점은 설계 자체의 난이도가 상승하는 것이다.

3가지 구조만 나와 있지만, 실제의 게임은 그렇게 단순하지 않기 때문에 저러한 3가지 위에 다양한 예외 처리들이 입혀지게 되고, 이렇게 생겨난 예외 처리들을 모두 고려해서 설계를 해야 하기 때문에 굉장히 높은 난이도를 필요로 한다. 또한 설계를 아무리 잘한다고 해도 엔진이 가진 한계성에 따라 구현여부가 결정되기도 한다.

 

해석자 패턴의 장점은 다들 눈치 챘겠지만 이런 것들이다.

-      조합으로 다양한 것들을 창조한다.

-      리소스를 절약한다.

-      정해진 규칙안에서 자유도를 발휘할 수 있다.

-      체계가 잘 잡혀 있으면 업무 효율이 기하 급수적으로(100배이상?) 증가한다.

 

특히나 업무 효율 부분은 엄청난 효과를 볼 수 있는데, 만약 해석자 패턴이 없어서 스크립트나 게임툴이 없다고 해본다면, 기획자나 그래픽 디자이너가 무엇 하나를 테스트하기 위해서는 이런 과정을 통할 수도 있다.

 

    기획자 A가 작업물을 완성한다.

    그래퍼 B씨에게 프로그램에서 돌릴 수 있는 포멧으로 변경해달라고 요청한다.

    기획자는 B씨에게 받은 포멧이 변경된 작업물을 들고 프로그래머 C씨에게 가서 작업물을 게임에 띄워줄 것을 요청한다.

    프로그래머 C씨는 하던 작업을 멈추고 자신의 컴퓨터에 작업된 것을 띄운다.

    기획자 A씨는 작업물이 제대로 되어 있는지 확인하고 수정할 부분을 체크해 간다.

    다시 수정할 일이 생기면 1~5번을 반복한다.

 

실제로 최근에는 덜하지만 과거에는 이러한 프로세스를 쓰는 경우가 비일비재 했다.

만약 그래퍼 B씨가 자리에 없거나, 프로그래머 C씨가 자리에 없다면 기획자 A씨는 작업을 물을 완성해도 무엇을 어찌할 방법이 없는 것이다. (프로그래머 C씨는 또 무슨 죄란 말인가? A씨가 테스트 할 때마다 자리를 양보해야 하니; )

 

이러한 예로 봤을 때 해석자 패턴을 잘 쓰게 되면, 기획자 A씨가 자신의 작업물을 자신이 맞는 포멧으로 변경 시켜서 게임에 직접 띄운 후에 자신이 수정할 수도 있으면 되는 것이다. 하루에 A씨가 수정을 10번 한다고 하면이 작업을 10일만 한다고 해도, 정말 100배 이상의 효율을 갖게 되는 것이다.

 

이렇게 해석자는 참 많이 쓰인다. 요즘 게임업계의 추세가 기획자가 늘어나고 프로그래머가 줄어드는 추세에 있는 것도 해석자 패턴을 과거보다 좀 더 적극적으로 쓰기 때문에 일어난 변화라고 할 수 있다. 과거에는 프로그래머가 하던 것들일 이제 최초에 스크립트나 툴로 규칙을 정의해서 기획자가 바로 제어할 수 있게 만들어 놓았기 때문에 생긴 변화다.

 

이처럼 패턴을 알면 참! 편할 수 있다. ~~.