게임프로그래머가 되기위해 5

 
5. 같이 작업 하기 위해서 "디자인 패턴 & UML"
 
계속 되는 OOP를 향한 노력과 답답함.
 
이제는 게임 개발을 할 수 있고, 또 개발해봤다면 점점 더 강력한 객체지향 프로그래밍을 원하게 된다.
 
하나의 게임을 만들고 다른 게임을 만들때 완전히 같은 기능의 부분을 "복사와 붙여넣기"를 해서 프로그래밍을 하게되고[이게 말이 쉽지 피로도가 장난아니다.], 또 처음에 생각하지 못했던 기능의 추가나 생각하지 못했던 버그들 때문에 Code 전체를 뜯어 고친 경험이 몇번씩은 있었을꺼라 단언한다.
 
스스로 객체지향 프로그래밍이라고 생각하면서 짰지만 새로운 기능을 추가시키거나 같이 작업할때 걸리는 팀원들간의 싱크로 나이징 문제, 자신이 생각했던 디자인을 이해시켜야 한다거나 또 혹은 남이 생각했던 디자인 부분을 이해해야 하는것 들은 보통일이 아니다.
 
또한 서로 다른 마인드 때문에 하나의 디자인을 보고 하는 격론등 어떤의미에서는 비 생산적이며 이는 프로그래머를 지치게 만들고, 그만큼 작업에 걸리는 시간이 많아 진다.
 
만약 팀장이 있다면 어느정도 해결되겠지만 허접한 팀장을 만났다면? 비용과 스스로의 노가다를 줄이기 위해 설득시켜야 하지만 그것이 참 난감하다.
 
처음 OOD(Object Oriented Degine)를 하게되면 생기는 이런 문제들은 크게 위에서 말한것 처럼 크게 "팀원간의 싱크로 문제"와 "더 좋은 디자인에 대한 논쟁"이 문제로 남게된다.
 
물론 이것들에 대한 문제를 해결하는 방법은 당연히 있다. 벌써 객체지향이라는 개념이 나온지 10년도 넘었고 해외의 유수에 대단한 프로그래머들이 이런 문제를 그냥 놔뒀을리 만무하지 않는가?
 
 
팀원간의 싱크로 문제의 해결
 
우리들의 똑똑한 외국 프로그래밍 학자들은 이런 문제를 해결하기 위해 UML 이라는것을 만들었다. UML 이라함은 Unified Modeling Language 라 하여 1997년 표준이 완성된 언어 이다.
 
해석 그대로 이해하면 된다. 통일된 모델링 언어. 말그대로 어떤 언어로 프로그래밍을 짜던지 이걸로 모델링 하라는 의미다.
 
뭐 단순하게 OOD를 위해서 태어낳느냐 라고 하면 그것은 아니다. 이것은 소프트웨어 개발의 전체적인 부분을 "요구 분석", "시스템 설계", "시스템 구현"등을 할 수 있도록 만든것인데, 이것은 객체지향을 기반으로 하고 있다. 그렇기 때문에 UML을 가지고 OOD를 할수 있다.
 
UML은 Use Case Diagram, State Diagram, Sequence Diagram, Collaboration Diagram, Activity Diagram, Component Diagram, Depolement Diagram  이 존재 한다. 각각의 다이어그램의 존재이유는 뚜렷하며, 100% 모두 게임 프로그래밍에서 사용할수 있는지는 의문이지만(내가 UML을 잘 못해서 그런것일꺼다.) 소프트웨어 개발을 기본으로 생각했을때 각각의 다이어 그램들은 굉장히 필요하다.
 
각각의 존재의 이유는 책찾아봐라.(사실 설명하기 너무 복잡하고 길어진다. -> 무책임 '')
 
그렇지만 실제로 게임 개발도 소프트웨어 개발의 범주에 속하기 때문에 나 역시 굉장히 많은 다이어그램을 이용하고 있다. Use Case를 이용해 사용자와 사용자의 요구를 파악하고 도표화 시키며, State Diagram 으로 Class Degine 을 하고, Class 상태변화를 Sequence Diagram으로 표시하며, Activity Diagram을 통해서 프로그램의 흐름을 정의한다.
 
UML은 단순하게 Class Degine에만 사용하더라도 그 상관 관계를 정확하게 파악할수 있기 때문에 굉장히 좋다. 즉, 서로 UML을 하고 있다면 상대방의 디자인을 손쉽게 빠르게 알아볼수 있고 문제점들을 지적해 낸다거나, 필요한 부분을 보충 할 수 있다.
 
UML에 관한책은 많이 나와있지만, 인포북에서 나온 "UML 객체 지향 설계 (제2판) - 초보자를 위한 " 이 책이 괜찮다고들 많이 하고(초보자들이 보기엔) 나도 아직 보지는 않았지만 인사이트 에서 나온 UML, 실전에서는 이것만 쓴다!  이 책도 좋은 평가를 얻고 있다.
 
 
좋은 디자인 논쟁의 해결
 
좋은 디자인 논쟁은 사실 생산적이라고 할수 있다. 더 좋은 디자인에 대한 토론은 정말로 더 좋은 디자인을 탄생시키고, 더 멋진 OOP를 완성시킬수 있는 좋은 행위이다.
 
그렇지만 그것은 시간남을때 하는것이 좋다. 또 후회 하지 않으려면 디자인 패턴에 대해서 공부한후에 해도 늦지 않다.(나는 엄청 후회 했다.)
 
대학교 1학년과 2학년때 나의 프로그래밍적 최고의 화두는 어떻게 하면 더 나의 구라 객체지향 프로그래밍을 진짜 객체지향프로그래밍으로 바꿀까 였다. 가장 도움이 많이된 부분은 MFC였지만 실제로 그것으로는 부족했다. 고민과 토론 그리고 얻어낸것은 나름대로 괜찮은 디자인들이였지만 언제나 결정적인 순간에 객체들이 꼬여서 위에 말했던 문제에 봉착했다.
 
그리고 디자인 패턴에대해서 공부한후, 처음에는 광명을 나중에는 좌절을 맛봤다.(좌절은 나의 고민과 토론은 헛된것이 아닐까 하는..)
 
프로그래밍은 어플리케이션을 만드는 것이다. 궁극적인 목적은 그것이다. 그것을 위해 우리는 OOP도 하는것이고 OOD도 하는것이고 CBD(Component Base Degine)도 하는것이다.
 
더 멋진 디자인이 되기 위해서 토론하는것은 좋지만 그것이 어플리케이션을 제작하는데 방해가된다면 그건 순리에 맞지 않다고 보면 된다.
 
디자인 패턴은 우리가 정력을 낭비하지 않고 프로그래밍에 본질에 집중할수 있게 도와준다. 이미 검증되어있는 객체 지향 디자인들의 패턴을 따로 빼서 정리해놓은것이다.
 
디자인 패턴을 선택한후 프로그래밍을 하면 최소한 비 객체지향적이거나 (더 좋은 패턴이 있을지도 모르지만 ) 일반적 객체지향론(은닉성, 다형성등)에 어긋나지 않는다.
 
만약 팀장이 디자인 패턴을 모른다면 당당히 이미 검증되어 있는 내용으로 상대를 압도할수도 있는 좋은 방법이 될것이다.
 
책은 두말 없이 "GOF 의 디자인 패턴" 이 책을 추천한다.
 
책을 보면 어떤 식으로 어떻게 패턴을 이용하는지도 정확하게 나와있다. 간단히 설명하자면 자신이 패턴에 대해서 숙지하고 있다가 UML로 Use Case 등을 만들며 거기에 적당한 패턴을 찾아낸후 적용시키면된다.(이 얼마나 편한가!)
 
여담으로 1995년에 출판된 이책은 한국에 2002년에나 번역되었다. 한국이 얼마나 소프트웨어 시장에서 허접한지를 또 얼마나 영어를 공부해야 하는지를 여실히 보여준다. 우리는 이거 모르고 OOP해보겠다고 깝치고 있을때, 그넘들은 이것을 기반으로 더 좋은것들을 연구하고 있지 않았겠는가!
 
최근에는 경향이 좀 낳아지긴 했지만 그래도 최소 1년은 기다려야 번역본이 나오니 답답할뿐이다.[우워! 영어공부하자.]
 
 
그외에..
 
이런 것들은 첫강에 말했던 프로그래머로써의 자세 정도로도 설명 할 수 있다.
 
그렇니까 "프로젝트시 최대한 검증되어있는것을 이용한다." 라는 자세 말이다. UML과 디자인패턴 둘다 그런 의미로 사용하면 더 좋다.
 
각각의 다이어그램을 보여주고 설명하고 싶지만 이런것이 있고 이런것을 공부해야 한다는것에대한 방향 제시로 이 글은 마치는것이 더 효율적인것 같다. (사실 시스템 민지 얼마 안되서 로즈도 Visio도 안깔려 있어서 귀찮다. 퍽퍽!)
 
디자인 패턴은 한번 손으로 정리해놓은것이 있으니(그래봤자 GOF꺼 옮겨 놓은것이지만) 붙여 넣는다.
 
참고로 원론 적인 이야기로 뿐이 흐를수 없는것은 굉장히 민감한 주제인데다가 나도 아직 허접해서  잘모른다-_-!
 
----------------------------------------------------------------------------------------
 
디자인 패턴
 
1. 생성 패턴(Creational Patterns)

Abstract Factory : 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할수 있는 인터페이스를 제공한다.
 
Builder : 복합 객체의 생성 과정과 표현방법을 분리함으로써 동일한 생성 공정이 서로 다른 표현을 만들 수 있게 한다. (다형성을 이용한 생성?)
 
Factory Method : 객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만들 클래스의 결정은 서브클래스가 한다. Factory Method 패턴에서는 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룬다.
 
Singlenton : 클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할수 있는 방법을 제공한다.
 
 
2. 구조 패턴 (Structural Patterns)

Adapter : 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환한다. Adapter 패턴은 호환성이 없는 인터페이스 때문에 함께 사용할수 없는 클래스를 개조하여 함께 작동하도록 해준다.
 
Bridge : 추상화와 구현을 분리하여 각각을 독립적으로 변형 할 수 있다.
 
Composite : 부분-전체 계층을 나타내기 위해 복합 객체를 트리 구조로 만든다. Composite 패턴은 클라이언트가 개별적으로 객체와 복합 객체를 모두 동일하게 다루도록 한다.
 
Decorator : 객체에 동적으로 책임을 추가 할 수 있게 한다. Decorator 패턴은 기능의 유연 한 확장을 위해 상속 대신 사용할수 있는 방법이다.
 
Facade : 서브 시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터페이스를 제공한다. Facade 패턴은 서브 시스템을 좀 더 사용하기 편하게 하기 위해서 높은 수준의 인터페이스를 정의한다.
 
Flyweight : 객은 크기의 객체들이 여러개 있는 경우, 객체를 효과적으로 사용하는 방법으로 객체를 공유하게 한다.
 
Proxy : 다른 객체로의 접근을 통제하기 위해서 다른 객체의 대리자 또는 다른 객체로의 정보 보유자를 제공한다.
 

행위 패턴(Behavioral Patterns)

Chain of Responsibility : 요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여함으로써 요청하는 객체와 처리하는 객체 사이의 결합도를 없애려는 것이다. 요청을 해결할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달한다.
 
Command : 요청을 객체로 캡슐화 함으로써 서로 다른 요청으로 클라이언트를 파라미터화하고, 요청을 저장하거나 기록을 남겨서 오퍼레이션의 취소도 가능하게 한다.
 
Interpreter : 언어에 따라서 문법에 대한 표현을 정의한다. 또 언어의 문장을 해석하기 위해 정의한 표현에 기반하여 분석기를 정의한다.
 
Iterator : 내부 표현 방법을 노출하지 않고 복합 객체의 원소를 순차적으로 접근할 수 있는 방법을 제공한다.
 
Mediator : 객체들 간의 상호작용을 객체로 캡슐화 한다. Mediator 패턴은 객체들 간의 참조관계를 객체에서 분리함으로써 상호작용만을 독립적으로 다양하게 확대 할수 있다.
 
Memento : 캡슐화를 위배하지 않고 객체 내부 상태를 객체화 하여, 나중에 객체가 이 상태로 복구 가능하게 한다.
 
Observer：객체 사이에 일 대다의 종속성을 정의하고 한 객체의 상태가 변하면 종속된 다른 객체에 통보가 가고 자동으로 수정이 일어나게 한다.
 
State: 객체의 내부 상태에 따라 행위를 변경할 수 있게 한다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.
 
Strategy : 알고리즘군이 존재할 경우 각각의 알고리즘을 별도의 클래스로 캡슐화 하고 이들을 상호 교환 가능한 것으로 정의한다. Strategy 패턴은 클라이언트에 영향을 주지 않고 독립적으로 알고리즘을 다양게 변경할수 있게 한다.
 
Template Method : 오퍼레이션에는 알고리즘의 처리 과정만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스에 정의한다. Template Method 패턴은 알고리즘의 처리 과정은 변경하지 않고 알고리즘 각 단계의 처리를 서브클래스에서 재정의을 할 수 있게 한다.
 
Visitor : 객체 구조의 요소들에 수행할 오퍼레이션을 표현한 패턴이다. Visitor패턴은 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 한다.