[Archive] 강좌게시판
[myLV.net 집필진 강좌 – 웅킹킹킹]
안녕하세요. 웅킹킹킹 입니다.
이번 시간부터 Ladder Game 예제를 천천히 한 단계씩
나아갈 예정입니다.
지난 시간에 Actor Framework로 이루어진 Ladder Game의
UI와 UML을 소개해드렸는데요.
Actor Framework에서는 “UML”이 중요합니다.
설계된 OOP 구조는 변경하기가 너무 어렵기 때문이죠.
그래서 제가 지난 시간 UML을 먼저 소개해드리고
UML을 꼼꼼하게 살펴보는 것을 추천드렸습니다.
부디 UML을 살펴보셨기를 바라면서
이번 시간은 Ladder Game의 UML에 대해서 설명해드릴게요.
OOP기반의 Actor Framework는 프로그래머의 생각에 따라
프로그램의 구조가 매우 많이 달라집니다.
같은 내용이라도 말이죠.
물론 QDMH도 마찬가지이겠지만..
그래도 상태머신에 바탕을 두고 있는 QDMH보다는
프로그래머의 생각에 따라 전혀 다른 방식으로 개발됩니다.
우선 UML을 보시면
Ladder Game, Runner Manager, Runner 총 3개의 클래스가
Actor 클래스로부터 상속받아서 Actor 클래스가 됩니다.
Ladder Map 클래스는 상속 받지 않았기 때문에
일반 클래스 입니다.
Actor Class : Ladder Game, Runner Manager, Runner
Class : Ladder Map
제가 왜 이렇게 설계를 했을까요?
우선 Ladder Game에서 가장 중요한 인자는
사다리를 따라서 움직이는 녀석이겠죠?
Runner!!
저는 Runner를 Ladder Game에서 필요한 만큼 등장시키고 싶었어요.
즉 3인용이면 3개의 Runner,
5인용이면 5개의 Runner.
일반적인 QDMH나 상태머신에서는
시작 위치 설정 -> 사다리 타기 -> 결과
이렇게 대부분 3단계의 상태로
만들어질 거라고 생각됩니다.
이렇게 프로그램이 구현된 상태에서
만약 여기서 5인기준으로 5명의 주자를 동시에
사다리를 타게 하려면 어떻게 해야 할까요?
구현이 매우 힘들어지거나 새로 프로그램을
만들어야 할 것입니다.
아마 저라면 QDMH 기준으로 소비자 루프를
4개 더 복사해서 그 소비자 루프를 제어하기 위한
Queue를 더 생성하겠죠.
생각만해도 진절머리가 나네요..
어쨌든 저는 Ladder Game의 확장성을 고려해서
Runner 액터 클래스를 3인용이면 3개를 호출하고
5인용이면 5개를 호출하는 구조로 만듭니다.
그럼 Runner 액터 클래스를 관리할 필요가 생깁니다.
Runner를 호출해야 할 개수를 정하고
역할이 끝난 Runner를 퇴장시키는 관리자 역할이 필요로 합니다.
그래서 Runner 관리자역할로
Runner Manager 액터 클래스를 생성합니다.
그리고 이 모든 액터 클래스를 관리하고 Ladder Game의
전체적인 책임을 맡을 사장급 Ladder Game 액터도 생성합니다.
Ladder Game 액터 클래스가 Root Actor 입니다.
Ladder Map 클래스는 행위(Method)를 하지 않아요.
사다리 맵의 정보만 제공할 뿐입니다.
그래서 굳이 Actor 클래스일 필요가 없습니다.
그래서 Ladder Map의 정보만
사다리를 타야 할 Runner 액터 클래스와
결과 값을 표현하는 Ladder Game 액터 클래스에게 제공합니다.
그럼 이제부터 자세하게 클래스의 역할을 짚어보겠습니다.
먼저 Ladder Game 액터 클래스 입니다.
Ladder Game을 총괄하는 사장급입니다.
즉, Root Actor 입니다.
* 클래스를 읽는 법은 저의 지난 강의를 참고해주세요.
“Launch Runner Manager” 메소드로
Runner Manager 액터 클래스를 호출할 수 있습니다.
“Create Users” 메소드로
2 ~ 5인 중 유저를 설정할 수 있습니다.
나머지 “Update ~~” 메소드는 Ladder Game의 진행상태를
그때 그때 업데이트해서 보여줍니다.
부장급인 Runner Manager 액터 클래스를 호출하고
고객인 우리에게 결과 값을 보여주는 역할을 하는
사장급 입니다.
사장급 역할을 하는 것 같죠?
Runner Manager 액터 클래스 입니다.
“Create Runner” 메소드는 필요한 만큼 Runner 액터 클래스를 호출합니다.
“Start Runner” 메소드는 Runner 액터에서 일을 시킵니다.
사다리를 타라고..
“Delete Runner” 메소드는 일을 다한 Runner 액터에게 퇴근을 명하죠.
Runner Manager 액터 클래스는 “Manager” 답게 일을 수행합니다.
마지막 액터 클래스인 Runner 액터 클래스 입니다.
“Departure” 메소드로 사다리를 타기위해서 출발합니다.
“Run” 메소드는 도착할 때까지 사다리를 계속 탑니다.
“Arrive” 메소드는 도착해서 이제 결과 값을 알려주고
퇴근시켜달라고 요청하죠.
말단 직원급 액터 클래스입니다.
우리네 인생 같네요.. ㅠㅠ
Ladder Map 클래스는 액터 클래스가 아닙니다.
생물이 아닌 무생물이죠.
메소드를 보시면 아시겠지만
Ladder Game이 시작 될 때 사다리 맵을 만들고
맵을 읽어서 Ladder Game 액터 클래스와
Runner 액터 클래스에게 정보 전송만 합니다.
이렇게 단순한 일을 하는 클래스를 굳이 직원급인
액터 클래스로 승급시켜서 월급을 줄 필요는 없겠죠?
액터 클래스가 되면 컴퓨터의 리소스라는 월급을 가져가거든요.
글을 쓰다 보니 우리가 살아가는 조직체계로 설명을 해드렸네요.
이렇게 설명하는 것이 더 이해가 될 거라고 생각이 드네요.
단순한 Ladder Game이지만
이렇게 OOP기반의 Actor Framework는 설계 방식이
상태머신이나 QDMH처럼 딱딱하게
상태전이가 아닙니다.
“A를 수행하고 B가 도출되면 C를 수행하라.”
라는 방식이 아닙니다.
프로그램이지만 해당 역할에 따라 액터 클래스에게
생명을 부여하는 느낌이 듭니다. 저는.. 이상하게..;;
그래서 OOP 관련 서적을 찾아보면
“인문학적” 이라는 단어가 자주 나와요.
이제 프로그래머가 인문학도 공부해야 합니다. ㅠㅠ
아무튼 저는 Ladder Game을 이렇게 설계했구요.
다양한 방식의 설계법이 있을 수 있습니다.
자기만의 UML을 만들어보세요.
Actor Framework를 공부할 때
큰 도움이 될 거라고 저는 생각합니다.
