이 책의 원서는 리치 슈페(Rich Shupe)와 지반 로서(Zevan Rosser)가 썼고 O’REILLY에서 지난 2008년에 Learning ActionScript 3.0: A Beginner’s Guide 라는 제목으로 출간되었습니다만, 우리나라에는 아직 번역서가 없던 참이었죠. 이 책을 ActionScript 3.0 Cookbook 과 액션스크립트 3.0 완벽가이드(콜린 무크 저, 원제 : Essential ActionScript 3.0)를 번역하셨던 송호철님이 번역하신다는 것이었습니다.

이 재미있고 흥미로운 요청에 당장 써드리겠다고 답장을 써 보내자 몇 시간 후에 편집자께서 편집중인 책의 pdf 파일을 보내주셨고, 며칠 후 몇 줄의 추천사를 (오탈자도 서너군데 찾아내어) 보내드렸던 것이 올해 추석 직전이었던걸로 기억합니다.

드디어 며칠전 이 번역서가 출간되었는데,^[01] 고맙게도 편집자님께서 추천사에 대한 답례로 책을 한권 보내주셨습니다.

포스트잇에 편집자님의 예쁜 글씨로 메모가 적혀있었습니다. "사랑해요 세계의끝님" (글씨 잘 안보이시죠? ^^)

액션스크립트 1.0과 2.0 시절로 개발하던 시기에는 콜린 무크의 Essential ActionScript (이하 EAS)시리즈가 절대 불변의 바이블 같은 느낌이었는데, 액션스크립트 3.0 으로 넘어가고 나서는 콜린 무크의 입지가 예전만 못하달까요, 한편으로는 1.0, 2.0 책이 워낙 명저(名著)다 보니 그에 비해 상대적으로 3.0 책이 묻히는 감도 있고, 결정적으로 EAS3.0 책은 완전히 초보가 읽기에는 뭐랄까 다소 추상적이고 난해한 부분도 부분부분 존재하는 그런 책이라는 느낌입니다. 물론 EAS3.0 책은 그 책의 서문에도 쓰여 있듯, 초보 개발자가 아닌 어느정도 수준 이상의 개발자가 읽으면 상당히 도움이 되는 책임에는 분명합니다.

어찌됐건, 그래서 액션스크립트 3.0 에 와서 초보 레벨의 레퍼런스 참고서의 자리는 바로 Learning ActionScript 3.0 이 차지하고 있었습니다. 번역 출간된 책은 500페이지 안팎의 분량이고, 번역서 치고는 그림으로 구성된 설명도 꽤 많아,(게다가 컬러로!!) 액션스크립트 API의 모든 내용을 속속들이 다루고 있지는 않으면서도, 초보 개발자들이 처음 공부를 시작할 무렵에 적합한 내용이라고 할 수 있습니다.
또한 DisplayObject 나 모션, 벡터그래픽같은 플래시적 특성도 꽤나 자세히 설명되어 있으므로, 다른 네이티브 언어를 다루다가 필요에 의해 액션스크립트를 다루게 된 개발자들에게도 도움이 될것 같습니다.

제가 쓴 추천의 글. 바로 아래쪽에는 열이아빠(이준하)님의 추천의 글도 있습니다.

이제 이 책이 번역되었으니 초보자에게 추천할 수 있는 레퍼런스 가이드가 한 권 더 늘었군요.

1. 책의 정식 출판일은 2011년 10월 7일 입니다.

어떤 것들이 초기화에 해당하는지 이해하고 있고, 그 순서를 정확하게 이해하고 있다면 컴파일 단계에서 에러의 숫자를 획기적으로 줄일 수 있기 때문에 이 초기화 단계를 이해하고 있는 것은 매우 중요합니다. 특히 여러분이 null 객체 에러를 자주 만난다면 반드시 이 포스트를 정독할 필요가 있습니다.

“그거라면 이미 다 알고 있는 내용이잖아!!” 라고 불평하시는 현업 개발자 여러분들에게는 보너스로, static 생성자함수(!?)를 소개합니다. 이런분들은 D-2.클래스 생성자 부터 읽으셔도 되겠습니다.

A. 클래스는 무엇으로 이루어져 있는가?

객체지향에서 클래스를 역할 관점으로 본다면, 객체를 만들어 내는 ‘설계도’, 또는 ‘틀’ 이라고 할 수 있습니다. 한편 프로그래밍의 구조적인 관점에서 클래스가 어떤 내용물로 구성되어 있는지 들여다 봤을때는 속성(변수)과 메서드가 보이게 되죠.

변수의 종류

• 인스턴스 변수(instance variable)
• 클래스 변수(class variable)
• 로컬 변수(local variable)

메서드의 종류

• 인스턴스 메서드(instance method)
• 클래스 메서드(class method)
• 로컬 메서드(local method)

우리는 위와 같은 여러 종류의 요소를 클래스 멤버(class member)라고 부릅니다. 이 포스트에서는 후자의 관점으로 봤을때의 클래스와 멤버들에 대해 이야기를 하게 됩니다.

B. 변수(variable)

B-1. 인스턴스 변수 (instance variable)

우리가 보통 private var, public var 와 같은 키워드를 붙여 선언하는 변수는 인스턴스 변수에 해당합니다. 인스턴스 변수는 클래스를 이용해 객체(instance)를 생성한 경우에만 의미를 가지게 되므로 이런 명칭이 붙었습니다. 너무나 당연하죠? 우리가 Product 라는 이름의 클래스에 정의한 name 이라는 이름의 인스턴스 변수는 아래와 같이 정의되고…

0
1
2
3
4

package{
	public class Product{
		public var name:String; // 인스턴스 변수 선언
	}
}

호스트코드에서 아래와 같이 인스턴스 화를 거쳐 객체를 생성한 이후, 그러니까 new Product() 를 한 순간 이후부터 name 이라는 속성을 사용할 수 있습니다.

0
1
2
3

var instance:Product
trace( instance.name ); // 이 시점에서는 객체가 생성되지 않은 시점이므로 속성에도 접근불가
instance = new Product(); // 객체 생성
instance.name = "시리즈1번"; // 속성에 접근 가능

B-2. 클래스 변수 (class variable)

그런데 클래스 변수라는 것이 있습니다. 우리 액션스크립트 동네에서는 클래스 변수를 static 키워드로 만들기 때문에 static 변수 라고도 부르지만, 이 포스트에서는 인스턴스 변수와 구별되는 변수라는 의미로 클래스 변수라고 표기하겠습니다.

클래스 변수는 객체가 아닌 클래스 자체에 속하기 때문에 객체를 생성하지 않고도 사용할 수 있습니다. 위에서 만든 Product 클래스에 클래스 변수를 추가해 볼까요?

0
1
2
3
4
5

package{
	public class Product{
		static public var type:String = "휴대전화"; // 클래스 변수 선언하고 값을 대입
		public var name:String; // 인스턴스 변수 선언
	}
}

클래스 변수는 클래스가 import 되어 있고 클래스의 이름만 알고 있다면 아래와 같이 인스턴스를 생성하지 않아도 아무곳에서나 사용할 수 있습니다.

0

trace( Product.type ); // 출력 : 휴대전화

B-3. 로컬 변수 (local variable)

또 한가지의 변수로는 로컬 변수(지역 변수)가 있습니다. 메서드 내부에서 사용하기 위해 선언한 변수를 일컫는 명칭이죠. 지역변수는 private, protected, public의 접근 제한자를 붙이지 못합니다. 접근 제한자들은 클래스 본문에 펼쳐 있는 멤버들만 사용할 수 있기 때문입니다.

0
1
2
3
4
5
6
7
8

package{
	public class Product{
		static public var type:String = "휴대전화";
		public var name:String;
		prublic function Product():void{
			var temp:String; // 로컬 변수 선언
		}
	}
}

로컬 변수는 객체 외부에서도 접근할 방법이 없음은 물론이거니와 클래스 내부에서도 메서드 외부에서 접근할 방법이 없습니다. 오로지 메서드 내부에서만 생성, 사용, 참조, 소멸 됩니다.

C. 메서드(Method)

C-1. 인스턴스 메서드 (instance method)

변수와 마찬가지로 private function, public function 등의 키워드로 정의되고 인스턴스화 되지 않으면 사용할 수 없습니다.

0
1
2
3
4
5
6

package{
	public class Product{
		prublic function doSomething():void{ // 인스턴스 메서드
			// 인스턴스 메서드 바디
		}
	}
}

C-2. 클래스 메서드 (class method)

변수와 마찬가지로 인스턴스 메서드에 static 키워드를 붙이면 클래스 메서드가 됩니다.

0
1
2
3
4
5
6

package{
	public class Product{
		static prublic function doSomething():void{ // 클래스 메서드
			// 클래스 메서드 바디
		}
	}
}

C-3. 로컬 메서드 (local method)

변수와 마찬가지로 메서드 내부에서 어떤 로직을 처리하기 위해 만들어 놓은 메서드 입니다. private, public 등의 접근 제한자를 붙일 수 없고, 로컬 메서드 내부에서의 this 는 인스턴스 메서드에서의 this 와 다른것을 가리킨다는 것에 주의해야 합니다.

0
1
2
3
4
5
6
7
8
9
10
11
12

package{
	public class Product{
		prublic function Product():void{
 
			function doSomething():void{ // 로컬 메서드
				trace( this ); // 출력: [object global]
			}
			doSomething(); //자신을 소유하고 있는 메서드 내부에서만 호출할 수 있음
			trace( this ); // 출력: [object Product]
		}
		doSomething(); // 에러!! 호출 불가
	}
}

또한 위와 같이 로컬 메서드에서의 this 는 [object global] 이 찍히므로 객체 내부의 인스턴스 변수와 메서드를 참조할 수가 없습니다.

D. 초기화 순서

자 이제 이 포스트의 핵심에 도달했습니다.
클 래스가 초기화 될때 가장 우선시 되는 순서는 클래스 멤버 입니다. 클래스 변수와 클래스 메서드가 가장 먼저 초기화 되는거죠. 그리고 변수가 메서드 보다 먼저 초기화 됩니다. 로컬 멤버들은 인스턴스 멤버들 내부에 속하기 때문에 당연히 인스턴스 멤버들이 초기화 된 후의 순서 입니다.

1. 클래스 변수
2. 클래스 메서드
3. 인스턴스 변수
4. 인스턴스 메서드
5. 로컬 변수
6. 로컬 메서드

충분히 예상 할 수 있는 결과네요. 그런데 우리가 알아야 하는건 이 순서 자체가 아니라 순서가 이렇게 됨으로서 발생하는 제한사항에 대해서 입니다.

D-1. 초기화의 상관 관계

생각해 볼까요?
클래스 변수가 가장 먼저 초기화 되기 때문에 클래스 변수, 즉 static 변수가 인스턴스 변수나 인스턴스 메서드를 참조하고 싶어도 걔네들은 아직 존재하지 않는 애들입니다. 클래스(설계도)는 있지만 객체는 아직 생성되기 전 시점이기 때문이죠.

클래스 멤버가 초기화 되는 시점에 클래스 내부에는 (같은) 클래스 멤버외에는 아무것도 없습니다.

초기화가 끝난 후에 인스턴스 멤버들이 모두 생성되고 나면 런타임에서 참조할 수 있을텐데도, 컴파일 과정에서 아예 막혀 있습니다. 따라서 클래스 멤버에서 인스턴스 전용 키워드인 this 를 사용하면 컴파일 에러가 발생합니다.^[01] 객체가 생성되지도 않았는데 객체를 참조하려 할때 발생할 수밖에 없는 런타임 null 객체 에러를 컴파일 타임에 미리 봉쇄해 버리는 거죠.

new 연산자를 이용해 객체가 생성된 이후에서야 인스턴스 멤버들이 등장합니다.

반대로 인스턴스 멤버를 초기화하는 시점에서는 이미 클래스 멤버들은 초기화가 끝나있는 상태이므로 인스턴스 멤버들은 얼마든지 클래스 멤버들을 참조할 수 있습니다. 물론 이때도 클래스 멤버는 인스턴스 멤버를 참조할 수 없습니다. (this 사용불가)

D-2. 클래스 생성자 #

우리가 흔히 생성자라고 부르는 함수는 인스턴스 멤버의 생성자 함수입니다. 호스트 코드에서 그 생성자 함수를 호출하여 인스턴스화(객체화)를 할 수 있게 되죠. 뭐, 생성자에 static 키워드가 붙어 있지 않는 것만으로도 그것이 인스턴스 멤버임을 쉽게 짐작할 수 있습니다. 또한 생성자 함수를 호출하여 인스턴스화가 진행됨과 동시에 초기화가 이루어지게 되므로 인스턴스는 생성자 함수를 통해 초기화를 한다고 볼 수 있습니다.

그런데 클래스 멤버의 생성자 함수가 존재한다는 것을 알고 계십니까? 그러니까 static 생성자 함수라고 할 수 있겠네요.

0
1
2
3
4
5
6
7
8
9
10
11
12

package{
	public class InitailizeTest
	{
		{
			trace( "static 생성자 초기화 블럭" );
		}
 
		public function InitailizeTest()
		{
			trace( "인스턴스 생성자 초기화 블럭" );
		}
	}
}

이런 코드를 보신분도 있을것이고 처음보는 분들도 계실겁니다. 위와 같이 class 바디에 아무런 키워드나 접근 제한자 없이 중괄호를 열면 클래스가 생성되는 시점에^[02] 자동으로 실행되는 영역이 됩니다. 비교를 위해 바로 아랫 부분에 인스턴스 생성자 함수를 만들어 놓았습니다.

옆 동네인 Java 동네 에서는 이와 같이 클래스 바디에 중괄호로 펼쳐 놓은 부분은 인스턴스 초기화 영역 입니다. 우리 ActionScript 동네와는 다르죠. Java 에서 클래스 초기화 영역을 구성하려면 아래와 같이 클래스 바디에 static 키워드를 먼저 쓰고 중괄호를 열어야 합니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13

// ActionScript 가 아닌 Java 코드 입니다.
class JavaInitializeTest {
	static{
		// Java 의 클래스 초기화 블럭
	}
 
	{
		// 인스턴스 초기화 블럭 (액션스크립트에서는 이 부분이 클래스 초기화 블럭)
	}
 
	JavaInitializeTest(){
		// 생성자 함수
	}
}

그럼 이 클래스 초기화로 무엇을 할 수 있냐면, 인스턴스 생성자 함수에서 초기화를 하던것과 같은 발상을 하면 됩니다. Product 클래스로 이야기를 끌어 나가고 있으니까 계속 덧붙여 나가볼까요?

위와 같이 static 변수에 초기 값을 할당한다거나 static 객체에 이벤트 리스너를 달아주는 등을 예로 들 수 있겠죠.
인스턴스 생성자에서 클래스 멤버들에 대한 참조가 가능하므로 인스턴스 초기화 단계로 넘겨서 클래스 멤버들의 초기화를 해도 문법상으로는 문제가 없긴 합니다만, 클래스 초기화가 필요했던 멤버는 클래스 초기화 영역에서 초기화를 끝내는게 올바른 방법 입니다. 이걸 인스턴스 초기화 단계로 끌고 내려가면 클래스 멤버쪽에서 어떤 행동이 다시 필요할때 에러가 생길 가능성이 높아집니다. 위에서도 썼듯이 클래스 멤버가 작동하는 시점에 인스턴스 멤버는 존재하지 않기 때문에 클래스 멤버가 참조해야 하는 인스턴스 객체는 null 입니다. 실제로 초기화 단계에서 static 멤버와 관련해서 일어나는 null 객체 에러의 대부분이 바로 이 문제 때문에 일어납니다. 제대로 이해하고 사용한다면 에러를 획기적으로 줄일 수 있겠죠?

지금까지 설명한 개념들을 하나의 예제 클래스로 만들어 보았습니다. trace() 출력되는 순서를 살펴보세요.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

package{
	import flash.display.Sprite;
 
	public class InitailizeTest extends Sprite
	{
		static private var sv:Object = { call:trace( "static 변수 초기화" ) };
		static private var obj:Object = getObject();
 
		static private function getObject():Object
		{
			return { key:"static value" };
		}
 
		{
			trace( "static 생성자 초기화" );
			trace( sv ); // 출력: [object Object]
			trace( obj.key ); // 출력: static value
			//trace( this ); // Error: The this keyword can not be used in static methods. It can only be used in instance methods, function closures, and global code.
		}
 
		private var iv:Object = { call:trace( "인스턴스 변수 초기화" ) };
		private var obj:Object = getObject();
 
		public function InitailizeTest()
		{
			trace( "인스턴스 생성자 초기화" );
			trace( obj.key ); // 출력: instance value
		}
 
		private function getObject():Object
		{
			return { key:"instance value" };
		}
	}
}

클래스 각 멤버들의 위아래 코딩 순서를 바꿔 봐도 출력되는 순서에는 변함이 없습니다. 따라서 초기화 순서는 클래스의 코딩 순서에 영향을 받지 않는다는 것도 알 수 있습니다. 다만, 초기화 순서에 따라서 클래스를 기술해 나가는 것이 가독성이 높을 수 밖에 없기 때문에 특별한 이유가 아니라면 초기화 순서에 따라 코딩을 해 나가는 것이 좋습니다.

1. 컴파일 에러 메세지는 다음과 같습니다. The this keyword can not be used in static methods. It can only be used in instance methods, function closures, and global code.
2. 인스턴스가 생성되는 시점이 아닙니다.

우리나라에서 활동하는 액션스크립트 개발자 분들도 있지만, 전 세계적인 개발자 숫자에 비한다면 극히 일부분에 불과합니다. 우리가 어떤 문제에 봉착했을때, 이 문제가 여러분이 사상 최초로 경험한 문제일 확률은 거의 제로에 가깝죠. 누군가는 이 문제에 대한 해결 방법을 알고 있을 겁니다. 그리고 그 해결 방법의 난이도가 높거나 삽질이 심할 경우, 또는 아주 쉬운 것인데 등잔밑이 어두워 해결 방법을 찾지 못하고 있을 경우에도 해결방법을 어디엔가 기록해 놓고, 자신과 같은 시간낭비를 하지 않기를 바라는 선배 개발자가 있게 마련입니다.

따라서 검색어만 적절하게 선택하여 구글링을 한다면 대부분의 문제에 대한 해결 방법을 찾을 수 있습니다. 그러나 우리나라 사람들은 영어에 대한 막연한 거부감, 내지는 두려움으로 쉬운 해결방법을 찾지 못하고 지나치는 경우가 허다하합니다. 외국에 나가서 살지 않는 이상 영어를 네이티브 수준으로 잘 할 필요까지야 없지만, 자신의 업무 분야에 해당하는 영어로 된 문서 정도는 읽고 해석할 줄 알아야 합니다.

앞부분이 너무 거창 했는데요. 어순이나 문법을 speaking 할 수 있을 정도로는 알지 못할지라도, 언어야 어쨌건 단어로 이루어져 있으므로 단어의 의미만 알고 있다면 영어로 된 문서를 읽고 해석하는 것은 어렵지 않겠죠.

다만, 사전 들추기가 귀찮을 수는 있는데, 이런거라면 브라우저의 즐겨찾기에 등록해서 사용하는 북마클릿 기능을 이용하면 귀차니즘을 극복할 수 있습니다.

구글 번역 북마클릿

구글 번역 (위의 이미지나 왼쪽 링크를 웹 브라우저의 즐겨찾기로 끌어다 놓으세요.)

브라우저의 북마크(즐겨찾기)에는 http:// 로 시작하는 url 이 올 수도 있지만, Javascript 도 올 수 있습니다. 이것을 이용하여 북마크에 자바스크립트를 활용하여 유용한 기능을 하는 프로그램으로 만든것을 북마클릿(Bookmarklet) 이라고 합니다.

이런저런 인터넷 사전을 사용해 봤지만, 역시 최근에는 구글사전 만한것은 없고, 네이티브 스피커의 발음도 들을 수 있어 좋습니다. 최근 트렌드나 속어(slang), 숙어등도 잘 반영해 주죠.

이 북마클릿은 (지금은 어디인지 잃어버린) 구글의 어느 페이지에서 제공하던 링크였는데, 제가 약간 보완하여, 한글을 입력할 수 있게 하였고, 한글을 입력할 경우 자동으로 한->영 사전으로 검색됩니다. 그리고 브라우저에서 마우스로 선택한 부분이 있다면 그 부분을 자동으로 가지고 들어가 대화 상자를 띄워 주므로 편리합니다. 귀차니스트 에게 매우 안성 맞춤이죠.

구버전의 IE에서 즐겨찾기로 끌어다 놓기가 되지 않는 분은 링크에서 라이트 클릭 한 후 “즐겨찾기에 추가” 를 선택하시면 됩니다. IE에서는 위험할 수 있다는 경고가 뜨지만 실제로는 안전합니다. (FF나 GC에서는 일반적인 북마크와 동일하게 취급됩니다.)

위의 링크를 브라우저 부분에 끌어놓기가 잘 안되는 분은, 새 즐겨찾기를 하나 만든 후 아래의 코드를 즐겨찾기의 주소 부분에 넣어도 됩니다.

0

javascript:void(q=prompt('Google%20Translate%20:',getSelection()));if(q)void(window.open('http://translate.google.co.kr/?hl=ko#en|ko|'+encodeURIComponent(q)))

2011년 10월19일 추가

구글 사전이 폐쇄되고 구글 번역으로 통합되어 현재는 http://www.google.co.kr/dictionary 이런 화면만을 보여주기 때문에 이전의 막강한 구글 사전이 좀 아쉽기는 하지만 구글 번역으로 북마클릿의 쿼리를 옮겼습니다. 위의 링크들은 이제 구글 번역 서비스를 이용해 번역을 합니다.

대표적인 rpg 스타일의 타일 맵 구조인 디아블로 3의 한 장면

Depth Manager 포스트에 이미 썼지만, 게임은 Diablo나 WOW 스타일의 롤 플레잉 게임(RPG) 이기 때문에, 중앙에 위치한 플레이어 캐릭터는 화면상에서 계속 중앙에 고정되어 있어야 하고, 사용자가 wasd 키를 이용해 방향을 조작하면 바닥 맵이 움직이도록 기능되어야 합니다.

맵 뿐만 아니라 몬스터도 맵을 기반으로 움직이고, 그 위에 날아다니는 스킬(총알 또는 미사일) 역시 마찬가지 입니다. 그러므로 화면 자체는 1인칭 주인공 시점이고 나(플레이어)를 제외한 세계의 모든 것이 동시에 같은 방향으로 움직이게 됩니다.

Depth Manager 포스트에 이미 상세하게 썼으므로 레이어 구조가 궁금하신 분은 읽어보시기 바라고, 이 포스트에서는 바닥의 맵에 집중해서 알아보겠습니다.

맵의 크기에는 물리적인 제한이 존재한다.

가장 먼저 알아볼 것은 플래시의 몇 가지 한계점 중의 하나인 비트맵의 표시 면적(픽셀) 한계수치에 관한 내용입니다. BitmapData 클래스에 대한 레퍼런스를 보면,

AIR 1.5 및 Flash Player 10에서는 BitmapData 객체의 최대 크기가 8,191픽셀(폭 또는 높이)이며 총 픽셀 수는 16,777,215픽셀을 초과할 수 없습니다. 따라서 BitmapData 객체의 폭이 8,191픽셀이면 높이가 2,048픽셀 이하여야 합니다. Flash Player 9 이전 버전 및 AIR 1.1 이전 버전에서는 이 제한이 높이 2,880픽셀 및 폭 2,880픽셀입니다.

이런 내용을 볼 수 있습니다. 즉, 바닥의 맵은 위의 제한 내의 크기로 만들어져야 한다는 겁니다. 설사 이런 제한이 없다손 치더라도 저런 엄청난 크기의 비트맵을 움직이려면 상당한 수치의 cpu 를 사용해야 한다는 이야기고, 이것은 맵을 움직이는 것만으로 성능상 상당한 문제를 일으키게 됩니다.

그러므로 이런 조건에 맞게 맵을 만드려면 맵을 타일과 같이 쪼개야만 한다는 잠정적인 결론에 이릅니다. 화면이 움직일때 맵이 표시되는 면적만을 갱신해서 표시하고 화면 바깥에 있는 맵은 아무 일을 하지 않게, 아예 visible 을 끌 수 있으면 꺼서 최대한 cpu 자원을 적게 소모하도록 해 줄 필요가 있습니다.

A. 사용자의 컨트롤에 대한 처리

자 그럼 좀더 들어가서…
사용자가 키보드 A 키보드를 눌러 캐릭터를 왼쪽으로 이동 시키는 조작을 했다고 가정합니다.
이 경우 맵은 그 반대 방향인 오른쪽으로 이동시켜야겠죠. 이동후에는 왼쪽에 비어있는 맵을 보충하고자 오른쪽에 있는 맵 타일을 가져다 왼쪽에 놓습니다. 이것을 쉽게 그림으로 표현해 보죠.

A-1. 수평이동

여기까지는 쉽죠? 타일의 갯수가 많으면 기하급수적으로 헷갈리기 때문에 가장 간단한 타일 조합인 3*3으로 예시를 했습니다. 그리고 타일은 배열을 사용할 것이므로 타일 넘버링은 0 부터 시작함이 마땅하나 역시 매우 헷갈리기 때문에 1부터 시작했습니다.

A-2. 수평+수직 이동

그러면 사용자가 A 키와 W 키를 동시에 눌러 왼쪽 위 방향의 대각선으로 조작했을 경우는 어떨까요? 역시 마찬가지로 왼쪽이 비면 오른쪽에 있는 타일을 가져다 왼쪽에 놓고, 위쪽에 빈 공간을 아래쪽의 타일을 가져다 놓으면 됩니다.

타일이 대각선으로 이동 하다가 이동 조건을 먼저 충족시킨 수평 이동 규칙이 먼저 적용 됩니다. 그리고 곧 이어 W 키에 의해 수직 이동 조건도 충족되어 가장 아랫줄 전체가 가장 위로 이동하게 되죠.

꼼꼼한 분들 중에는 정확히 W키와 A키를 동시에 눌러 왼쪽으로 보내는 함수와 위쪽으로 보내는 함수가 동시에 호출되면 어떻게 되는거냐. 라고 의문을 품으실 분이 계실 것 같습니다만, 다행인지 불행인지 플래시 플레이어는 싱글 쓰레드 이기 때문에 동일한 함수가 동시에 호출되는 일은 일어나지 않습니다. 1 나노초라도 먼저 호출 되는 쪽의 함수가 실행되고 이후의 호출은 대기를 타게 되므로, 특히 9번 타일에 대해서는 걱정하지 않으셔도 됩니다.

자 그래서 플레이어 캐릭터는 가만히 있어도 움직이는 세계를 만들어 봤습니다. 실제로는 러닝머신과 같은 형태이긴 합니다만 ^^

이론은 쉽죠? 그러나 일정한 조건이 되면 감지해서 타일 위치를 변경하는 코드는 꽤나 복잡하기도 하고 한 가지의 정답이 아닌 여러 가지 방법으로 구현이 됩니다. 최적화가 덜 되있긴 하지만 제 수준에서는 TileSet.as 파일의 코드가 200라인 약간 넘는 정도가 나오네요.

A-3. 함수 목록

로직의 흐름을 따라 필요한 함수를 간단하게 정리해 볼까요?

• 타일을 담고 있는 컨테이너의 x, y 값을 매 프레임마다 업데이트 해 주는 함수(호스트 코드에서 호출)
• 이동하면서 타일이동 조건에 부합하는지 검사
• 검사 조건에 충족하면 4가지의 이동( 왼->우, 우->왼, 하->상, 상->하 ) 명령을 호출하는 함수
• 각 조건에 따라 (어느쪽 끝이 될지는 모르겠지만) 한쪽 끝 모서리의 타일들의 목록을 리턴하는 함수
• 리턴받은 타일 목록을 4가지 유형에 따라 픽셀 이동

이 밖에도 아래와 같은 부차적인 함수도 필요합니다.

• 각 모서리 위치에 있는 타일들이 어떤 녀석들인지 우리는 눈으로 보면 알 수 있지만 컴퓨터는 어떻게 알 수 있나요? 이를 위해 2차원 배열로 타일 목록을 관리할 필요도 있고,
• 타일이 이동한다면 얼마만큼의 픽셀이 움직여야 하는지 미리 계산 되어 있어야 하며,
• 2차원 배열을 관리 할때 첫 번째 원소를 빼내서( Array.shift() ) 마지막 원소로 넣어주는( Array.push() ) 함수와,
• 그 반대의 함수도 필요합니다. ( Array.pop() 과 Array.unshift() )

여러분도 직접 만들어 보세요. 여러분의 실력 향상에 분명 도움이 될겁니다.

B. 최종 컴파일 결과

그럼 최종 컴파일 결과물을 보고, 플래시 화면을 한번 찍은 후 WASD 키보드도 움직여 보세요. 맵이 움직이는것을 확실히 증명하기 위해 5*5 타일중 정 중앙의 타일 색상을 살짝 바꿔 놓았습니다.

C. 기능 개선

현재의 결과물은 타일의 크기가 가로세로 각각 100픽셀 정도의 작은 타일이라 모든 타일들이 한 화면에 표시되지만, 타일의 크기가 좀 더 커야 할 경우를 고려한 구조도 필요할것 같습니다.

또한 타일 갯수가 3*3, 5*5, 7*7 외에도 4*4, 6*6 과 같은 짝수 타일의 경우에도 문제 없이 동작할 수 있도록 해야겠고, 가로와 세로의 타일 수가 일치 하지 않는 경우 역시 마찬가지 되겠습니다.

책 표지 이미지는 yes24 에서 무단으로 가져왔습니다. ^^

액션스크립트 3.0 기본서

액션스크립트 3.0 을 다루기 위해서 반드시 읽어야 할… 그리고 참고서 삼아 가지고 있어야 할 책입니다. 아래의 기본서 세권 중 최소 두권은 읽어보시길 바랍니다. 가능하면 세 권 모두 읽는 것을 권합니다.

okgosu의 액션스크립트 정석

http://goo.gl/7R8Bg

옥상훈님이 쓴 기초서이자 세 권 중에서 가장 최근에 나온 책입니다. 그간 액션스크립트의 전반적인 것을 다룬 기초서가 마땅한게 없어 추천하기가 애매했지만, 이 책이 나온 이후로는 이 책을 추천합니다. 액션스크립트 뿐만 아니라 관련된 주변의 여러 가지 것들까지 함께 다루고 있어 두루두루 유용합니다만, 책 가격은 왜 그리 비싼건지…

액션스크립트 3.0 완벽가이드

http://goo.gl/GrE7t

많은 분들이 잘 알고 계시는 콜린 무크의 EAS3.0의 국내 번역서이자, AS1.0부터 계속 이어진 시리즈의 3.0 버전 입니다. 번역이 다소 늦게 된것이 불만이라면 불만이랄까요. 책의 내용은 좋습니다만, 프로그래밍을 전혀 모르는 완전 초보가 읽는다면 “이건 무슨 이야기를 하는걸까?” 하는 생각이 들 수 있습니다. 3.0이 대략 어떤건지 이해한 후에 읽는다면 매우 좋은 책입니다.

디자이너를 위한 액션스크립트 3.0

http://goo.gl/SKGg2

책의 제목에서 알 수 있듯 디자이너와 같이 언어에 취약한 입문자를 위한 책 입니다. 이미지의 할당 면적이 많고 간단한 예제 위주로 내용이 진행됩니다. EAS3.0 이 늦게 번역되기도 했지만, 설사 일찍 번역되었더라도 이 책과 EAS3.0은 내용면에서 완전히 다른 동네에 위치해 있다고 할 수 있으므로 책의 용도가 겹치는 일은 없다고 할 수 있겠죠.

* * * * *

디자인 패턴

디자인 패턴은 패턴 자체를 개발에 직접 사용할 수도 있지만, 실제로는 언어적 구조와 객체지향적인 프로그래밍에 대한 이해를 돕는데 훨씬 도움을 많이 줍니다. 처음엔 약간 이해하기 힘들어도 처음엔 빠르게 읽어 나가고, 시간이 지난 후에 좀 더 자세하게 읽어본다면 분명 피가되고 살이 될 겁니다.

액션스크립트 3.0 디자인 패턴

http://goo.gl/sloa5

액션스크립트를 기반 언어로 디자인 패턴을 다룬 현재까지 유일한 번역서이자 아마도 마지막 번역서가 되지 않을까 싶습니다. MVC를 포함한 사용 빈도가 높은 10가지의 패턴을 예제와 함께 소개하고 있고, UML 이라든지, 이벤트 구조, 또는 XML 이나 정규표현식도 부록과 같이 붙어 있습니다.

Head First Design Patterns : 스토리가 있는 패턴 학습법

http://goo.gl/yjRIx

개발서들을 많이 접해보신 분들은 이 책의 제목만 보고도 어떤 내용인지 능히 짐작이 될 겁니다. 이해하기 쉬운 삽화와 Java 코드로 디자인 패턴을 설명하고 있습니다만, 이 시리즈의 다른 책들과는 달리 이해하기 쉽고 디자인 패턴의 중요한 부분을 조목조목 잘 짚어내고 있습니다. 디자인 패턴에 대한 감을 제대로 잡아주는 강력추천 도서 입니다.

* * * * *

코딩 방법론 또는 리팩토링

이 책들은 입문 단계가 지난 직후쯤에 읽는 책들로 올바른 프로그래밍 기법에 대한 방법을 제시합니다. 주로 Java 코드 위주로 설명하지만 충분히 이해할 수 있는 수준의 코드고, API 를 다루는 것이 아닌 방법론을 다루기 때문에 객체지향 언어라면 어떤 언어의 개발자에게도 유익한 책들 입니다.

켄트 벡의 구현 패턴 : 읽기 쉬운 코드를 작성하는 77가지 자바 코딩 비법

http://goo.gl/6oMsA

이 책의 부제에 쓰여있는대로, 가독성이 떨어지는 현란한 테크닉을 구사하지 말고, 다른사람, 또는 자기 자신도 읽기 쉬운 프로그래밍 방법을 소개하는 책입니다. 코딩을 쉽게 하려면 상당히 여러가지를 고려해야 하고 책 내용도 무작정 쉽지많은 않습니다만, 켄트 벡이라는 이시대의 걸출한 개발자의 저서를 읽을 수 있다는 것만으로도 충분한 그런 책이죠.

Refactoring 리팩토링 : 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법

http://goo.gl/BMaZz

켄트 벡과 수많은 교류를 하고 서로 영감을 주고 받는 또 한명의 유명한 개발자, 또는 개발 이론가 (생긴건 시골 아저씨) 마틴 파울러의 리팩토링 방법론에 관한 책 입니다. 이론의 기본적인 자세는 켄트 벡의 저서와 비슷하지만, 이 책은 이미 작성된 코드를 어떻게 효과적으로 리팩토링 하는지에 대한 노하우에 대하여 글을 쓰고 있습니다.

* * * * *

기타

위의 카테고리에 속하지 않지만, 액션스크립트 프로젝트 실무에 반드시 한번쯤 실제적인 도움을 주는 좋은 책들 입니다.

손에 잡히는 정규 표현식

http://goo.gl/vcvMJ

액션스크립트에서 정규식은 몰라도 노가다로 극복 가능하지만, 알게되면 상당히 편리한 물건입니다. 물론 문자열 조작에 한정해서겠지만 말이죠. 달파란(길섭)의 표현을 빌자면, “정규식은 이 책 하나면 마스터 가능하다.” 라고 합니다.

ActionScript 3.0 Cookbook  : 플래시, 플렉스 개발자를 위한 액션스크립트 솔루션

http://goo.gl/gKQk5

국내에 제대로 된 액션스크립트 3.0의 기본서가 없을 무렵 가장 처음에 번역되어 기본서도 아니면서 기본서의 역할을 해왔던 액션스크립트 3.0 쿡북 입니다. 오라일리 출판사의 쿡북 시리즈의 스타일을 그대로이고, 개발하면서 맞닥뜨리게 되는 여러 가지 문제에 대한 해결책을 간략하지만 확실하게 제시해 주는 책 입니다.

Java의 정석

http://goo.gl/iB70M

액션스크립트 개발자에게 Java 책이 도움이 된다는 이야기는 들어본적 있어도 어느정도 도움이 된다는 건지는 실감하기 힘들텐데요. 결론만 말하자면 Java는 정말 액션스크립트의 기본 언어 학습에 정말 도움이 많이 됩니다. 액션스크립트 3.0은 프로그래밍 언어 학습이 절반, API 가 절반이라고 할 수 있는데, 이중 전자를 먼저 알고 있다면 후자는 그냥 훑어보는 정도로도 개발이 가능하다고 할 수 있습니다. Java 나 C# 개발자 출신 액션스크립트 개발자들이 바로 그들이죠. 이 책은 Java 에 대한 기본서 이면서 객체지향에 대한 이론도 충실하게 짚어주는 좋은 책입니다.

Flash Player 11 의 인큐베이터 버전이 설치되면 보이는 워터마크

며칠전 Flash Player 11이 될 Molehill 의 인큐베이터 버전이 릴리즈 되었습니다. Molehill 은 3D API 와 하드웨어 가속을 본격적으로 사용하는 첫 버전이기 때문에 인큐베이터 버전이라는 다소 생소한 방식의 배포 방식을 선택한것으로 보입니다.

어쨌건 플래시 개발자 입장에서는 새로나온 API를 점검하기 위해 새 플래시 플레이어를 설치해 봐야 할 텐데요.^[01] 문제는 현재 정식 릴리즈된 플레이어 버전(Molehill 의 입장에서 보면 구버전)으로 작업중인 프로젝트에 영향을 미칠 수가 있습니다. 게다가 이번 Molehill 의 인큐베이터 버전을 html 에서 보면 왼쪽 화면과 같이 워터마크가 표시되서 썩 내키지 않기도 합니다. 그렇다고 플레이어를 설치하고 삭제하는 것을 반복하는 것은 뭔가 좀 번거롭기도 하고 마음에 들지 않죠.

이런 문제를 Google Chrome 브라우저에서는 깔끔하게 해결할 수가 있습니다.

먼저 크롬의 구글 크롬의 해당 도움말을 참고해서 플러그인 관리 페이지를 엽니다. 이 플러그인 관리 페이지는 주소창에 about:plugins 과 엔터키를 입력하면 더욱 간단하게 열 수 있습니다.

플러그인 관리 페이지에서 오른쪽 윗 부분의 “세부정보”를 클릭해서 Flash 항목을 보면 아래와 같이 두 개의 플러그인 파일이 존재하고 있는 것을 볼 수 있습니다.

이것은 크롬에 통합된 플래시 플러그인과^[02] 사용자가 별도로 설치한 플래시 플러그인  두 개를 별도로 표시해 주고 있습니다.
두 개의 플러그인은 버전이 다를뿐만 아니라 디스크상의 경로도 완전히 다르다는 것을 볼 수 있네요.

이 화면에서 “사용중지”를 클릭하면 필요하지 않은 플래시 플레이어를 사용 중지 시킬 수 있습니다. 더욱 놀라운 것은 사용중지 후, 브라우저의 재시작조차 필요 없이 새로고침 한번으로 플러그인이 전환 됩니다.

아직은 크롬에서만 이 플러그인 스위칭 기능을 제공하는 걸로 확인했습니다. 다른 브라우저에서 가능한 방법이 있으면 아래 댓글에 써 주세요.

1. 플레이어 설치 url http://labs.adobe.com/technologies/flashplatformruntimes/incubator/
2. 구글은 얼마전부터 별도의 설치가 필요하지 않도록 플래시 플러그인을 빌트인 해서 크롬을 출시하고 있습니다.

일단 무슨 게임을 만드는지 살펴볼까요?
키보드의 wasd 키로는 이동 방향을 전환하고, 마우스로 플레이어 캐릭터의 방향과 슈팅을 하게 되는 롤 플레잉 스타일 게임 입니다. WOW(World of Warcraft)의 플레이 스타일과 비슷하다고 생각하면 되겠습니다.

게임의 시각 객체들을 담고 있는 컨테이너는 아래와 같이 만들어져 있습니다.

A. 계획

유저가 wasd 키를 누르면 전체 화면이 이동하지만 플레이어 캐릭터는 화면의 중앙 위치를 계속 유지하게 만들어야 하죠.
움직이는 화면 전체에 해당하는 객체는 PlayingStage 클래스로 만들어져 stage 에 addChild() 되어있고 있고 이 클래스 내부에는 레이어 순서대로 Map 객체가 가장 아래에 깔려 있고, 그 위에 CharacterLayer 객체가, 그리고 가장 위에 스킬 객체들이 날라다니는 SkillLayer 가 addChild() 되어 있습니다.

이 중에서 CharacterLayer 객체 내부에 Player 객체와 Monster 객체들이 섞여서 addChild() 되어 있는데요, 플레이어 캐릭터는 화면 중앙에 움직이지 않고, Map 이 유저가 컨트롤 하는 방향의 반대 방향으로 움직이게 되므로 Monster 캐릭터만을 addChild() 해 넣은 MonsterLayer 클래스 위에 Player 캐릭터만을 위한 Layer 를 따로 두고 싶었지만, 그렇게 되면 플레이어 캐릭터는 무조건 MonsterLayer 의 상위 레이어에 있게 되므로 쿼터 뷰의 특성상 플레이어의 앞쪽에 겹쳐 위치한 몬스터도 플레이어의 아래 깔리게 되는 원치 않는 상황이 발생하게 됩니다. 그래서 플레이어 캐릭터를 포함한 앞뒤 원근 관계를 가지는 모든 캐릭터 객체들을 하나의 Layer 에 넣어서 관리해야만 합니다.

그런데 이렇게 되면 유저의 키보드 컨트롤로 모든 객체, 즉, Map, Monster, Skill 객체들은 같은 방향으로 움직이지만, Player 객체만은 반대 방향으로 움직여야 합니다. 따라서 이 모든 객체들을 addChild() 하고 있는 컨테이너인 PlayingStage 객체를 wasd 에 따라 움직여주되, 플레이어 캐릭터만은 그 반대 방향으로 별도로 이동시켜 줍니다.

주변의 문제들은 모두 짚었고, 그럼 이제부터 CharacterLayer 클래스로 시각을 집중시켜 보도록 합시다. 위에서 말한대로 이 CharacterLayer 객체 내부에 addChild() 되어있는 객체들은 Player 객체와 Monster 객체가 섞여 있겠죠. 여기서 우리는 플레이어와 몬스터의 앞뒤 원근 관계 뿐만 아니라 몬스터와 몬스터의 앞뒤 원근 관계도 바뀔 수 있음을 기억해야 합니다.

위의 그림과 같이 rotationX 로 화면을 기울인 상태에서 플래시의 좌표계는 왼쪽 위가 x, y 좌표의 기준점 0 이므로 y 가 증가하면 아래쪽으로 이동하게 됨을 잊지 마세요. 결국, y 값이 높으면 원근 관계상 앞쪽에 위치하게 되고, y 값이 낮으면 먼 쪽에 위치하게 됩니다.

A-1. 겹쳐 있는 두 개의 객체 간의 관계만 파악하는 방법

객체 간 앞뒤 관계는 서로 시각적으로 겹쳐 있는 상태의 두개 이상의 객체에서만 발생하는 문제라고 바꾸어 말할 수 있습니다. 서로 시각적으로 겹쳐있지 않은 객체는 DisplayObjectContainer 상의 addChild() 인덱스가 서로 역전되어 있다고 할지라도 문제될게 없는 셈이죠. 서로 떨어져 있는 객체가 서로 겹치게 되면 그때 가서 두 객체의 y 값을 비교해서 인덱스를 조정하면 됩니다.
그래서 Monster 객체에 hitTestObject() 메서드를 이용하여 객체의 충돌을 감지하고 충돌 시점의 y 값이 높은쪽의 인덱스가 높으면 아무런 조정을 하지 않고, y 값이 높은데 인덱스가 낮은 경우에 두 객체의 인덱스를 바꿔 주거나 낮은쪽의 인덱스를 높은쪽의 인덱스 한단계 위 인덱스로 setChildIndex() 해 주는 겁니다.

그런데 막상 이렇게 DepthManager 클래스를 작성하고 작동시켜보면 문제를 발견할 수 있습니다.
이 방법은 모든 플레이어와 몬스터 캐릭터들 내부에 엔터프레임을 돌려 계속 충돌을 감지해야 하고, 결국 불필요한 중복 연산이 발생하게 되어 전체적으로 퍼포먼스를 떨어뜨리게 되는 결과를 가져오게 됩니다.
또한 두 개의 객체간에는 문제 없이 제대로 동작하지만, 동시에 3개 이상의 객체가 겹치게 되면 좌표상으로는 뒤에 위치하는 객체가 인덱스가 더 높은 버그 현상도 자주 생기게 됩니다.

A-2. 모든 객체의 y 값 순위를 매겨 인덱스를 새로 쌓는 방법

그래서 모든 객체마다 y 값에 따라 객체들간의 순위를 정해서 그 순위대로 인덱스로 쌓는 단순한 방법을 사용해 보도록 합시다. 간단한 코드가 가독성도 높고 대개의 경우 버그도 없는, 있다 하더라도 금방 수정할 수 있는, 잘 만들어진 코드라고 할 수 있죠.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

var _parent:DisplayObjectContainer;
var _children:Array;
 
function getChildren( $parent:DisplayObjectContainer ):Array
{
	var list:Array = [];
	var i:int;
	for ( i = 0; i < $parent.numChildren; ++i )
		list[ i ] = $parent.getChildAt( i );
 
	return list;
}
 
function reOrder():void
{
	var count:int;
	var child:DisplayObject;
	for each( child in _children )
	{
		count = getCount( child );
		_parent.setChildIndex( child, count );
	}
}
 
function getCount( $child:DisplayObject ):int
{
	var count:int = 0;
	var child:DisplayObject;
	for each( child in _children )
	{
		if ( child.y < $child.y )
			count = count + 1;
	}
	return count;
}
 
// 자식 객체들을 배열로 가져옴
_children = getChildren( _parent );
 
// 실행
reOrder();

대략 위와 같이 구현하였습니다. 엔터프레임을 CharacterLayer 객체 한곳에서 대표로 돌리고 자식 객체들의 순서를 정해주는데, 이렇게 사용하기 위해서, 미리 플레이어와 몬스터 캐릭터를 getChildren() 메서드를 이용해 모두 하나의 배열에 넣어두었고 for each .. in 로 모든 배열 원소를 순환하였습니다. 모든 객체를 순환하면서 y 값을 현재 비교 대상인 객체의 y 값과 비교해서 낮으면 카운팅하고 합산해서 인덱스를 얻어내는 방법 입니다.
getCount() 함수에서 반환되어 나오는 int 값이 기준 객체보다 y 값이 작은 객체들의 갯수이므로 그 갯수가 바로 CharacterLayer 객체에 setChildIndex() 메서드의 인덱스 인자와 같은 값이 되는거죠.

B. 클래스로 분리시켜보자

자 핵심 로직은 완료했으니 이것을 클래스로 분리시켜 나만의 라이브러리에 추가 하면 더욱 좋겠죠? 초보 플래시 개발자 분들의 의견을 들어보면 의외로 이런 내용이 도움이 된다고들 해서 이런 내용을 끼워 넣어 봅니다.

이 DepthManager 클래스의 준비 과정은 이렇습니다.

B-1. 준비물 모으기

준비물이라고 한다면, 객체들을 모두 addChild() 하고 있는 부모 객체 하나일수도 있고, 또는 객체들을 배열로 받을수도 있겠습니다. 다른 경우라면 배열로 받는 것이 여러 모로 편리하고 퍼포먼스 측면에서도 좋겠지만, 그렇다면 모든 자식 객체들의 부모가 동일한 하나의 객체라는 것을 검증하는 조건문이 추가적으로 더 필요하게 되므로, 간단하고 코드 이해를 빠르게 하기 위해 이번에는 부모 객체 하나를 참조로 받고 그 자식 객체들을 모두 depth 관리하는 방법을 선택합니다.

B-2. 로직 점검

그런데 문제가 생겼습니다. 위에서 만든 로직은 최초 부모 객체를 참조로 받는 동시에 자식 객체를 모두 배열에 넣어 for each .. in 순환문을 사용하는 구조이고, 이것은 퍼포먼스를 의식한 코딩이었습니다. 만약 자식 객체의 숫자가 런타임에 변하지 않는다면, 이 방법이 가장 깔끔하겠습니다만, 지금 DepthManager 클래스가 필요한 것은 게임이므로 수 많은 객체들이 동적으로 등록되고 다시 빠져나갈 수 밖에 없겠죠. 그래서 런타임에 객체가 새로 추가 되는 것을 알기 위해, 부모 객체가 참조로 등록되는 순간 Event.ADD 이벤트를 걸어 놓고 새로 addChild() 된 객체가 있다면 배열에 추가 하는 이벤트 리스너 함수를 덧붙입니다. (아래 완성된 클래스 참고)

사실 그냥 간단하게  부모 객체의 numChildren 속성을 참조해 자식 객체의 갯수를 알아내고 getChildAt() 으로 객체를 잡아낸 후, 그냥 for 문을 돌리는 방법을 사용할 수도 있습니다. 이 방법은 배열을 for each .. in 로 순환하는 것 보다는 퍼포먼스가 떨어지는 한편,^[01] 별도의 배열과 배열에 원소를 넣고 빼는 함수를 만들고 관리하지 않아도 된다는 점은 장점입니다.
어느 방법을 선택하느냐는 현재 만들고 있는 애플리케이션의 성격에 따라 적절하게 판단하시기 바랍니다. 여기서 우리는 처음 정한대로 배열을 이용하는 방법으로 진행합니다.

B-3. 클래스 가동

위에서 설명했듯이 이 로직은 엔터프레임 기반으로 실행되므로 클래스를 가동시킴과 동시에 부모 객체에 엔터프레임을 걸고 이벤트 핸들러 함수를 실행 시킵니다.

그런데 여러차례 상기했듯이 이 코드는 엔터프레임마다 실행되므로 cpu 자원을 꽤 잡아먹는 연산이 될 수 밖에 없습니다. 그나마 모든 객체에 대한 앞뒤 관계를 이 하나의 엔터프레임에서 해결할 수 있으므로 가격대비 성능이 저렴한 편이라고 할 수 있긴 합니다만, 이 함수를 호출하는 것을 최소화 할 필요는 있습니다.
그래서 엔터프레임 이벤트 핸들러 함수를 매 프레임이 아닌 몇 프레임마다 호출하는 조건문을 하나 걸어두었습니다.

여기서 우리는 이 함수를 왜 만들었는지 다시 기억할 필요가 있습니다. 캐릭터 객체들간의 앞뒤 관계를 잡아주기 위함이었죠. 아래 두 개의 컴파일 결과물을 비교해 보세요.

<<1프레임 마다 호출>>

<<5프레임마다 호출 ( 한번 호출한 후 4프레임은 건너뛰도록 조건을 걸어놓음 ) >>

위 두개의 결과물에서 차이가 느껴지시나요?
의식하고 보면 매프레임 호출과 5프레임 마다 1회 호출의 차이가 느껴질수는 있습니다만, 그 차이가 큰 의미를 가지는 수준은 아닐 것입니다. 인간의 눈은 매우 정확하면서도 한편으로는 (정확하다는 확고한 믿음 때문에) 속이기도 쉬운 감각기관 입니다. 특히 이런 움직이는 화면에서는 그런 측면이 더 잘 드러나죠.

B-4. 클래스 네이밍

이 DepthManager 클래스는 y 값이 높은 객체를 자동으로 인덱스를 높게 설정하게 되므로 엄밀히 말하면 3D 쿼터 뷰 에서만 원래 의도한대로 동작한다고 봐야 겠죠. 그러므로 이 클래스에 DepthManager 라는 범용 네이밍을 하는 것은 좀 부담스럽습니다. 그래서 이 클래스를 가장 잘 표현할 수 있는 QuarterViewDepthManager 라는 약간은 장황한 네이밍을 했습니다. 중간에 Auto 라는 단어도 끼워 넣고 넣고 싶었지만 참았습니다. ^^ 간단하게 3DDepthManager 라고 해도 되겠죠. 그러나 숫자가 클래스 이름의 가장 첫 번째 오는것은 불가능 하므로 의미는 약간 다르지만 DepthManager3D 라고 해도 표현해도 크게 무리 없을 것 같습니다.

B-5. 완성된 클래스

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

package kr.ufx.beta.display
{
	import flash.display.DisplayObject;
	import flash.display.DisplayObjectContainer;
	import flash.events.Event;
 
	/**
	 * @author 원종선[세계의끝] cuebrick[ at ]gmail.com http://ufx.kr/blog
	 *
	 * << 3D quater view 를 위한 자동 depth manager >>
	 * depth 를 관리하고자 하는 객체들을 모두 하나의 부모객체에 넣은 후
	 * 부모객체를 setParent() 메서드를 이용해 참조로 넘기면
	 * 부모객체에 addChild() 되어 있는 모든 객체들의 y 값에 따라 자동으로 depth 가 조절된다.
	 * 매 프레임마다 depth 를 재편할 필요가 없는 경우 skipFrames 속성을 설정하면
	 * 적당히 프레임을 건너뛰어 depth managing 을 수행할 수 있다.(퍼포먼스가 향상됨)
	 * run(), stop() 메서드를 이용해 동작을 수행 또는 일시정지 시킬 수 있다.
	 */
 
	public class QuarterViewDepthManager
	{
		private var _parent:DisplayObjectContainer;
		private var _children:Array;
		private var _everyNumFrame:uint = 5;
		private var _count:int = 0;
 
		/***********************************************************
		 * public method
		 ***********************************************************/
		public function setParent( $parent:DisplayObjectContainer ):void
		{
			_parent = $parent;
			addListener( _parent );
			_children = getChildren( _parent );
		}
 
		public function run():void
		{
			if ( _parent == null )
				throw new Error( "setParent() 메서드를 먼저 호출할것" );
 
			addEnterFrameListener( _parent );
		}
 
		public function stop():void
		{
			removeEnterFrameListener( _parent );
		}
 
		/***********************************************************
		 * private, protected method
		 ***********************************************************/
		private function addListener( $parent:DisplayObjectContainer ):void
		{
			$parent.addEventListener( Event.ADDED, addChildHandler );
			$parent.addEventListener( Event.REMOVED, removeChildHandler );
		}
 
		private function addEnterFrameListener( $parent:DisplayObjectContainer ):void
		{
			$parent.addEventListener( Event.ENTER_FRAME, update );
		}
 
		private function removeEnterFrameListener( $parent:DisplayObjectContainer ):void
		{
			$parent.removeEventListener( Event.ENTER_FRAME, update );
		}
 
		private function update( e:Event ):void
		{
			if ( _count % _everyNumFrame == 0 )
				reOrder();
 
			++_count;
		}
 
		private function getChildren( $parent:DisplayObjectContainer ):Array
		{
			var list:Array = [];
			var i:int;
			for ( i = 0; i < $parent.numChildren; ++i )
				list[ i ] = $parent.getChildAt( i );
 
			return list;
		}
 
		private function addChildHandler( $e:Event ):void
		{
			_children.push( $e.target );
		}
 
		private function removeChildHandler( $e:Event ):void
		{
			var index:int = _children.indexOf( $e.target );
			_children.splice( index, 1 );
		}
 
		private function reOrder():void
		{
			var count:int;
			var child:DisplayObject;
			for each( child in _children )
			{
				count = getCount( child );
				_parent.setChildIndex( child, count );
			}
		}
 
		private function getCount( $child:DisplayObject ):int
		{
			var count:int = 0;
			var child:DisplayObject;
			for each( child in _children )
			{
				if ( child.y < $child.y )
					++count;
			}
			return count;
		}
 
		/***********************************************************
		 * get / set method
		 ***********************************************************/
		public function get skipFrames():uint
		{
			return _everyNumFrame - 1;
		}
 
		public function set skipFrames( $skipFrames:uint ):void
		{
			_everyNumFrame = $skipFrames + 1;
		}
 
	}
 
}

위와같이 클래스를 정리하고,
호스트코드에서 아래와 같이 사용하면 됩니다. 사용법은 뭐 너무나 간단하죠.

0
1
2
3
4
5
6
7
8
9
10
11

// 부모 컨테이너를 생성한 후에
var parentContainer:Sprite = new Sprite;
// 여러 자식 객체들을 addChild() 했다 가정하고...
 
// DepthManager 객체 생성
var depthManager:QuarterViewDepthManager = new QuarterViewDepthManager;
// 부모 객체를 DepthManager 에 던져줌
depthManager.setParent( parentContainer );
// 필요하다면 skipFrames 를 설정하고,
depthManager.skipFrames = 4;
// 동작시킴
depthManager.run();

클래스를 객체지향적으로 잘 만들수록 호스트 코드에서의 사용법은 훨씬 쉬워집니다. DepthManager 클래스 내부에서 무슨일이 일어나는지는 알 필요 없이 그저 부모 객체를 하나 던져주고 run() 함수를 실행시키면 되는거죠.

이렇게 3D 쿼터 뷰 화면에서 사용하는 약간은 특수한 목적의 DepthManager 클래스를 만들었습니다. 간단한 클래스지만 구현하는 과정에서 버그가 생길 수 있는 요소도 제거해보고 성능을 최적화 하는 요령등 클래스를 만드는 기본적인 방법도 알아보았습니다. 실제 정확히 동작하는것을 확인했으므로 필요하신 분은 package 를 수정하여 여러분의 라이브러리에 추가해 사용하세요.

1. for each .. in 순환문은 for 순환문에 비해 약 30% 정도 수행속도가 빠릅니다.

이 포스트는 “초보 프리랜서 견적 낼 때는 이렇게” 내용을 여러분이 읽었다는 것을 전제로 쓰여질 것이므로 이전 포스트를 읽지 않으신 분은 참고하시기 바랍니다.

이전 포스트에서는 결국 “초보 프리랜서라면 견적을 대략 얼마만큼 내면 되겠는가” 라는 내용이 핵심인 셈이었습니다만, 얼마만큼의 견적을 내면 되는지 아는것 만으로는 견적서가 작성되진 않죠. 이런저런 자질구레한 것들도 알아야 합니다. 이 포스트는 그런 자잘한 것들, 그러나 꽤나 중요한 것들을 위주로 짚어 보도록 하겠습니다.

또한, 견적서라는 것이 모든 작업이 시작되기 전에 서로 “간”을 보는 단계에서 주고 받게 되는 문서이므로 여러분의 견적을 받게 되는 회사의 시각으로 보면 “이 프리랜서 개발자가 제대로 일을 할 수 있는 사람인지 아닌지” 알 수 있게 하는 중요한 판단근거가 되는 경우가 많습니다. 그렇기 때문에 프리랜서의 견적서는 빈틈이 없어야 하고, 혼자 작업하기 때문에 어설프다는 인상을 주지 않도록 신경을 써 줘야 합니다.

견적서 샘플 다운로드

그리고 이번에는 엑셀로 작성된 실제 견석서 샘플을 보면서 설명하도록 하겠습니다. 실제로 제가 작성하여 사용하고 있는 양식이므로 초보 프리랜서 여러분도 이 견적서 샘플을 가져다 수정해서 자신있게 견적을 내시면 됩니다.

먼저 상황을 설정해 볼까요?

지금 여러분은 A주식회사에서 요청이 들어와 웹 사이트의 플래시 애플리케이션 개발에 관한 견적서를 작성하려고 하던 참입니다. 실무자와 꽤 오랜 시간에 걸친 전화통화를 거쳐 요건정리를 해보니 아주 어려운 프로젝트는 아니지만 그렇다고 후다닥 해 치울 수 있는 작업도 아닌지라 1달 반 정도의 작업기간이면 테스트와 피드백에 의한 수정 까지 모두 마칠 수 있을것 같습니다. 그런데 A주식회사에서는 이 서비스를 또 다른 원청업체에게 납품하여야 하는데, 납품 기일이 앞으로 1달 밖에 남지 않았습니다.
여러분은 플래시 바닥에서 2년 정도 실무를 경험한 개발자이고요. 나름 이런 저런 삽질 하다보면 플래시 API 수준에서는 어느정도 마음먹은대로 결과물을 산출해 낼 수 있는 실력을 가지고 있습니다. (물론 상황 설정을 위한 가정입니다.) A회사로부터는 지인의 지인을 통해 소개 받았고(보통 이렇죠?) 이번이 첫 거래 입니다.

그럼 항목 하나하나를 보면서 이야기해 보겠습니다.

A. 견적명, B. 견적금액

그리고 견적서 수신자, 작성자 등이 기본적으로 들어갑니다.
일반적으로 견적서가 주로 엑셀과 같은 스프레드시트로 만들어지는건 다 이유가 있습니다. 각 항목을 입력하면 더하기 곱하기 정도는 알아서 계산해주기 때문이죠. 이 샘플 견적서 역시 세부 명세 항목의 단가와 수량을 입력하면 자동으로 견적서가 완성이 되는 기능을 가지고 있습니다. 그렇기 때문에 여러분은 B 항목의 견적금액을 직접 입력할 필요 없이 C 항목의 세부명세만 작성해 넣으면 됩니다. 바로 C 항목으로 넘어갑니다.

C. 세부명세

1번 그룹 – 인건비 항목

지난 포스트에 이어 이 견적서는 인건비 수준에도 미치지 못하는 보수를 받고 일하는 초보 프리랜서분들을 위한 글이므로(이미 적절한 보수를 제대로 받고 계신분은 이 포스트를 읽으실 필요가 그리 없겠죠.) 역시 이번에도 인건비 베이스로 견적해 보겠습니다.

1.1 개발 부분 보수

개발 부분 보수 항목은 메인이 되는 보수 입니다. 가장 널리 사용되는 Man/Month 인건비 산정 방법을 선택하고 있습니다. Man/Month 계산에서 1일 근무시간은 8시간 입니다. 일주일은 5일 근무 기준이죠. 1달 프로젝트라면 대략 25일로 봅니다.
여러분의 인건비 단가는 한국 소프트위어 산업협회의 “2010년도 적용 sw기술자 노임단가 공표“를 근거로 산정 되었고, 플래시 라는 나름 특수한 스킬을 가지고 있기 때문에 초급 기술자 일일 노임인 146,620원 보다 약간 더 받을 수 있다고 판단하여 하루 160,000원으로 산정하였습니다. 여기에 한달 진행일수인 25일을 곱해 4,000,000 원이 딱 떨어졌습니다.

1.2 디자인 부분 추가 보수

플래시 개발자들은 보통 액션스크립트 코딩 이외에도 디자인을 추가로 요청 받는 경우가 많죠? A주식회사의 입장에서는 플래시 개발자가 디자인을 같이 처리해 준다면 추가로 디자이너를 고용하지 않아도 되므로 가능하다면 여러분에게 디자인을 맡기려 하고 있습니다. 문제는 디자인은 사람마다 취향도 많이 타고, 완성되었을 때의 품질을 수량으로 측정할수가 없기 때문에, 클라이언트쪽에서 만족하지 않고 수정을 요구한다면, 여러분에게 리스크가 되버립니다. 그러므로 여러분이 디자인을 처리할 수 있다는 것을 알고 있는 클라이언트가 요구한다면 정당하게 비용을 받으세요. 다만, 어디까지나 주력이 개발이고, 디자인은 부차적인 것이므로 디자인 전업의 경우 보다는 인건비를 적게 책정하는것이 좋겠습니다. 물론, 디자인은 죽어도 귀찮다 하시는 분들은 디자인 견적을 쎄게 때려서 클라이언트로부터 다른 디자이너를 고용하게끔 만들 수도 있습니다. ^^

1.3 시간외 근무 보수

이 부분은 많은 프리랜서들이 놓치고 가는 부분인데요, 프로젝트가 촉박한 경우(뭐 촉박하지 않은 경우가 얼마나 되겠습니까만은…) 일정에 대기위해 야근도 불사하고 작업을 하게 마련입니다. 그런데 이 프로젝트의 경우는 1달 반 짜리 프로젝트를 1달만에 해치워야 하므로 부득이하게 야근을 해야할 필요가 생겼습니다. 견적을 Man/Month 로 산정할때 착각하기 쉬운 부분이 바로 이부분인데, 1달 반짜리 작업을 1달로 단축해서 작업하면 1달치의 보수를 받는게 아니라 1달 반 기간동안의 보수를 받아야 합니다. “1달에 맞게 적당한 수준으로 빨리 작업해 주세요” 라거나 “1달 반이라 코드의 품질이 떨어진다” 는 A주식회사 사정이고, 여러분은 급박하게 작업해야 하는 만큼, 여러분의 시간을 추가로 희생해 가면서 작업하는 것입니다. 프리랜서는 시간이 돈입니다. 이점 명심하세요.

2번 그룹 – 서비스 항목

이 항목들은 인건비는 아니지만 클라이언트에게 비용을 받아야 하는(받고 싶은) 항목들 입니다. 경우에 따라 생략될수도 있고 추가될 수도 있습니다.

2.1 전체 소스코드 제공

코딩을 하다보면 온통 새로운 클래스와 라이브러리만 사용하진 않죠? 많은 부분 기존 제작되어 있는 나만의 라이브러리를 가져다 새로운 프로젝트에 사용하게 됩니다. 코드의 재사용이죠. 그런데 가끔은 공개하기 꺼려지는 라이브러리가 있을 수 있습니다. 견적서는 오픈소스 커뮤니티에 기여하는 것이 아니라 회사대 회사(프리랜서)의 거래이고 이익을 창출하기 위한 경제활동이므로 비용이 발생하면 받아야 하는 겁니다. 여러분이 개발한 라이브러리를 A주식회사가 무료로 입수하면 그것이 다른 프로젝트에 사용되지 말란 법이 없기 때문에, 그것에 대한 리스크를 비용으로 청구한다는 개념입니다.

2.2 컴파일 방법 및 개발환경 제공

보통 플래시 산출물과 소스코드 모두를 클라이언트에게 넘겨주었는데도 1년후에 전화와서 수정을 요청받는 경우가 있습니다. A주식회사에서는 컴파일을 할 줄 아는 사람이 없는거죠. 그런 경우라고 하더라도 내부에 개발자 한명쯤은 있게 마련이므로, A주식회사의 개발 담당자에게 swf 를 컴파일 하는 방법을 알려주게 되고, 이 과정은 여러분이 A주식회사로 방문해 담당자에게 설명하는 시간을 사용하는 것이므로 역시 비용이 발생하게 됩니다. 출장비 정도라고 생각하시면 되는거죠.

3번 그룹 – 직접 경비 항목

이 그룹은 항목을 보시면 쉽게 알 수 있는 내용이므로 항목마다 자세한 설명은 생략합니다. 원래 이런거 받는거냐고요? 받고싶지 않으시다면 안받으셔도 됩니다. 하지만 점심시간에 점심은 먹어야죠? 회사에 고용되어 일하면 식대 나오죠? 식대를 받고 싶지 않으시다면 안받으셔도 됩니다. ^^

4번 그룹 – 합계

일단 각 그룹별 소계의 총계를 내고, 원천징수 3.3%를 제한 나머지 96.7%의 금액을 합계로 냅니다. 천원 단위 미만은 A주식회사에 인심 쓰시고요. 이렇게 나온 최종 금액이 견적서 상단의 B. 견적금액 항목에 쓰여집니다.

D. 발행일, E. 유효기간

견적서에는 유효기간이라는 것이 존재합니다. 작년에 작성한 견적서를 갑자기 올해 들이대며 “이 견적서대로 해주세요” 라는 말을 듣게 된다면 당황스럽겠죠? 작년에 비해 여러분의 경력은 1년 늘어났잖아요.

F. 기타

이 항목에는 예시로 써 놓은 항목 외에도 요구하고 싶은 내용이라던가, 세부명세 항목에 부연설명이 필요한 부분을 설명해 놓습니다. 샘플로 작성되어 있는 항목을 참고하여 넣고 싶은 내용을 추가하세요..

* * * * *

몇 가지 요령과 필수 지식

1. Excel 파일 보다는 pdf 파일로 보낸다.

크게 두 가지 이유가 있습니다. 우선 문서를 열었을때 엑셀 파일 보다는 pdf 파일이 좀 더 모양새가 납니다. 인쇄 했을경우 좀더 인쇄본에 가깝기도 하고 말이죠. 그리고 그보다 더 중요한 이유는 문서를 기본적으로 수정할 수 없도록 만들어 혹시 있을지 모르는 임의의 조작을 예방하고, 이 견적으로 확정한다는 느낌으로 가는 거죠. 수정할수가 없으니까요.

마이크로소프트 엑셀에서 pdf 파일로 저장하는 방법은 간단합니다. 혹시 아래와 같은 메뉴가 없다면 구글링 해서 해결하세요.

마이크로소프트 오피스 엑셀에서 pdf 파일로 저장

2. 견적 항목은 구체적일수록 좋다.

위의 세부 명세 부분에서 견적 항목들중에는 다른 견적서에서는 상당히 보기 힘든 세세한 부분이 있다는 것을 느낀 분이 많을겁니다. 프리랜서의 견적서 답지 않게 말이죠. 일부러 이렇게 견적을 내는 이유는 이 견적서에 타당성을 부여하기 위함입니다. 항목이 세세하게 기술되어 있으면 실제 비용이 이렇게 저렇게 필요하고, 약간의 견해차이는 있을지언정 전체 견적이 뺀찌 맞는 경우는 없습니다.
사실 견적서에 “Alpha 프로젝트 전체 프로젝트 산출물 납품” 이라는 항목으로 최종 금액만 떡 하니 써도 될것 같지만, 실제로 그런 견적서는 클라이언트를 납득시킬 수가 없습니다. 또한 그런 뭉뚱그린 견적서는 네고 대상이기도 하죠.

3. 네고(negotiation:협상을 통한 할인)를 고려한다.

자신이 생각하는 적정 보수보다 약간 높게 견적 한 후 네고해 주는 것도 방법입니다. 깍아주겠다는데 마다할 사람 없고, 우리나라 사람이라면 두말할 것도 없죠.
이때 네고를 해줄 수 있다는 의향을 컨택 포인트(실무자 또는 협상대상자)에게 슬쩍 띄워주는 것이 요령입니다.
그러나 네고를 할 경우 할인율은 너무 과도하게 책정하지 않는 것이 좋습니다.
또한 네고 요청이 들어올 경우를 대비해서 최초 견적을 너무 타이트하게 하지 않는 것도 요령이죠.

4. 견적서는 한번으로 끝나지 않는다.

우리나라는 보통 이렇습니다. “이런이런거 할 예정입니다. 보수는 얼마나 원하시는지 언제까지 알려주세요.” 견적서를 달라고도 하지 않습니다. 보통 이런 경우 프리랜서에게 책정된 보수가 있음에도 불구하고 프리랜서가 얼마나 받고 싶은지 떠보는거죠. 요건(요구조건)정리도 그냥 전화로 하는둥 마는둥입니다. 결국 가격만 알고 싶다는 거죠. 프로그램의 품질은 어떻든 이 사람들에게는 중요한 것이 아닙니다. 경험상 이런경우 개발자에 대한 기본 예의가 없는 회사인 경우가 대부분일 뿐더러, 결정적으로 보수는 “무조건 싸게” 이므로 참여하지 않는것이 정신 건강상 좋습니다.

내 가격이 다소 높더라도 회사쪽에서 필요하면 ok 해주는 그런 거래가 장기적으로 좋습니다. 실제 작업에 참여하게 되는 프로젝트는 한번의 견적으로 끝나지않고 약간의 조정을 거치고, 요건정리도 가능하면 많이 해서 다시 견적하는 경우가 많습니다. 아무래도 그럴 수 밖에 없겠죠? 요건에 따라 기간도 바뀌고, 보수도 바뀔 수 밖에 없으니까 말이죠.

5. “이번만 잘 해주면 다음 작업이 계속 있어요.”

라고 말하는 회사가 있죠. 실제로 상당히 많습니다. 이번 프로젝트의 보수를 싸게 해주면 다음 작업이 계속 있으니까 그때 잘해주겠다는 건데, 절대 다음 작업이 여러분에게 돌아오지 않습니다. 설사 돌아오더라도 그만그만한 낮은 금액의 견적서를 또 요구받게 됩니다. 애초에 그런 회사와는 거래를 시작하지 마세요.

* * * * *

마치며

견적서를 작성하고 보니 상당히 리얼한 견적서가 되고 말았군요. 이 견적서를 보시는 여러분 중에서는 “프리랜서 견적서 치고는 금액이 견적이 너무 약하다.” 라고 생각하는 분도 있을 수 있고, 좀 더 초보에 가까운 프리랜서 분들 중에서는 “한달에 6백만원이 넘게 견적서를 보내면 연락이 안올거 같은데?” 하는 걱정을 하실 수도 있습니다만, 어디까지나 이 견적서는 예시에 불과하고, 실제로 견적을 내는 주체는 여러분이므로, 상황에 따라 유연하게 견적서를 작성하시라는 의견을 드리고 싶습니다.
다만, 견적은 쿨하게 내세요. 결국, 견적서란

“나는 내가 가지고 있는 기술과 시간을 이 가격에 팔겠다”

라는 표현의 문서인거죠.

이 포스트가 프리랜서 여러분들에게 실질적인 도움이 되기를 바라며 글을 마칩니다.

2011년 11월 29일에 추가

지디넷 코리아에 아래와 같은 기사가 올라왔군요.
SW노임단가제, 16년만에 접은 이유

노임단가제는 서서히 사용되지 않을 전망입니다. 견적서 작성에 참고하세요.

A. Object Pool의 의미

객체 재사용 이라고 해서 뭐 엄청난 방법이 필요한 것은 아닙니다. 가장 쉽게 사용할 수 있는 방법으로는 Array 나 Vector 또는 Object 와 같은 컬렉션(Collection) 형태의 자료구조에 객체를 만들어 넣어두고 필요한 만큼 사용한 후, 필요없어진 객체를 다시 반납하는 방식으로 로직을 구성하면 됩니다.

Object in Pool !!!

이러한 구조를 객체 풀 또는 오브젝트 풀(Object Pool) 이라고 부르고, 오브젝트 풀로부터 객체를 획득하는 행위를 풀링(pooling) 한다고 표현합니다.Pool은 우리도 흔히 사용하는 단어 입니다. [구글 사전 링크] 수영장의 그것을 일컫는 단어이기도 하고요, 제안서에서도 자주 “인력 풀” 과 같은 형태로 자주 등장합니다. 스타크래프트의 저그 종족에서 저글링을 생산하기 위한 기본 건물을 스포닝 풀(Spawning Pool : 산란못)이라고 부르죠. 어떠한 대상이 모여있는 특정 장소라는 원래의 뜻을 가지고 있습니다.

오브젝트 풀을 다음과 같이 두 가지로 형식으로 구분할 수 있습니다.

B. 정적 오브젝트 풀

애플리케이션이 시작될때 미리 필요한 객체를 (정적으로) 만들어 놓고 시작하는 방식으로

1. 필요한 객체 숫자가 정해져 있는 경우
2. 필요한 객체의 숫자가 아주 많지 않은 경우

에 사용합니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package
{
	import flash.display.Sprite;
 
	public class FixedPoolTestDrive extends Sprite
	{
		private var _itemList:Array = [];
 
		public function FixedPoolTestDrive()
		{
			createItem( 10 ); // 객체는 미리 생성
 
			var item:Item = getItem( 3 ); // 3번 인덱스는 4번째 원소
			item.y += 100;
		}
 
		private function createItem( $num:uint ):void
		{
			var i:uint, item:Item;
			for ( i = 0; i < $num; ++i )
 			{
 				item = new Item;// 고정된 숫자만큼의 객체를 미리 생성
 				item.x = ( item.width + 5 ) * i;
 				addChild( item );// 더 이상 객체를 생성할 일이 없기 때문에 addChild()와
 				_itemList[ i ] = item;// 배열에 넣는것을 미리 다 해 놓는다.
 			}
 		}
 
 		private function getItem( $index:uint ):Item
 		{
 			if ( $index <= _itemList.length )
				throw new Error( "Item 객체의 인덱스는 0 부터 " + ( _itemList.length - 1 ) + "번 까지 있고 " + $index + "번은 목록에 존재하지 않는 인덱스입니다." );
			return _itemList[ $index ];
		}
	}
}

C. 동적 오브젝트 풀

애플리케이션이 시작되는 시점에는 객체의 숫자가 0으로 시작하고 요청이 들어오면 필요한 만큼 new 로 생성해서 사용하는 방식으로

1. 필요한 객체의 숫자를 정할 수 없는 경우
2. 필요한 객체의 숫자가 많은 경우
3. 또는 객체의 사용 갯수의 폭이 실행때마다 상당히 다른 경우(어떤 경우는 조금 사용하고, 어떤 경우는 많이 사용하는)

에 사용하면 적합 합니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package
{
	import flash.display.Sprite;
 
	public class DynamicPoolTestDrive extends Sprite
	{
		private var _itemList:Array = [];
 
		public function DynamicPoolTestDrive()
		{
			var index:uint = 3;
			var item:Item = getItem( index );
			item.y += 100;
			item.x = ( item.width + 5 ) * index;
		}
 
		private function getItem( $index:uint ):Item
		{
			// 요청한 인덱스에 해당하는 _itemList 배열을 변수에 대입. 인덱스에 해당하는 원소가 존재할수도 있고 아닐수도 있다.
			var item:Item = _itemList[ $index ];
 
			// 위의 변수에 대입된 객체가 null 이라면 아래의 조건문이 실행된다. ( not 연산자 ! 로 조건을 걸었으므로. )
			if ( ! item )
			{
				item = new Item; // 객체를 생성
				addChild( item ); // addChild() 하고
				_itemList[ $index ] = item; // 해당하는 배열 인덱스에 넣은후 return 해준다.
			}
			return item;
		}
	}
}

어떻습니까? 간단한 오브젝트 풀이지만 이것으로 얻어지는 효과는 상당히 뛰어납니다.
비행기 슈팅게임을 만드는 경우를 예로 들어볼까요? 총알을 발사할 때마다 new Bullet() 을 하여 계속 총알을 만든다면 계속 메모리 사용량이 증가할 수 밖에 없겠죠. 총알이라면 크기가 작으니 그나마 다행입니다. 적 비행기라면 어떨까요?
어차피 비행기가 총알을 발사하는 한 화면에서 동시에 공존하는 총알의 최대 갯수가 존재합니다. 그만큼의 총알만 미리 만들어 놓고 총알이 화면 밖으로 나가서 더 이상 의미가 없게 되면 다시 회수에서 재사용 하는 것입니다.
메모리 사용량은 일정 수준에서 더 이상 늘어나지 않게 되고 최종보스를 만날때까지 안정적인 동작을 할 수 있겠죠.

한 가지 주의해야 할 점은, 현재 새로 사용하고자 하는 인덱스의 객체가 사용중인지 아닌지 판단할 수 있는 장치를 마련해야 하는 점입니다. 사용중인 객체를 마구 끌어다 쓰면 곤란해지겠죠. 객체 내부의 변수, 예컨대 public var isIdle:Boolean 과 같이 플래그를 두어 구분 하는 등의 방법을 사용하면 되겠습니다.

D. 오브젝트 풀 클래스

위에서 알아본 컬렉션을 이용한 오브젝트 풀은 호스트 코드에 섞여 있는 형태이기 때문에, 오브젝트 풀이 존재하는 클래스의 코드가 매우 길어서 가독성이 떨어진다거나, 객체들이 복잡한 구조를 가지고 있는 애플리케이션 이라거나 캡슐화를 업격하게 적용해야의하는 경우에는 사용하기 어려울 때가 있습니다. 이런 고민을 여러분만 했을리는 없겠죠. 그래서 전세계 여러 개발자들이 오브젝트 풀을 클래스 화 하여 관리하는 방법을 사용합니다.

액션스크립트에서 사용할 수 있는 오브젝트 풀 클래스 중에서는 우리나라 카페쪽 커뮤니티나 개인 개발자 블로그 등에서 여러번 소개된 바 있는 polygonal.de 의 라이브러리가 가장 유명합니다. 폴리고날에서 2008년 발표한 ObjectPool 라이브러리를 이 [링크]에서 다운받아 사용해 볼 수 있습니다.

이 글을 쓰기로 처음 마음먹은 무렵에는 저 역시 폴리고날의 오브젝트 풀 클래스를 여러분에게 소개하고 원리와 사용방법을 기술하려 했지만, 사실 제가 아니더라도 이미 다른 분들이 소개하고 있는데다가, 폴리고날 오브젝트 풀의 코드를 분석해 보고 난 후 코드를 분석하는것 자체가 의미가 별로 없다는 것을 깨달았습니다. 여러분도 소스코드를 보시면 느끼시겠지만, 이해하기 어렵습니다. 사실 이해할 필요 없이 제대로 동작하기만 해도 무방하죠. 그래서 더더욱…

객체의 재사용을 다룬 이 연속 포스팅들은 원래 “제3회 PFG 트렌드 공유 오픈세미나 ” 의 세션 발표의 목적으로 초고가 쓰여진 것인데, 발표 전날 방향을 살짝 바꿔서 오브젝트 풀을 간단하게 제작해보기로 했습니다.
아래의 오브젝트 풀은 여러분에게 동작 방식을 설명하기 위해 아주 기본적인 기능만을 가지고 있습니다. 누구든지 자유롭게 수정하여 사용하실 수 있습니다. (단, 수정하실 경우에는 제 이름을 원저자로, 수정하신 분을 수정저자 정도로 표기해 주시면 고맙겠습니다.)

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

package
{
	import flash.display.DisplayObjectContainer;
	/**
	 * Simple Object Pool Class with DisplayObjectContainer
	 * @author 원종선[세계의끝] cuebrick[ at ]gmail.com http://ufx.kr/blog
	 */
	public class ObjectPool
	{
		private var _class:Class;
		private var _activeList:Array = [];
		private var _deactiveList:Array = [];
		private var _container:DisplayObjectContainer;
 
		/**
		 * 할당받을 클래스(형:type)을 지정한다.
		 * @param	$class
		 */
		public function allocation( $class:Class ):void
		{
			_class = $class;
		}
 
		/**
		 * 객체를 부모 컨테이너에 붙여서 반환받고 싶다면 설정한다.
		 * @param	$container
		 */
		public function setContainer( $container:DisplayObjectContainer ):void
		{
			_container = $container;
		}
 
		/**
		 * 이 메서드를 이용해 객체를 요청한다.
		 * _deactiveList 배열을 조회하여 객체가 존재하면 반환하고, 없으면 새로 생성하여 반환해준다.
		 * 새로 생성하여 반환해준 경우 객체를 _activeList 에 push 해 놓는다.
		 * @return
		 */
		public function getInstance():*
		{
			var instance:*;
			if ( _deactiveList.length == 0 )
			{
				instance = new _class();
 
				if ( _container )
					_container.addChild( instance );
			}
			else
			{
				instance = _deactiveList.shift();
			}
 
			_activeList.push( instance );
 
			return instance;
		}
 
		/**
		 * 사용이 끝난 객체를 오브젝트 풀에 반환해준다.
		 * 반환하면 _deactiveList 배열에 등록되고, 다시 사용할 수 있는 상태로 바뀐다.
		 * @param	$instance
		 */
		public function returnInstance( $instance:* ):void
		{
			var instance:*;
			for each ( instance in _activeList )
			{
				if ( instance == $instance )
				{
					trace( "instance 반환되었음 :", $instance );
					_deactiveList.push( $instance );
					_activeList.splice( _activeList.indexOf( $instance ), 1 );
				}
			}
		}
 
		/**
		 * 현재 사용중인 객체들의 목록을 조회
		 */
		public function get activeList():Array { return _activeList; }
 
		/**
		 * 현재 사용할 수 있는 객체들의 목록을 조회
		 */
		public function get deactiveList():Array { return _deactiveList; }
 
	}
 
}

클래스 내부에 사용중 객체 목록과 미사용중 객체 목록이 배열로 두개 있고, 호스트 코드에서 getInstance() 메서드로 요청하면 미사용중 객체 목록 배열에서 반환해주거나, 노는 객체가 없으면 새로 만들어 반환해 주는 형태입니다. 호스트 코드가 대여하거나 반납한 객체는 그에 알맞은 상태의 배열로 옮겨 놓는 방식으로 간단하게 구현하였습니다. public 메서드에 주석을 자세하게 달아 놓았으므로 그 밖의 코드에 대한 별도의 설명은 필요하지 않을것 같습니다.

호스트 코드에서는 이렇게 사용하겠죠.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 오브젝트 풀 객체를 생성
var _pool:ObjectPool = new ObjectPool;
 
// MyClass 형의 객체로 클래스 할당
_pool.allocation( MyClass );
 
// 풀에 객체 요청하고 변수에 대입
var instance:MyClass = _pool.getInstance();
 
// 객체를 컨테이너에 붙임
addChild( instance );
 
// 사용이 끝나면 풀에 객체를 반환함
removeChild( instance );
_pool.returnInstance( instance );

pool 에다가 getInstance() 해서 객체를 새로 받아오다니, 마치 손안대고 코를 푸는것 같은 느낌같지 않습니까?

E. 객체 재사용의 효과

객체를 재사용하게 되면 다음의 몇 가지 긍정적인 효과를 기대해 볼 수 있습니다.

1. 런타임 성능 향상 (Improve run-time performance)
2. 메모리 누출 방지 (Prevent memory leak)
3. 안정적인 동작 (Running stable)

E-1. 런타임 성능 향상

애플리케이션이 시작, 초기화 하면서 사용될 객체를 모두 만들어 놓은 경우라면, 런타임에 new 를 연산하느라 버벅일 필요가 없겠죠. 따라서 런타임에 성능 향상이 일어날 수 있습니다. 동적으로 풀을 구성한 경우라도 어쨌건 무분별하게 객체를 생성할 가능성이 줄어들므로 마찬가지로 성능 향상을 꾀할 수 있겠습니다.

E-2. 메모리 누출 방지

어딘가에 버려졌지만 addEventListener 가 달려있다는 죄로 GC(가비지 컬렉션)가 수집도 안해가는 불쌍한 객체들이 없어지게 되므로, 메모리 누출 현상이 획기적으로 줄어들 가능성이 있습니다.

E-3. 안정적인 동작

쓸데 없이 객체를 생성하지 않고 계속 재사용 하게 되므로, GC가 돌아도 별로 수거할 것이 없게 될 가능성이 높습니다. “가비지 컬렉션에 대한 이해” 편에서 설명한것과 같이 GC가 돌게 되면 (특히 플래시 플레이어 같이 싱글 쓰레드라면 더욱더) 모든 동작을 멈추고 GC를 돌리게 되므로 플래시 애플리케이션이 순간적으로 멈칫거리는 현상이 발생하게 되는데, 오브젝트 풀을 사용한다면 GC가 할일이 거의 없게 되므로 전체적으로 랙이 줄어드는 안정적인 동작을 기대해 볼 수 있습니다.

그런가 하면

1. 전체적인 메모리 사용 총량은 약간 올라가는 경향이 있고,
2. 에러발생율이 낮아지는 효과가 있습니다. (특히 null 객체 에러)
3. 또한 GC를 사용 하지 않는 것을 전제로 하기 때문에 메모리 관리를 개발자가 직접 해야 하는 귀찮음 정도는 감수해야겠죠. (머릿속으로 메모리를 계산)

이렇게 액션스크립트에서의 객체 재사용(재활용) 과 오브젝트 풀에 관한 세 개의 연속 포스팅을 살펴보았습니다. 객체를 재사용 하는 것 정도는 객체지향 프로그래밍을 하는 개발자들에게는 기본기라고 할 수 있을 정도 이므로 여러분들도 꼭 알아두시고, 실천에 옮겨, 프로그램의 수준을 한 단계 높이길 바라겠습니다.

A. 가비지 컬렉션 일반론 Gabage Collection Overview

프로그래밍을 하면서 사용한 객체는 메모리를 소비해야 하기 때문에 운영체제에서 빌려와서 사용하게 됩니다. 메모리를 빌려와 그 공간에 객체를 기록하는 행위를 할당(allocation) 이라고 합니다. 그리고 객체를 사용한 후 더이상 필요가 없어지게 되면 객체를 운영체제에 반납하는 절차를 거쳐야 합니다. 마치 도서관에서 책(객체)을 대출한 후 열람실(메모리)에서 열람하는 것과 같다고 볼 수 있습니다.

그런데 프로그래밍이라는 것이 컴퓨터가 하는것이 아니라 개발자라는 사람이 하는 것이라, 운영체제에서 빌려온 메모리를 반환하지 않고 빼먹는 개발자가 있기도 합니다. 프로그램이 짧은 시간 동안 실행되고 종료 되는 것이라면 큰 문제는 아니지만, 서버용 프로그램과 같이 프로그램이 실행 한 후 오랜 시간 동안 실행 상태를 유지해야 하는 경우에는 메모리에 더 이상 사용하지 않게된 메모리들이 점점 쌓이는 한편, 새로운 메모리는 계속 요구 되기 때문에 언젠가는 메모리가 꽉 자서 옴짝 달싹 할 수 없게 됩니다. 이런 것을 메모리 유출(memory leek) 현상이라고 하여 프로그램 에러의 가장 치명적인 원인이 됩니다.

그래서 현대의 고급 프로그래밍 언어에는 이런 메모리 반납 과정을 자동으로 처리해 주는 Gabage Collection (이하 GC) 이라는 것이 생겨났습니다. 프로그래머가 사용한 후 필요 없어진 객체들은 GC가 정기적으로 수거하고 메모리에서 소멸시켜버려 다시 메모리를 사용할 수 있는 상태로 만들어주는거죠. 위에서 한 도서관의 비유를 계속 이어나가자면 가비지 컬렉션은, 우리가 그 존재를 눈치채기는 쉽지 않지만, 더이상 아무도 읽지 않거나 너무 낡아 책으로서의 가치가 없어진 것들을 수거해서 처리하는 사서에 비할 수 있을것 같습니다.

그러나 GC는 메모리 반환을 하기 귀찮아 하는 게으른 프로그래머를 위한 도구라기 보다는, 프로그래머가 메모리 반환 같은 단순한 일에 신경쓰지 않고 보다 큰 개념의 로직이나 구조적인 프로그래밍에 집중할 수 있도록 도와주는 역할을 한다고 보는것이 타당합니다.

B. Mark, Sweep and Compact

GC가 동작하는 방식을 그림으로 표현해 보겠습니다.

Mark, Sweep & Compact

1. Mark – 참조되고 있지 않은 객체를 표시(mark) 한 후,
2. Sweep – 표시된 객체를 쓸어(sweep) 버리고,
3. Compact – 중간중간 구멍이 뚫려 있는 메모리 공간을 남아있는 객체를 스스슥 이동해서 디스크 조각모음을 하듯 공간을 확보합니다.^[01]

이 과정을 개발자가 신경쓰지 않아도 플래시 플레이어의 GC가 수행합니다. 상당히 편리하겠죠? 객체가 변수에 대입되거나, addEventListener() 메서드가 달려있거나 하는 등의 참조가 되어있다면 GC가 mark 를 하지 않습니다. mark 가 되지 않으면 sweep 되지 않으므로 그 객체는 GC에 의해 삭제당할 가능성이 없는 상태가 됩니다.
위의 내용을 Grant Skinner가 시뮬레이션 할 수 있게 만들어 놓은 [링크] 를 확인해 보세요.

그러나 지금까지의 설명은 객체지향 프로그래밍의 GC에 대한 일반론에 불과합니다. 액션스크립트에서는 이와같은 일반론에 더해지는 몇 가지 특수한 상황들이 존재합니다.

C. 액션스크립트 개발자의 입장에서 본 GC

액션스크립트 역시 Java 의 연장선상에 있는 현대의 고급 프로그래밍 언어에 속하기 때문에 GC를 이용한 메모리 회수 방식을 사용합니다. 그런데 플래시 개발자들이 알아야만 하는 몇 가지 사항이 더 있습니다.

C-1. GC를 강제로 실행시킬 수 없다.

GC는 운영체제가 플래시 플레이어에게 할당한 일정 분량의 메모리가 고갈되어갈 무렵에 실행되기 때문에 그 실행 시점을 정확히 알 수 없습니다. 또한, 버그로 동작되는 상황을 제외하고는 개발자가 GC의 동작을 시작시킬 수 없습니다. NetConnection 객체를 고의로 두번 호출하면 이 객체를 회수하기 위해 GC가 동작하게 되고 try…catch로 감싸놓으면 런타임 에러가 발생하지 않게 되는 버그가 있습니다만, 정상적인 처리 방법이 아닐뿐더러 Adobe 에 의해 언제 패치될지도 모르므로 사용하지 않는것이 좋습니다.

C-2. GC가 도는 시점이 문제.

대부분의 플래시 플레이어는 웹 브라우저에 플러그인 형태로 실행되기 때문에 플래시 답게 항상 가벼운 동작을 기대하지만, 실제로 GC가 돌기 시작하는 시점은 이미 무거워질대로 무거워져 물기를 흠뻑 머금은 스펀지와 같은 상황일때가 되고 나서인 경우가 대부분 입니다. 우리가 플래시에게 기대하는 것은 이런것이 아니겠죠.

C-3. GC의 수거대상이 되게 하기 위한 준비작업의 번거로움.

객체를 가비지 컬렉션 대상이 되게 하기 위해서는 변수가 가리키는 모든 참조 제거, 객체에 붙여놓은 이벤트리스너 모두를 제거한 후, 변수에 null 을 대입해야 합니다. 이렇게 글로 표현하는것은 쉽지만, 실제 코드상에서는 이 객체가 어디서 몰래 참조되고 있는지 알 수 없는 경우도 꽤 됩니다. 게다가 이런 절차는 네이티브 개발자 출신이 아닌 경우가 많은 플래시 개발자의 입장에서는 번거롭게 느껴지기 마련이고, 그냥 내버려 두는 경우가 대부분이죠.

C-4. GC가 돌아도 문제.

우여곡절끝에 GC가 돌아도 문제가 여전히 남아 있습니다. GC가 실행될때는 프로그램이 일시적으로 중단되는 현상을 발견하게 됩니다. GC 대상이 많은 경우라면 체감할 수 있을 정도죠. 게다가 플래시 플레이어는 기본적으로 싱글 쓰레드 이기 때문에 프로그램 실행을 모두 일시 중단하고 GC를 돌린 후 다시 프로그램을 실행 하게 되므로 멈칫거리는 현상이 더욱 잘 느껴집니다.

D. Gabage Collection vs. Object Pool

플래시로 만들어진 대부분의 일반적인 웹 애플리케이션들은 GC에게 객체의 수명관리를 맡겨도 무방합니다. 어차피 플래시 애플리케이션은 대부분 웹 브라우저에 플러그인 형태로 보여지게 되고, 플래시가 차지하고 있던 메모리는 브라우저가 종료되는 시점에 동시에 회수되는 브라우저 의존적인 형태라 실행되는 지속 시간이 그리 길지 않기 때문이죠.

그러나 게임과 같이 생성해야 하는 객체의 숫자가 많고, 지속시간도 대체로 긴 편이면서, 그 객체가 차지하는 메모리 크기가 큰 경우에는 GC 보다는 객체 풀(Object Pool) 방식으로 객체를 재활용 관리하는 것이 보다 좋은 선택이라 할 수 있습니다.

객체 풀 방식에 대해서는 “액션스크립트의 객체 재사용을 위한 오브젝트 풀(Object Pool)” 에서 이어집니다.

1. Java 에서는 이 compact 과정이 존재하는데, 플래시 플레이어가 이 과정을 수행하는지는 확실히 알려져 있지 않습니다.

그러나 사용자들의 웹 애플리케이션에 대한 기대치가 높아지고 플래시로 만들어진 다양한 형태의 애플리케이션이 등장함으로서 보다 높은 차원의 프로그래밍 스킬이 요구되는 경우가 생겼습니다. 객체 재사용(재활용) 은 그런 한 단계 높은 차원의 프로그래밍 스킬 중 하나라고 볼 수 있는데요, 객체를 재사용 하는 방법에 대해 몇 개의 연속 포스팅으로 알아보겠습니다.

제가 이 주제에 대해 포스팅을 하게 된 직접적인 계기가 된 일이 있습니다. 얼마전 액션스크립트 카페에 아래와 같은 질문이 올라왔었습니다.^[01]

A. 질문 사례 (Case Study)

가비지컬렉션에 대한 문서들을 수집해서 보는중인데
대부분 재활용을 극대화하라는 내용으로 끝을 내더라구요.(한계?!)

0
1
2
3
4
5
6
7
8
9
10
11
12
13

//Sprite 변수
var myObject:Sprite;
 
/* 등록 */
myObject = new Sprite();
addChild(myObject);
 
/* 삭제 */
removeChild(myObject);
myObject = null;
 
/* 재활용?! */
myObject = new Sprite();
addChild(myObject);

이런식으로 사용하라는 건가요?
아니면 다른 좋은 예가 있을까요?

위와 같은 질문에 제가 아래와 같이 답변을 달았습니다.

한계가 아니라 그렇게 하는것이 객체지향 언어의 기본입니다.
플래시가 워낙에 언어적 기반이 없는 초보 개발자들이 많은 동네다 보니 이런 부분이 덜 중요하게 인식되는것 뿐이죠.

예로드신 방법은 재활용에 해당하지 않습니다.
재활용은 변수를 재활용하는것이 아니라 객체를 재활용하는 것이거든요.
변수는 백만개 만들어도 성능에 크게 지장 없습니다.
그러나 객체를 백만개 만들면 플래시가 뻗어버리겠죠.

아래와 같은 클래스가 있습니다. 잘 살펴보세요. 어떤 구조를 가졌는지..

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// MyObject 클래스
package
{
    import flash.display.Sprite;
 
    public class MyObject extends Sprite
    {
        private var _form:int = 0;
 
        public function MyObject()
        {
            init(); // 최초 실행시에 초기화
        }
 
        public function init():void
        {
            _form = 0; // 변수를 초기화
            // 그 밖의 각종 초기화 코드 (시각적인것을 포함하여 xml 등의 데이터 등도 초기화)
        }
 
        public function setForm( $form:int ):void
        {
            _form = $form; // 변수에 저장하고 그것을 이용해
            // 이 객체의 여러가지 형태를 설정 (아마도 시각적인것)
        }
    }
}

그리고 호스트코드에서 아래와 같이 사용합니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 변수
var myObject:MyObject; // Sprite 가 아니라 MyObject 클래스 입니다. (요주의, 아래에 설명 되어있음)
 
/* 생성 */
myObject = new MyObject(); // new 는 여기서 한번만 합니다.
myObject.setForm( 3 ); // 3번 형태로 사용
addChild(myObject);
 
/* 재활용 */
myObject.init(); // 초기화시킴
myObject.setForm( 2 ); // 2번 형태로 재사용
 
/* 삭제, (그러나 같은 유형의 객체가 다시 등장할것 같으면 삭제하지 않음) */
removeChild(myObject);
myObject = null;

Sprite 따위를 왜 재사용해야하나 하는 생각 때문에 질문을 작성하신듯 한데요,
Sprite 에 graphics 패키지를 이용해 그림이라도 열나게 그리지 않는 이상, Sprite 형의 객체에 초기화 할 일은 많지 않겠죠.
코드로 전부 설명해 놓았으니 여러번 읽어보세요.

new 를 단 한번 한다는 것이 재활용의 포인트 입니다.
좀더 깊은 곳으로 가면, new 조차도 다른 객체에 의뢰하여 해당 클래스 안에서는 new 가 필요 없게도 하는 경우가 있습니다.

B. new 연산자.

프로그래밍에서 객체를 생성한다는 것은 좀 남다른 의미를 가집니다. 바로 무(無)에서 유(有)를 창조해 내는 과정이기 때문이죠. 액션스크립트에서는 class 를 설계도 삼아 new 연산자를 이용해 실제 객체를 생성하게 됩니다. 문제는 이 과정이 컴퓨터의 자원을 가장 많이 사용하는 연산중 하나라는 사실이죠.

게다가 액션스크립트에서 다루는 객체들의 대다수는 DisplayObject 를 상속한 객체들이기 때문에, 객체 하나하나의 데이터 크기가 큰 편이라, 객체를 재사용 하면 경우에 따라 그 효과가 눈에 보일정도로 좋아지게 됩니다.

위의 질문 내용으로 다시 올라가 코드를 다시 보면, 객체를 재활용 하고 있지 않다는 것을 알 수 있습니다. 1번 라인에서 선언된 변수 myObject 는 가장 아랫 라인까지 재활용 하고 있지만 객체는 두 번 new Sprite() 하고 있죠. 즉, 변수는 재활용을 하고 있는데, 정작 객체는 이전 객체를 버리고 새로 객체를 만들어 사용하고 있습니다. 두 번째 객체를 생성하여 myObject 변수에 대입한 순간에 이전에 만든 객체는 참조할 수 있는 방법을 잃어버려 개발자는 이 객체에 두 번 다시 접근할 수 없습니다. 더군다나 이 객체에 addEventListener() 라도 달려있다면 쓰레기(gabage) 상태로 메모리에 남아 플래시 플레이어가 종료될때까지 계속 살아있게 됩니다.

이 쓰레기에 대한 정체를 파악해 보고자, 다음 내용은 “플래시 플레이어의 가비지 컬렉션(gabage collection)에 대한 이해” 로 이어집니다.

1. http://cafe.naver.com/flashactionscript/53831

A. Polymorphism in ActionScript (액션스크립트에서의 다형성)

그럼 액션스크립트에서는 다형성이 어떻게 나타나는 걸까요?
먼저 위키백과 한글판의 OOP 항목에 나타난 다형성에 대한 설명을 인용해 보겠습니다.

다형성이란 같은 메시지에 대해 클래스에 따라 다른 행위를 하게 되는 특징이다. 일반적으로 같은 이름을 가지는 메서드에 대해 인자(Argument)의 개수와 데이터형(Data Type)에 따라 수행되는 행위가 달라짐을 의미한다. 다형성을 통해서 사용자는 약속된 인터페이스를 따르는 서로 다른 객체를 같은 방식으로 사용 할 수 있게 된다.

상당한 숫자의 플래시 개발자들이 해당되겠습니다만, 여러분이 액션스크립트 이전에 다뤄본 객체지향 언어가 없다면 위의 설명만으로는 다형성이 도무지 무엇인지 이해할 수가 없을 것입니다. 특히나 액션스크립트같이 다뤄지는 객체 대부분이 시각적인 표현을 다루는 경우라면, 다형성이라는 개념은 “단지 여러가지 형태를 가지고 있는 그 어떤것” 정도의 피상적인 개념만 느끼게 되는거죠.

“MovieClip 으로 만든 객체가 여러가지 형태(디자인)을 가지고 있는게 다형성인가?”

또는,

“라이브러리 패널에 MyButton 이라고 클래스 이름 정의된 자원이 있다면 var button1:MyButton = new MyButton( “blue” ); 할때도 있고, var button2:MyButton = new MyButton( “red” ) 할수도 있는 등, 형태 또는 색상을 바꿔서 사용하는게 다형성 일걸?”

이것도 아니면,

“하나의 상위 클래스를 상속한 하위 클래스가 여러 가지 type 인 상황이 다형성이겠지?”

네이티브 개발자들이 보면 한참 웃다 잃어버린 배꼽을 찾으러 돌아다닐 것 같은 이런 생각들을 초보 플래시 개발자들이 실제로 하고 있습니다.

그러나 액션스크립트의 다형성이라고 다른 언어의 다형성과 다르지 않습니다.

다형성(多形性)의 한자에서 가운데 “형(形)”은 프로그래밍 적인 관점으로 해석했을때 type 입니다. 즉, 하나의 객체가 여러가지 type 을 가질 수 있다는 의미 입니다. 객체지향 프로그래밍에서 type 이란 무엇인가요? 바로 Class 이름이죠. var button:MyButton 과 같이 변수를 생성 했을때 MyButton 이 바로 Class 이름임과 동시에 button 객체의 type 입니다. 결국, “객체가 여러 가지 Class 형태를 가지게 된다.” 라고 다형성을 바꿔서 설명할 수 있습니다.

언뜻 이해가 안될 수도 있습니다. 아니, 어쩌면 초보 플래시 개발자는 이해가 되지 않는게 당연한 것일테니 실망할 필요는 없습니다.

그럼 이 부분을 설명하기 위해 객체지향 프로그래밍에서 하나의 객체를 생성하면 컴퓨터는 어떻게 이 객체를 생성하며 인식하게 되는지 알아야 할 필요가 있습니다. 이 부분을 이해하게 되면 어째서 다형성이 구현될 수 있는지 논리적 근거를 이해하게 됩니다.

컴퓨터, 그러니까 우리는 이것을 컴파일러라고 볼 수도 있고 플래시 플레이어라고 볼 수도 있습니다. 어떻게 생겨먹은 녀석이건 간에 우리가 var button:MyButton = new MyButton() 이라고 코딩했을때 이 녀석은 상속 체인상의 모든 부모 객체를 만들어 냅니다. 여러분은 그런거 본적이 없다고 해도 사실이 그렇습니다.

우리는 코드로 설명하면 이해가 빨리 되죠?
MyButton.as 파일에는 아래와 같이 코딩 되어 있을겁니다.

0
1
2
3
4
5
6
7
8
9

package
{
	public class MyButton extends Sprite
	{
		public function MyButton()
		{
			// 관련 코드들
		}
	}
}

위의 클래스 정의를 보면 MyButton 클래스는 Sprite 를 상속(확장) 했음을 알 수 있습니다.
이 클래스를 호스트 코드에서 var button:MyButton = new MyButton(); 하는 순간 컴파일러는 MyButton 객체와 Sprite 객체와 DisplayObjectContainer 객체와 InteractiveObject 객체와 DisplayObject 객체와 EventDispatcher 객체와 최상위의 Object 객체까지, MyButton 의 상속 체인상 모든 type 의 객체를 실제 만들어서 메모리상에 기록합니다.

var button:MyButton = new MyButton(); 을 하게 되면 상속 체인상의 모든 객체들이 생성됩니다. 다만 받아내는 변수에 따라 가리키는 대상이 다를뿐!!

그리고 위와같이 호스트 코드에서 new MyButton() 를 하고 var button:MyButton 에 대입하게 되면, 생성된 총 7개의 객체중 한 가지 type 인 MyButton type의 객체만 실제로 사용하게 됩니다. 대단한 낭비라고 생각하실지 모르겠습니다만, 실제로 컴파일러나 플래시 플레이어는 이렇게 작동합니다. 그런데 다형성이 구현되는 논리적인 근거가 여기에 있습니다. 그 근거가 무엇인지는 잠시 후에 살펴 보기로 하고,

아래의 호스트 코드를 보실까요?

0
1
2
3
4

// MyButton 형으로 생성하고 MyButton 형의 변수에 대입함
var button:MyButton = new MyButton();
 
// MyButton 형으로 생성했지만 Sprite 형의 변수에 대입함
var button:Sprite = new MyButton();

위의 코드는 둘다 유효한 코드 입니다. 전자의 경우는 생성과 변수를 같은 type 으로 한 경우이고, 후자의 경우는 하위클래스로 생성하고 상위 클래스의 변수로 받은 상황 입니다. 후자의 경우에는 암시적 형 변환이 일어났다고 표현하죠. 즉, 아래와 같은 코드를 한 줄로 표현한거라 할 수 있습니다.

0
1
2

var button:Sprite; // Sprite 형의 변수 선언
var myButton:MyButton = new MyButton(); // MyButton 형의 객체 생성
button = myButton; // 상위 형의 변수에 하위 형의 객체를 대입. 암시적 형 변환이 일어남

형 변환(casting: 캐스팅)이란 단어는 초보 개발자라 할 지라도 어떤 것인지 익히 알고들 계실 겁니다. 위와 같이 관련된 다른 type 으로 변형 하는 것을 형 변환 이라고 하는 거죠. 관련이 없는 type 끼리는 형 변환이 실패하게 됩니다. 형 변환은 기본적으로 상속 체인상의 상하위 클래스간의 형 변환만이 가능합니다. (아래쪽, 형 변환의 제한 참고)

형 변환에 대해 좀더 알아보고 넘어가겠습니다. 이 포스트에서는 “형 변환”이라는 우리말 표현과 “캐스팅”이라는 영어식 표현을 혼용해서 사용하고 있습니다만, 이해를 돕기 위해 사용한 것일뿐, 완전히 동일한 것을 가리키는 표현입니다.

하위 type에서 상위 type으로 형 변환 하는 것을 up-casting (업 캐스팅) 이라고 하고, 그 반대의 경우를 down-casting (다운 캐스팅) 이라고 합니다. 업 캐스팅은 위의 호스트 코드에서 본 것과 같이 암시적 형 변환이 가능하지만 다운 캐스팅은 명시적 형 변환만 가능합니다. 이 내용은 아래에서 다시 자세히 살펴보겠습니다.

0
1
2

var button:Sprite = new MyButton();
var myButton:MyButton;
myButton = button as MyButton; // as 연산자로 캐스팅 할 수도 있고 myButton = MyButton( button ) 과 같이 캐스팅 할 수도 있음

위에서 new MyButton() 하게 되면 총 7개의 객체를 메모리에 생성한다고 했죠? 형 변환이 일어나게 되면 변수가 가리키는 대상이 형 변환이 일어난 type 을 가리키게 됩니다.

이렇게 다형성이라는 것은 그것이 암시적이든 명시적이든 형 변환과 관계를 가지고 있습니다. 위에서 형 변환은 상속 체인에서만 일어날 수 있다고 설명하였으므로 다형성은 것은 결국 상속과 밀접한 관계를 가지게 됩니다.

1. down-casting

그러면 이렇게 형 변환을 해서 얻는 이득이 무엇인 걸까요?
초보 개발자에게 있어 형 변환을 해본 경험은 대략,

0

MovieClip( this.parent ).gotoAndStop( 2 );

위와 같은 일을 수행하기 위해서 일 것입니다. 그런데 parent 라는 속성은 DisplayObject 클래스에서 정의된 읽기 전용 속성이고 DisplayObjectContainer 를 반환하기 때문에^[01] 그보다 두 단계 하위 단계에 있는 MovieClip 형의 메서드인 gotoAndStop() 메서드를 사용할 수가 없으므로, ^[02] gotoAndStop() 메서드를 사용할 수 있도록 MovieClip( 캐스팅대상 ) 으로 형 변환 해 준다는 의미 이므로 이것은 다운 캐스팅에 해당합니다.

결국, 다운 캐스팅을 하는 이유는 이와 같이 상위 형의 클래스에는 정의 되어 있지 않은 메서드나 속성을 사용하기 위해 그것을 사용할 수 있는 형으로 변환 하기 위함입니다.

2. up-casting

그렇다면 업 캐스팅은 어떤 경우에 사용할까요? 언뜻 보기에 업 캐스팅으로 얻어지는 이득이 없을 것 같아 보일 수도 있을 것입니다. 상위 형의 클래스에는 하위 형의 클래스보다 할 수 있는 일이 적거나 같기 때문에 드는 생각이죠. 그러나 만약 형 변환이 다운 캐스팅만 존재한다면 형 변환은 거의 무의미한 행위가 됩니다. 무엇보다도 gotoAndStop() 메서드 따위를 쓰자고 형 변환 씩이나 하는건 귀찮습니다. AS2.0 에서 MovieClip 클래스가 바로 Object 클래스를 상속 받아버렸듯 그냥 상위 클래스에 모든 기능을 다 때려박으면 캐스팅이고 뭐고 할 필요가 없겠죠.

예컨대 아래와 같은 상위 클래스가 있고,

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

package
{
	public class SuperClass
	{
		public function SuperClass()
		{
			trace( "SuperClass created." );
		}
 
		public function superClassMethod():void
		{
			trace( "DoSomething in SuperClass !!" )
		}
	}
}

위의 상위 클래스를 상속한 하위 클래스가 아래와 같이 있습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

package
{
	public class SubClass extends SuperClass
	{
		public function SubClass()
		{
			trace( "SubClass created." );
		}
 
		public function doSomething():void
		{
			trace( "DoSomething in SubClass !!" )
		}
	}
}

위와 같은 상속 구조와 메서드의 경우에서는 형 변환으로 얻는 이득이 없습니다.
호스트 코드는 어떤 상황인지 볼까요?

0
1

var obj:SuperClass = new SubClass(); // 이렇게 up-casting 을 했다면
obj.doSomething(); // 컴파일 에러!!

당연한 결과죠? obj 변수는 SuperClass 형이기 때문에 doSomething() 메서드가 존재하지 않습니다.
그렇다면,

0
1
2

var obj:SuperClass = new SubClass();
obj.superClassMethod(); // 이것은 당연히 가능
SubClass( obj ).doSomething(); // 다운 캐스팅을 수행했기 때문에 이것도 가능함

위와같이 사용해야 합니다.

“에… 이거 뭔가요? 아주 불편하잖아요. 다형성 뭐하러 구현하나요?” 하는 웅성거림이 들려오는듯 합니다.

맞습니다. 단순히 형 변환만 해서는 다형성으로 인한 이득을 얻을 수 없습니다. 때문에 여기에서 중요한 키워드가 등장해야 하는데, 바로 override 입니다.

3. override

override 키워드는 상위 클래스에서 정의한 메서드를 하위 클래스에서 재정의 할때 사용합니다. 위의 두 개의 클래스 구조는 예제속에서만 존재하는 아주 간단한 상속 구조라고 할 수 있습니다. 그러나 실제로 프로젝트에서는 어떤가요? 1개의 상위 클래스에는 2개 이상, 무한대 수의 하위 클래스가 상속할 수 있습니다. 게임 설계에서 몬스터를 구현하는 내용을 예로 들어볼까요?

몬스터들은 hp 가 있고, 이리저리 로밍(roaming) 하다가, 플레이어를 발견하면 attack 하기도 하고, 플레이어에게 얻어맞으면 피해(damage)를 받게 됩니다. 또한 몬스터의 종류마다 제각각 공격력이 다를 것이므로 공격등급(rating) 속성을 가질 것이고, hp 가 일정 수준 이하로 떨어지면 도망(runAway)칠 수도 있죠.
이 내용을 가지고 Monster.as 클래스를 만들어 볼까요?

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

package
{
	public class Monster extends Sprite
	{
		protected var _hp:int = 100;
		protected var _runAwayHp:int = 10;
		protected var _rating:int = 20;
 
		public function Monster()
		{
			trace( "---몬스터 생성 공통 초기화---" );
		}
 
		public function attack( $target:Player ):void
		{
			// 플레이어 객체에 _rating 만큼의 데미지를 가함
			$target.damage = _rating;
		}
 
		public function set damage( $damage:int ):void
		{
			this._hp -= $damage;
 
			// 데이지를 받은 후 _hp 가 _runAwayHp 미만으로 떨어지면 runAway() 메서드 실행
			if ( this._hp <= 0 )
				die();
			else if ( this._hp < this._runAwayHp )
				runAway();
		}
 
		protected function runAway():void
		{
			throw new Error( "override runAway() method !!" );
		}
 
		protected function roaming():void
		{
			// 어슬렁 거리는 알고리즘 구현
		}
 
		protected function die():void
		{
			trace( "몬스터 사망" );
		}
	}
}

Monster 클래스는 아래에 나올 여러 가지 몬스터들의 공통적인 부분을 끌어올린 일종의 추상층 이라고 할 수 있습니다. Monster 클래스에서는 변수나 메서드의 접근 제한자가 public 인지, protected 인지 주의해서 살펴보세요.

다음은 Monster 클래스를 상속한 Gobblin 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package
{
	public class Goblin extends Monster
	{
		public function Goblin()
		{
			this.name = "Goblin";
			trace( this.name, "생성" );
			this._hp = 70;
			this._runAwayHp = 10;
			this._rating = 15;
			roaming();
		}
 
		override protected function runAway():void
		{
			// Goblin 의 ㅌㅌㅌ 알고리즘 구현
		}
	}
}

생성자에서 기본 스탯을 세팅했고, runAway() 메서드를 override 하여 Gobblin 만의 도망가는 알고리즘을 구현하면 되겠습니다.

다음은 Dragon 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package
{
	public class Dragon extends Monster
	{
		private var _fireRating:int = 100;
 
		public function Dragon()
		{
			this.name = "Dragon";
			trace( this.name, "생성" );
			this._hp = 200;
			this._runAwayHp = 0;
			this._rating = 50;
			roaming();
		}
 
		override public function attack( $target:Player ):void
		{
			// Dragon Monster는 기본 공격력(_rating)에 화염데미지(_fireRating)를 추가함
			$target.damage = _rating + _fireRating;
		}
 
		override protected function runAway():void
		{
			// Dragon 은 도망가지 않음
		}
	}
}

Dragon 몬스터는 기본 데미지에 화염 데미지를 더해서 총 데미지를 계산 하는군요. Monster 클래스의 기본 공격 계산과 다르기 때문에 attack() 메서드를 override 했습니다.

그리고 Troll 클래스는 다음과 같습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package
{
	public class Troll extends Monster
	{
		private var _poisonRating:int = 30;
 
		public function Troll()
		{
			this.name = "Troll";
			trace( this.name, "생성" );
			this._hp = 120;
			this._runAwayHp = 12;
			this._rating = 20;
			roaming();
		}
 
		override public function attack( $target:Player ):void
		{
			// Troll Monster는 기본 공격력(_rating)에 독데미지(_poisonRating)를 추가함
			$target.damage = _rating;
			$target.dotDamage = _poisonRating;
		}
 
		override protected function runAway():void
		{
			// Troll 의 ㅌㅌㅌ 알고리즘 구현
		}
	}
}

Troll 몬스터는 기본 데미지에 추가로 독 데미지를 주게 되는데 기본 데미지에 합산 하는 방식이 아니라 틱(tick)당 데미지를 주는 방식입니다.

위에서 보시는 바와 같이 각 몬스터 종류 마다 attack() 하여 데미지를 주는 방식이 다르므로, 데미지를 계산하고 _hp 를 깍아내는 코드는 Monster 클래스가 아닌 각각의 하위 클래스에 위치해야 합니다. 물론 Goblin클래스처럼 attack() 메서드를 override 하지 않으면 Monster 클래스에 있는 attack() 메서드의 계산이 실행 되면서 기본 데미지 만을 주게 되겠죠. runAway() 메서드도 마찬가지로 몬스터 별로 구현하는 방식이 다릅니다. 단, runAway() 메서드는 new Error() 를 던져줌으로서 하위 클래스에서 반드시 구현하게끔 하고 있습니다. 즉, runAway() 메서드는 Monster 클래스를 상속한 하위 클래스라면 반드시 override 해야 합니다.

이런 상속 구조를 가진 monster package 되겠습니다. 이 클래스들을 UML로 표현하면 다음과 같습니다.

한결 정리가 되죠?
그리고 이 몬스터들과 대적하는 Player 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package
{
	import flash.display.Sprite;
	import flash.utils.Timer;
	import flash.events.TimerEvent;
 
	public class Player extends Sprite
	{
		protected var _hp:int = 200;
		protected var _rating:int = 30;
		protected var _tick:Timer = new Timer( 1000, 5 );
		protected var _totalDotDamage:int = 0;
 
		public function Player()
		{
			trace( "---플레이어 생성---" );
			_tick.addEventListener( TimerEvent.TIMER, onTick );
		}
 
		public function attack( $target:Monster ):void
		{
			// 몬스터 객체에 _rating 만큼의 데미지를 가함
			$target.damage = _rating;
		}
 
		public function set damage( $damage:int ):void
		{
			_hp -= $damage;
			trace( "플레이어 캐릭터 hp :", _hp );
 
			if ( _hp <= 0 )
			{
				trace( "플레이어 캐릭터 사망" );
				_tick.stop();
			}
		}
 
		public function set dotDamage( $damage:int ):void
		{
			// Timer 를 이용해 시간당 데미지를 받는 알고리즘 구현
			_totalDotDamage += $damage;
			_tick.reset();
			_tick.start();
		}
 
		private function onTick( $e:TimerEvent ):void
		{
			damage = Math.round( _totalDotDamage / 10 );
		}
	}
}

Monster 클래스와 Player 클래스는 공통된 부분이 제법 보이는군요. 그렇다면 나중에 리팩토링을 통해서 Charactor 클래스로 공통된 부분을 올리고 상속을 하면 되겠군요. 그러나 이 포스트는 리팩토링에 관한 포스트가 아니므로 이 부분에 대한 공부는 다음기회로 넘기고…

그럼 이 몬스터들과 플레이어를 호스트 코드에서 돌려 볼까요?

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import flash.display.Sprite;
 
	public class MonsterTestDrive extends Sprite
	{
		public function MonsterTestDrive()
		{
			var player:Player = new Player;
 
			var monsterList:Array = [ new Gobblin, new Dragon, new Troll ];
 
			var mob:Monster;
			for each( mob in monsterList )
			{
				trace( mob.name, "몬스터가 플레이어를 공격 합니다." )
				mob.attack( player );
			}
		}
	}
}

출력 내용은…

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---플레이어 생성---
---몬스터 생성 공통 초기화---
Goblin 생성
어슬렁 어슬렁
---몬스터 생성 공통 초기화---
Dragon 생성
어슬렁 어슬렁
---몬스터 생성 공통 초기화---
Troll 생성
어슬렁 어슬렁
Goblin 이 플레이어를 공격 합니다.
플레이어 캐릭터 hp : 185
Dragon 이 플레이어를 공격 합니다.
플레이어 캐릭터 hp : 35
Troll 이 플레이어를 공격 합니다.
플레이어 캐릭터 hp : 15
플레이어가 tick 당 데미지를 받고 있음----
플레이어 캐릭터 hp : 12
플레이어가 tick 당 데미지를 받고 있음----
플레이어 캐릭터 hp : 9
플레이어가 tick 당 데미지를 받고 있음----
플레이어 캐릭터 hp : 6
플레이어가 tick 당 데미지를 받고 있음----
플레이어 캐릭터 hp : 3
플레이어가 tick 당 데미지를 받고 있음----
플레이어 캐릭터 hp : 0
플레이어 캐릭터 사망

몬스터들이 인정사정 없군요. 플레이어는 체력이 0 이 되서 결국 사망했습니다.
플레이어는 몬스터들의 attack() 메서드로 인해 데미지를 받았는데, 호스트 코드에서 순환문으로 돌릴 수 있었습니다. 이렇게 할 수 있는 것은 모든 몬스터들에게 attack() 메서드가 public 으로 존재하기 때문이죠. 그런데 Goblin, Dragon, Troll 클래스에 attack() 메서드가 존재하고 있다는 확신을 할 수 있는 것은 이 세 개의 클래스들이 Monster 클래스를 상속했기 때문 입니다.

자 그럼, 위의 호스트 코드의 순환문 for each( mob in monsterList ) 의 바로 위에 있는 var mob:Monster 에 주목하세요. monsterList 배열에 있는 각각의 원소들은 모두 데이터 형이 다릅니다. 클래스가 다르죠. 그런데 이 배열 원소를 순환할 때는 이 배열원소보다 상위 클래스인 Monster 클래스로 받고 있습니다.^[03] Monster 에도 기본형으로 attack() 메서드가 존재하므로 Goblin 과 같이 별도로 attack() 메서드를 override 하지 않았다면 Monster 클래스의 attack() 메서드가 호출되고, Dragon 이나 Troll 과 같이 별도의 데미지와 공격방식을 가진 다른 몬스터들은 override 된 attack() 메서드가 호출 되는 것입니다.

편리하죠? 우리는 순환문을 돌릴때 배열에 들어가 있는 몬스터들의 여러 가지 type에는 신경쓰지 않아도 됩니다. 만약 위와 같이 업캐스팅을 이용한 다형성을 적용하지 않으면 Goblin, Dragon, Troll용 순환문을 각각 돌려야 할 가능성이 높습니다. 또는 var mob:* 과 같이 형을 지정하지 않은 변수로 받아야 할텐데, 이렇게 되면 코드 힌트를 받지 못하는 것은 둘째 치고, attack() 메서드가 존재하는지 확신할 수 없으므로 순환문의 신뢰도가 떨어질 수 밖에 없습니다. 여러분이 만든 게임의 몬스터의 종류가 세 가지만 있을 것 같진 않죠? 이렇게 다형성을 이용하면 코드가 견고해지고 유지보수하기 편해집니다.

이렇게 다형성은 상속을 기본으로, 그중에서도 override 와 특히 깊은 관계를 가집니다.

4. parameter

한편, 메서드의 인자(파라미터)에 대해서도 다형성을 적용해 볼 수 있습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.KeyboardEvent;
	import flash.events.MouseEvent;
 
	public class HandlerExample extends Sprite
	{
		public function HandlerExample()
		{
			stage.addEventListener( MouseEvent.CLICK, run );
			stage.addEventListener( KeyboardEvent.KEY_DOWN, run );
		}
 
		private function run( $e:Event ):void
		{
			trace( $e )
		}
	}
}

stage 에 걸려 있는 두 가지 다른 종류의 이벤트 핸들러를 하나의 이벤트 핸들러로 처리하고 있습니다. 이것이 가능한 이유는 MouseEvent 나 KeyboardEvent 모두 Event 를 상속한 하위 클래스이기 때문 입니다. 역시 위의 경우도 이벤트 리스너에서 보낸 이벤트 객체를 이벤트 핸들러가 인자로 받으면서 암시적 업 캐스팅이 적용되었습니다.

5. interface

지금까지는 상속(inheritance) 체인상에서의 다형성을 알아봤는데요, 인터페이스 키워드(interface)로도 다형성을 구현할 수 있습니다. 인터페이스를 “구현상속”이라고 부르기도 하는데, 다형성 측면에서도 여러 모로 상속과 비슷해 보이기 때문이죠.

아래는 Monster 클래스에 붙일 IAttack 인터페이스 입니다.

0
1
2
3
4
5
6

package
{
	public interface IAttack
	{
		function attack( $target:Player ):void
	}
}

몬스터용 이기 때문에 $target 인자를 Player 형으로 받고 있습니다.
그러면 Monster 클래스는 어떻게 수정하면 될까요?

0
1
2
3
4
5
6

package
{
	public class Monster implements IAttack // IAttack 인터페이스를 구현
	{
		// Monster 클래스의 다른 부분은 기존 코드와 동일 ...
	}
}

네. 간단하죠. Monster 클래스에는 이미 attack() 메서드가 존재하므로 IAttack 인터페이스는 곧바로 구현된 것입니다. 바뀌는 코드는 고작 여기까지 입니다. 상황에 따라 개별 Goblin, Dragon, Troll 클래스에 각각 IAttack 인터페이스를 붙여도 마찬가지로 동작합니다.

그럼 호스트 코드에서는 어떻게 사용하게 될까요?

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import flash.display.Sprite;
 
	public class InterfaceTestDrive extends Sprite
	{
		public function InterfaceTestDrive()
		{
			var player:Player = new Player;
 
			var monsterList:Array = [ new Goblin, new Dragon, new Troll ];
 
			var mob:IAttack; // mob 을 IAttack 형으로 받고 있음
			for each( mob in monsterList )
			{
				trace( Monster( mob ).name, "이 플레이어를 공격 합니다." ); // Monster 클래스의 속성을 이용하고 싶다면 형 변환!!
				mob.attack( player );
			}
		}
	}
}

어떻습니까? 매우 편리하죠? 호스트코드에서는 배열에 들어있는 몬스터가 어떤 종류건 간에 관계 없이(알 필요 없이) IAttack 인터페이스를 구현하기만 했다면 순환문을 돌릴 수 있게 됩니다. 다형성을 이용해서 말이죠.

B. How to apply (적용 방법)

그런데 이런 방식으로 형 변환을 이용한 다형성의 이득을 챙기려면 몇 가지 규칙을 알고 있어야 합니다. 다르게 말하자면 아래에 나열할 규칙들은 객체지향 프로그래밍에서 상속을 구현할 때 알아야 되는 규칙들이기도 합니다.

1. 하위 형으로 생성하고 상위 형 변수로 받는다.

0

var instance:SuperClass = new SubClass();

위의 Monster 추상 클래스와 하위 개별 구상 클래스들과 같이 상속 구조가 잘 구성되어 있다면 모든 행동을 상위 클래스 형 만으로 할 수 있게 됩니다. 즉, 개별 구상 클래스는 추상클래스에서 구현하도록 한 public 메서드 외에는 자신만 가진 public 메서드는 없는 것이 좋겠죠. 이렇게 추상층과 구상층이 잘 구성되면 Monster 형의 변수만 가지고도 모든 몬스터들의 행동을 표현할 수 있게 됩니다.

2. 상속 체인상의 상하위 클래스간에만 형 변환 가능.

A 클래스를 상속한 B 클래스와 C 클래스가 있을 경우 A 형태와 B 형태는 캐스팅이 가능하고, A 형태와 C 형태는 캐스팅이 가능하지만, B 형태와 C 형태간 형 변환을 시도하면 플래시 플레이어가 에러를 뿜어줍니다.

객체지향 프로그래밍에서 부모자식은 있어도 형제 자매라는 개념은 존재하지 않습니다. 게다가 애초에 상속 체인을 부모자식 관계로 이해하는것 자체가 에러입니다.^[04]
같은 상위 클래스를 상속한 하위 클래스는 서로 관계가 없는 클래스이고 그 type 끼리는 형 변환이 실패하게 됩니다. 형 변환은 기본적으로 상속 체인상의 상하위 클래스간의 형 변환만이 가능하다는 것을 기억하세요.

3. up-casting 은 implicit casting (암시적 형 변환) 가능.

0
1
2

var object1:SuperClass; // 상위 형으로는 변수만 선언
var object2:SubClass = new SubClass(); // 하위 형으로는 객체까지 생성
object1 = object2; // 하위형의 객체를 상위형의 변수에 대입(암시적 형 변환)

상위 클래스는 서브클래스에 비해 메서드와 속성의 갯수가 같거나 적기 때문에, 다르게 표현하면 기능이 적은 클래스로 형 변환 하는 것이기 때문에 형 변환 검사를 느슨하게 해도 되고, 따라서 암시적 형 변환이 가능합니다. 변수가 상위 형이고 값이 하위 형인 경우에는 캐스팅을 하지 않아도 대입하는 과정에서 자동으로 형 변환이 일어 납니다.

4. down-casting 은 explicit casting (명시적 형 변환)만 가능.

0
1
2

var object:SuperClass = new SubClass(); // 상위형의 변수에 하위형의 객체 생성
object.superClassMethod(); // 상위형의 메서드 호출 가능
SubClass( object ).doSomething(); // 명시적 형 변환을 해야만 하위 형의 메서드 호출 가능

up-casting 과는 반대로 이 경우에는 메서드와 속성의 숫자가 같거나 적은 상위 클래스에서 많은 쪽인 하위 클래스로 형 변환 해야 하기 때문에 형 변환이 유효한지 아닌지 검사를 하는 과정이 필요합니다. 그래서 다운캐스팅은 암시적 형 변환을 할 수 없고 명시적 형 변환만이 허용됩니다.

5. 상위 형으로 생성하였다면 down-casting 불가.

0
1

var instance:SuperClass = new SuperClass();
var temp:SubClass = SubClass( instance ); // Error !!!

위와 같은 경우 입니다. 상위 형으로 생성하고 상위 형의 변수로 받았다면, 그 상위형을 상속한 하위 클래스라 할지라도 다운 캐스팅을 할 수 없습니다. 어찌보면 당연하죠? var mc:Sprite = new Sprite(); 한 후, Monster( mc ); 하는 것과 같으니까요. Sprite 객체를 아무리 캐스팅을 한들 Monster 객체가 될리 없습니다.

* * * * *

이렇게 다형성을 이용한 프로그래밍은 개발자에게 많은 이득을 가져다 줍니다. 코딩에 유연성을 부여하고 코딩을 담백하게 할 수 있도록 도와 줍니다. 게다가 상당항 분량의 코드를 줄일 수 있게 되면서, 코드가 명확해지고(가독성이 높아지고) 그로인해 유지보수가 수월해지게 되는거죠. 여러분도 이제 다형성을 이용한 코딩을 해 보세요. 형 변환 부터 시작하면 됩니다. ^^

1. http://help.adobe.com/ko_KR/Flash/CS5/AS3LR/flash/display/DisplayObject.html#parent
2. 즉, this.parent 는 DisplayObjectContainer 형 이므로 gotoAndStop() 메서드가 존재하지 않는다는 의미.
3. 암시적 업 캐스팅이 적용 된것입니다.
4. AS3.0 클래스의 상속(extends)구조에서 상위, 하위 클래스의 메서드 호출방법 의 가장 첫 문단 참고

우리나라 경영진들의 개발에 대한 몰이해, 또는 액션스크립트 프로젝트는 프레임웍 이라기 보다는 front-end (사용자단) 쪽의 결과물로 표현되는 경우가 대부분이므로 JAVA 등과 같이 강한 객체지향 개발의 필요성을 느끼지 못하기 때문이기도 하는 이런저런 구조적인 문제점들이 있으나, 정작 가장 결정적인 이유는 액션스크립트 개발자 자신들의 역량 부족에 기인한다고 볼 수 있을 것입니다.
즉, 액션스크립트 개발자들은 대부분 시각적인 것에 대단히 관심이 높은 (개발) 비전공자 출신인 경우가 많기 때문에, 화면만 어떻게 표현만 된다면 내부구조야 어찌되었든 별로 상관 없다는 식의 작업 방식을 취하는 경우가 많습니다. 이런 경우 프로젝트가 약간만 복잡해지거나 클라이언트의 유지보수 요구가 강하다면, 프로젝트 초반에 아무생각 없이 날코딩한 자신을 탓하고 있을 것이 틀림 없습니다.

여러분은 버그가 생길까봐 프로그램 수정을 두려워 하고 있진 않나요?

유지보수를 하고 수정을 하면 할 수록, 특히 자신이 초기 개발을 하지 않고 유지보수만을 담당하게 되었다면, 프로젝트의 전체 구조를 파악할 수 있는 시간도 주어지지 않고, 시간이 주어졌다고 해도 그런것에 쏟을 여력이 없는 우리 액션스크립트 개발자들은, 수정을 하면 할수록 버그가 생산된다는 것을 누구보다도 잘 알고 있습니다.

그래서 수정사항을 기피하거나, 수정의 분량이 조금만 많거나 새로운 기능이 들어가면 “이건 유지보수가 아니라 리뉴얼 해야됩니다. 그리고 (당연히) 비용이 많이 들어갑니다.” 라는 식으로 작업을 뒤로 미루거나 수정을 피할 수 없다면 재작업으로 유도하게 마련입니다. 이런 요구를 할 수 있는 상황이라면 그나마 나은 경우라고 할까요? 많은 경우 초기 개발이 어떻게 되었든간에 촉박한 기간내에 수정을 해 내야 합니다. 그러나 애초에 초기 개발부터 프로그램의 설계가 제대로 되었다면 간단히 수정이 가능한 일은 아니었을까요?

결국 이런 총제적인 난국이 작업 결과물의 부실을 낳고, 이런 부실이 액션스크립트 결과물들은 좋지 않다 라는 인식을 낳아, 또다시 그만그만한 front-end 작업물만을 담당하게 되는 악순환을 가져오게 됩니다.

그럼 여러분은 플래시로 언제까지 네비게이션 바나 만들고 있을껀가요?

객체지향 프로그래밍을 공부해야 하는 이유가 여기에 있습니다. 객체지향 프로그래밍은 프로그램의 퍼포먼스를 높이거나 개발시간 단축을 위한 프로그래밍 방법론이 아니라 유지보수를 잘 하기 위한 개발 방법론입니다. 객체지향 프로그래밍 방법론을 적용해가며 프로그래밍을 하다 보면 절차지향 프로그래밍에 비해 오히려 코딩 분량이 늘어나게 마련이고, (일반적으로) 퍼포먼스도 떨어지게 됩니다. 그러나 그 대신 우리는 유지보수의 편리성을 얻게 되는거죠.

자, 여러분이 코딩한 내용을 살펴보세요. 객체에 addEventListener() 달아놓은 이벤트 리스너와 핸들러 그리고 그에 속한 관련 처리 함수가 전체 코딩 분량의 절반을 넘는다면, 그것은 AS2.0의 타임라인 날코딩과 다를 바 없을겁니다. 이런 경우 AS3.0 으로 코딩하고는 있지만 객체지향적인 프로그래밍으로 인한 이득을 얻지 못하는 경우라고 할 수 있을 겁니다. 그래서 좀더 OOP적으로 프로그래밍 하기 위해, 그리고 조금더 이 (개발)언어를 마치 모국어를 말하듯 구사하기 위해, 이런 주제를 잡았습니다.

그리고 이 포스팅들은 제가 참여하고 있는 스터디, 또는 세미나에서 발표한 내용을 청중들에게 미리 자료로 제공하기 위해 초고(草稿) 형태로 작성한 내용이기도 합니다. 발표가 끝난 후 조금 더 정리하거나 내용을 추가해서이 블로그에 포스팅 되므로, 포스팅 되는 시점은 실제 글이 쓰여진 시점보다는 약간 나중이 될 가능성이 높습니다.

또한, 애당초 발표를 목적으로 글이 쓰여지기 때문에 실제 학습순서와는 다르게 포스팅 될 수 있습니다. 예컨대 “상속”을 이해 한 후 “다형성” 을 읽어보면 좀 더 이해가 잘 되겠지만, 실제 순서는 “다형성” 이 먼저 포스팅 될 수 있다는 것이죠. 이런 경우 나중에 포스팅 된 “상속” 을 읽으신 후, 예전에 포스팅 되었던 “다형성”을 한 번더 읽어 보실 필요도 있을 것입니다.

어쨌건, 현재까지 작성되었거나 계획중인 포스팅은 아래와 같습니다. (rss 로 이 글을 보시는 분들은 아래의 포스트 목록이 주기적으로 추가되거나 바뀐다는 것을 기억하세요.)

OOP in ActionScript (액션스크립트에서의 OOP)

1. 예제를 통해 쉽게 풀어보는 OOP의 다형성 (Polymorphism)
2. 액션스크립트로 하는 객체 재사용(재활용)과 오브젝트 풀(Object Pool) – 개요
3. 플래시 플레이어의 가비지 컬렉션(gabage collection)에 대한 이해
4. 액션스크립트의 객체 재사용을 위한 오브젝트 풀(Object Pool)

그리고 OOP에 대한 시리즈 포스트는 고수들은 가르쳐주지 않는 AS3.0 입문 카테고리에도 포함될 예정이므로, 초보 개발자들도 이해하기 쉬운 내용과 고수들은 잘 가르쳐 줄것 같지 않은 특별한 요점정리로 포스트가 쓰여질 내용입니다. 따라서 OOP 에 이미 익숙한 개발자 분들은 딱히 이 시리즈를 읽지 않으셔도 됩니다.

그럼 먼저 OOP의 기본 요소들과 개념들은 무엇인지 나열해 보도록 합시다.

• Classes : 클래스
• Instance :인스턴스
• Method : 메서드
• Message passing : 메시지 패싱 (전달)
• Decoupling : 디커플링
• Abstraction : 추상화
• Inheritance : 상속
• Encapsulation : 은닉(캡슐화)
• Polymorphism : 다형성

이중에서도 OOP의 3대 속성이라고 한다면

1. 상속
2. 은닉(캡슐화)
3. 다형성

을 꼽을 수 있고, 이 목록은 OOP를 주제로 쓰여질 포스트들의 주제 목록에 다름 아닙니다. 모든 주제를 다루진 않겠지만 대체로 위의 목록이 가리키는 범주를 벗어나지 않는 개념 향상 위주의 포스팅이 예정되어 있습니다.

순환문만 있다면 수백만번의 반복 노가다도 문제 없다.

부제: AS2.0의 인스턴스 네이밍 습관을 AS3.0에서 바꿔보자.

액션스크립트로 처음 개발언어에 입문한 사람들에게 순환문은 마법과도 같은 생산성을 의미합니다. 스테이지와 타임라인에 드로잉 툴로 이것저것 그려내고 모션 트윈이나 쉐이프 트윈 노가다를 하던때가 매우 미개하게 느껴질 만큼 그 위력은 대단하게 느껴지죠.

액션스크립트에서 사용할 수 있는 순환문에는 while, do .. while, for, for .. in, for each .. in 의 다섯가지 입니다.^[01] 앞의 세 가지 순환문은 각기 형태가 다르게 보이지만 조건이 true 일 동안 계속 실행된다는 원리나 동작 방식이 동일하고, 뒤의 두 가지 순환문은 객체의 모든 변수(또는 객체가 가진 자식 객체)에 개별적으로 접근할 수 있는 특징을 가지고 있습니다.

다섯 가지의 순환문이 있음에도 불구하고 뭔가 코드에 관여하여 컨트롤 할 수 있는 부분이 많아 보여서 일까요? 대부분의 초보 개발자들은 for 순환문만 주구장창 사용합니다. 그것도 조건을 조회하는데 i++ 와 같이 정수 i 값을 증가하거나 감소하는 방식만 사용하죠.

그러면 이런 for 문은 어떤가요?

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var list:Array = [ "a", "b", "c" ];
var i:int;
for( init(); hasNext(); ) // 조건절의 모양새에 유의
{
	trace( getItem( i ) );
}
 
function init():void
{
	i = 0;
	// some initialize
}
 
function hasNext():Boolean
{
	if ( list.length > i )
		return true;
	else
		return false;
}
 
function getItem( $index:int ):*
{
	i++;
	return list[ $index ];
}

위의 코드는 유효한 코드 입니다. 반드시 for( i = 0; i < n; ++i ) 의 형태일 필요가 없다는 것이죠. for 문 괄호안의 세미콜론으로 구분되는 세 부분은 왼쪽부터 초기화, 조건절, 루프 후 실행이라는 각각의 역할을 가지고 있습니다. 그런데 for 문은 실제로 가운데의 조건절 부분만 만족하면 앞뒤 부분은 생략되도 문법적으로 에러가 아닙니다. 즉, for( ; hasNext(); ) 이런 for 문 역시 유효합니다.

그러나 이렇게 사용할 바에야 while 문을 사용하는게 퍼포먼스 면에서라도 조금이나마 나을겁니다. 즉, for 문이 while 문에 비해 추가된 기능은 바로 조건절 앞 뒤에 존재하는 부분입니다. for 문은 초기화와 루프 후 실행을 한 줄에 지정할 수 있다는 잇점을 가지고 있습니다. 반대로 초기화할 필요가 없고 루프 후 실행할 것이 없으면 while 문을 사용하는것을 고려해 볼 필요가 있습니다.

* * * * *

A. 문제점 제시

자 그럼 슬슬 순환문 사용에 있어서의 문제점을 살펴볼까요?
초보 개발자들은 for( i = 0; i < n; ++i ) 형태의 순환문만을 사용하려는 습관을 가지고 있는데, 이 습관 때문에 AS2.0에서는 객체들에게 거의 예외없이 "문자열"+숫자 형태의 일련번호를 가진 인스턴스네임이 늘상 사용되어 왔습니다. 이것은 다분히 플래시가 디자이너들에 의해 네비게이션 바를 만드는 툴로 인식되면서부터 습관이 되버린 사용 방법이면서, 동시에 fla 파일을 판매하는 몇몇 사이트에서 네비게이션 바를 만들때 어김없이 사용한 방식이기도 했습니다. 심지어 Flash 8 까지는 숫자만으로 이루어진 인스턴스네임조차도 허용되었기 때문에,^[02] 네비게이션 항목 객체의 인스턴스네임이 죄다 숫자로 이루어진 엽기적인 fla 파일들도 한동안 돌아다니곤 했습니다.

그런 네비게이션 바를 만들어낸 사이트들을 탓할 생각은 없습니다. AS2.0 이하의 구조에서는 아주 간단하고 효율적으로 객체를 참조할 수 있는 방법중 하나였으니까 말이죠. 문제는 이런 방법에 익숙해진 디자이너들이 이 방법 이외에는 생각을 하지 않는다는 것입니다.

그럼 그렇게 된 원인을 오랜만에 AS2.0 코드를 보면서 짚어볼까요?

0
1
2
3
4
5
6
7
8
9
10

// fla 의 상황. 라이브러리에 Linkage 이름을 mc 으로 부여한 무비클립이 있음
var temp:MovieClip;
var len:Number = 10;
for( i = 0; i < len; ++i )
{
	temp = this.attachMovie( "mc", "mc" + i, this.getNextHighestDepth() );
	temp._x = ( temp._width + 5 ) * i;
	// 그 밖의 초기화 코드
 
	trace( temp._name );
}

이렇게 하면 화면에 mc0 부터 for 문이 돌아간 마지막 i 값까지의 객체가 다다닥 생겼을겁니다.

컴파일 결과 화면 상황

이 순환문이 한번 돌아간 이후로는 this 의 어디에서나 mc0, mc1, mc2 … mc9 를 참조할 수 있습니다. 그것인 즉, 인스턴스 객체가 만들어지면서 같은 이름의 인스턴스네임도 부여되었다는 것을 의미 합니다.

이 상황에서 아래와 같은 코드를 실행해보도록 합니다.

0
1
2

this.mc2._name = "ufx"; // 이렇게 mc2 의 _name 속성을 변경하면
trace( this.mc2 ); // 출력 : undefined
trace( this.ufx ); // 출력 : _level0.ufx

이 코드를 보고 무엇을 알 수 있나요? AS2.0 에서 객체의 인스턴스네임과 _name 속성은 같은것을 지칭한다라는 것을 말해주고 있습니다.

* * * * *

B. 그러나 AS3.0에 와서는 사정이 달라졌습니다.

AS3.0에서는 fla 의 편집 화면상에 존재하는 무비클립에 인스턴스네임을 부여하면, 런타임에 name 속성을 변경할수가 없습니다. name 속성 변경을 시도하면 아래와 같은 에러 메세지를 만날 수 있습니다.

Error: Error #2078: 타임라인에 위치한 객체의 이름 속성은 수정할 수 없습니다.
at flash.display::DisplayObject/set name()
at AS3Test_fla::MainTimeline/frame1()

게다가 코드상에서 new 키워드를 사용하여 라이브러리의 클래스 정의를 사용하여 객체를 생성하는 경우, 인스턴스네임을 임의로 부여할 수가 없습니다.

0
1
2
3
4
5
6
7
8
9
10

var temp:TagImage;
var i:uint;
var len:uint = 10;
for ( i = 0; i < len; ++i )
{
	temp = new TagImage();
	temp.x = temp.width * i;
	addChild( temp );
 
	trace( temp.name );
}

위에서 보는것과 같이 name 속성은 별도로 코딩해서 속성부여하지 않는다면 swf 파일을 컴파일 하는 시점에서 아래와 같이 컴파일러가 자동으로 name 값을 부여하게 됩니다.

trace( temp.name ) 출력 결과

instance1
instance3
instance5
instance7
instance9
instance11
instance13
instance15
instance17
instance19

그렇다면 인스턴스네임은? 알 수 없습니다. 알 수도 없고 지정하거나 수정할 수도 없습니다. 즉, 인스턴스네임을 부여할 수 있는 경우는 fla 의 스테이지 화면에 존재하는 무비클립을 선택한 상태에서 속성 패널을 이용하는 경우로 제한되어 있는 것이죠.

AS3.0과 AS2.0이 가장 확연한 차이를 보이는 것 중 하나가 바로 이 부분 입니다. AS2.0 으로 플래시를 접했던 많은 사람들은 이 부분을 가장 혼동하게 되고, 이렇다는 것을 나중에 알게된 후에는 “정말 불편하게 변경되었잖아” 라고 생각합니다. 모든 무비클립을 인스턴스네임으로 핸들링해 왔는데 갑자기 그것이 제한되니까 그렇게 생각하는것도 당연합니다. 당장 this[ "mc" + i ] 스타일로 인스턴스네임을 줄 수가 없으므로, 뭘 하고 싶어도 할 수 없는 그런 상황이 된 것이죠.

그러나 실제로 인스턴스네임에는 다음과 같은 두 가지 문제가 있습니다.

• 서로다른 객체에게 같은 인스턴스네임을 부여할 수 있습니다. (인스턴스네임이 중복되었는데 에러를 내지 않습니다.)
• 중복된 인스턴스네임을 핸들링하면 먼저생성된 객체만 핸들링됩니다.

이런 부정확성은 객체를 핸들링 하는데 신뢰도를 떨어뜨리게 되어 원하지 않는 결과를 가지고 올 수 있게 됩니다. 그리고 이런 에러는 디버깅 하기도 힘들겠군요.

그래서 AS3.0에서는 인스턴스네임 대신 객체를 핸들링 하는 다른 방법들을 사용하게 됩니다. 그 방법들을 알아보기 전에 다시 한번 생각해보고 넘어가야할 것이 있습니다.

* * * * *

C. 정말 넘버링(Numbering)을 해야만 하는가?

AS2.0시절 인스턴스네이밍을 할때 “mc” + i 스타일로 하는것에 대해서 인데요, 대체 무엇때문에 넘버링을 하는 걸까요?

넘버링을 하는 이유는 두 가지로 볼 수 있습니다. 인스턴스네임이 중복되지 않게 유니크한 값을 가지기 위함이 첫번째 이유이고, 인스턴스네임을 substr() 메서드 등으로 문자열 조작을 하여 숫자부분 만을 획득한 후 그것을 index 로 다른 행동이나 값들을 호출하기 위함이 두 번째 이유 입니다.

그러나 다른 객체와 구분하기 위함이라면 “menu1″ 보다는 “AboutCompany” 가 훨씬 알아보기 쉽잖아요. trace() 찍어볼때는 말할것도 없습니다.
또한 넘버링을 한다는 것은 숫자가 인덱스의 의미를 가져 객체간 구분을 하는 기준을 삼는다는 것을 의미합니다. 그런데 정말 숫자가 의미를 가지고 있습니까? “mc” + i 스타일 네이밍에서 i 값은 단지 객체간 구분을 하고 어떤것을 먼저 생성했는지 순서를 말해줄 뿐, 숫자가 가지는 실제적인 의미가 없습니다.

그러므로 인스턴스네임을 넘버링 하는것에 더 이상 미련을 두지 마세요. 우리는 그 객체의 이름조차 알 필요 없는 더 좋은 방법을 사용하게 될 테니까요.

* * * * *

D. 상황별 해결 방법.

자, 그럼 다음의 세 가지 방식의 솔루션을 제시합니다. 경우에 따라서 특정한 상황에는 반드시 특정한 방법을 사용해야만 할 수 있습니다만, 대체로 여러분의 입맛에 맞는 방법을 사용하면 됩니다.

D-1. AS2.0 방식으로 사용하기를 원한다. (name 속성을 인스턴스네임 대신 사용)

0
1
2
3
4
5
6
7

var item:MenuItem;
var i:int, len:int = 5;
for( i = 0; i < len; ++i )
{
	item = new MenuItem();
	item.name = "item" + i; // 이렇게 name 속성에 넘버링
	addChild( item );
}

위와같이 객체들을 생성했으면,

0
1
2
3
4

var item:MenuItem = getChildByName( "item1" ) as MenuItem;
item.doSomething();
 
// 물론 DisplayObject 수준의 속성을 제어하는 거라면 간단하게 아래와 같이 해도 됩니다.
getChildByName( "menu1" ).y = 10;

위와 같이 DisplayObjectContainer 클래스의 getChildByName() 메서드를 이용해 name 속성으로 객체를 잡아낼 수 있습니다.

D-2. 배열(Array)에 넣어라

그러나 name 속성은 인스턴스네임과 마찬가지로 서로 다른 객체가 동일한 name 을 가지는것이 허용됩니다. 객체를 생성할때야 “이런게 헷갈릴리가 없어” 라고 생각하지만, 우리… 평생 네비게이션만 만들거 아니잖아요. 엔터프라이즈급의 복잡한 시스템을 가진 플래시 애플리케이션이라면 name 속성이 중복되는 일이 보기 드문 일도 아닙니다.

그래서 보통 이런경우 플래시 개발자들은 가장 손쉬운 방법으로 배열을 사용합니다. 우리가 제어하고 싶어하는 일련의 비슷한 객체들은 배열에 넣어서 관리하는 것이 가장 손이 덜 가고 편리한 방법 입니다.

0
1
2
3
4
5
6
7
8

var itemList:Array = [];
var item:MenuItem;
var i:int, len:int = 5;
for( i = 0; i < len; ++i )
{
	item = new MenuItem();
	itemList.push( item ); // 배열에 push()
	addChild( item );
}

위와같이 객체 생성 시점에 배열에 넣어두고

0
1
2
3
4

var item:MenuItem = itemList[ 1 ];
item.doSomething();
 
//배열 원소는 실제 객체를 참조하고 있기 때문에 별도의 캐스팅 없이 간단하게 아래와 같이 사용할 수도 있습니다. 단, 개발환경에 따라 코드힌트를 받지 못할수도 있습니다.
itemList[ 1 ].y = 10;

위와같이 배열 연산자로 각 객체를 참조할 수 있습니다.

D-3. Object에 넣는것은 좀더 세련된 방법

Object 클래스는 모든 클래스의 원형 클래스이기 때문에 이런저런 제한이 가장 덜 걸려 있는 클래스 입니다. 제한이 별로 없는 반면 할 수 있는 일역시 별로 없기도 하죠. 시각적인 면만을 본다면 Object 객체는 실제로 스테이지에 보이게 할 수 있는 것도 아니고 추상적인 특성을 가지고 있기 때문에 그리 쓸모가 없어 보이기도 합니다만, 반대로 이러한 유연한 특성 때문에 데이터를 저장하고 읽어내는데 편리한 클래스 입니다.

0
1
2
3
4
5
6
7
8
9

var itemList:Object = new Object();
var item:MenuItem;
var i:int, len:int = 5;
for( i = 0; i < len; ++i )
{
	item = new MenuItem();
	item.x = item.width * i;
	addChild( item );
	itemList[ "id" + i ] = item;
}

이렇게 생성한 후에는,

0
1

trace( itemList.id1 ); // 출력 : [object MenuItem]
itemList.id1.y = 100; // 이렇게 속성에도 자유롭게 접근됩니다.

다른 방법들보다 훨씬 직관적인데다가 간편하게 사용할수 있습니다.
이런 기능은 정확하게는 Object 클래스가 dynamic 으로 정의되어 있기 때문에 가능한 것인데, 반드시 Object 클래스가 아니더라도 dynamic 으로 정의되어 있는 MovieClip 과 같은 클래스도 동일하게 사용할 수 있습니다. 다만, 변수와 값을 보관하는데 MovieClip 씩이나 사용할 필요가 없겠죠. 게다가 이런 용도로 이미 많은 개발자들이 Object 를 사용하고 있기 때문에 코드 가독성을 고려해 봤을때 플래시 네이티브 클래스 중에서는 Object 클래스가 가장 좋은 선택이라고 할 수 있습니다.

* * * * *

E. for each .. in 을 이용한 순환문의 활용

지금까지 객체들을 생성하고 특정한 방식에 의해 세팅하는것을 살펴봤습니다. 이렇게 세팅하는것을 설명한 이유는, 활용을 할때 제대로 활용하기 위함이죠.
위에서 제시한 방법 중 getChildByName() 을 제외한 나머지 두 가지 방법은 객체들을 목록(컬렉션)으로 받게 됩니다. 이런 경우 for each .. in 순환문을 사용하게 되면 훨씬 신뢰성이 좋은 순환문을 만들 수 있습니다.
아래 코드는 for each .. in 순환문의 특성을 명확하게 표현하기 위해, 파싱된 xml 객체를 이용했습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

var xml:XML =
<data>
	<menu>
		<name>첫번째 메뉴</name>
		<url>path/myurl_1.html</url>
		<target>_self</target>
	</menu>
	<menu>
		<name>두번째 메뉴</name>
		<url>path/myurl_2.html</url>
		<target>_self</target>
	</menu>
	<menu>
		<name>세번째 메뉴</name>
		<url>path/myurl_3.html</url>
		<target>_blank</target>
	</menu>
</data>;
 
var itemList:Array = [];
var item:MenuItem, node:XML, i:int;
for each( node in xml.menu )
{
	item = new MenuItem();
	//item.updateXml( node ); // 이런식으로 XML 을 객체로 넘겨 내부에서 url 등을 처리하도록 함
	i = node.childIndex(); // index 값이 필요하면 xml 의 childIndex() 를 사용
	item.x = item.width * i;
	item.txtName.text = item.name = node.name;
	addChild( item );
 
	itemList[ i ] = item;
 
	trace( item.name );
}

이런 예제는 실무에 사용되는 코드와 거의 비슷하다고 할 수 있겠죠. xml 을 이용해 for each .. in 순환문을 사용하는 경우 xml 의 노드 순서대로 순환문이 돌기 때문에 순서대로 배열에 들어가게 됩니다.
배열에 예쁘게 들어가있기 때문에 사용하는것도 매우 편리합니다.

0
1
2
3
4
5

var item:MenuItem;
for each( item in itemList )
{
	trace( item.name );
	item.doSomething();
}

실제로 for each .. in 순환문은 for( i = 0; i < len; ++i ) 스타일의 for 순환문에 비해서 훨씬 직관적으로 사용할 수 있고, 순환 조건 평가가 undefined, NaN 또는 null 이 대입되서 무한루프에 빠지는 경우가 발생하지 않아 에러 발생이 획기적으로 줄어듭니다. 정확히 필요한 만큼만 순환하고 알아서 루프를 끝내기 때문이죠. 또한 속도 테스트를 해봐도 for 순환문보다 약간 빠릅니다.

그런데 한 가지 주의할 점이 있습니다. 배열의 경우 index 0번부터 순서대로 for each .. in 이 돌지만, 저 위의 경우와 같이 Object 에 변수로 저장한 경우에는 순서를 보장해주지는 않습니다. Object 를 컬렉션으로 사용하는 경우에는 실행 순서가 관계없는 순환문에 한정해서 사용해야 합니다.

* * * * *

F. 그런데 코딩하다보면 index 가 필요하던데?

먼저 객체간의 index 가 정말 필요한가 다시 생각해볼 필요가 있습니다. for each .. in 순환문은 컬렉션의 모든 변수(또는 원소)를 순환하기 때문에 index 가 필요하지 않습니다. 만약 여러분이 순환문만을 루프 시키기 위한, i++ 를 생각하고 있다면 더이상 i 를 사용할 필요가 없습니다.

그런데 객체간의 index 값이 필요할 때가 있긴 있습니다. 가장 손쉽게 떠오르는 경우는 객체의 width 속성을 i 로 곱해서 일렬로 주욱 나열하고 싶을 때가 해당하겠죠. 그런 경우에는 컬렉션의 여러가지 index를 활용할 수 있습니다.

F-1. 별도의 변수 index++ 를 사용.

보통의 for 문을 순환시키는 것과 동일한 테크닉입니다.

0
1
2
3
4
5
6
7

var item:MenuItem;
var i:int = 0;
for each( item in itemList )
{
	item = new MenuItem();
	item.x = item.width * i;
	i++;
}

F-2. XML 노드는 childIndex()

XML 노드를 순환할 경우에는 저 위쪽에서 이미 본 것과 같이 childIndex() 메서드를 사용하는 방법도 있습니다.

0
1
2
3
4
5
6
7

var item:MenuItem;
var node:XML, i:int;
for each( node in xml.menu ) // XML 을 순환하고 있음에 유의
{
	item = new MenuItem();
	i = node.childIndex();
	item.x = item.width * i;
}

F-3. Array 는 indexOf()

배열의 경우라면 indexOf() 메서드가 있겠죠.

0
1
2
3
4
5
6
7
8

var itemList:Array = [];
// 배열에 객체 생성하고 넣는 과정 코드는 생략
 
var item:MenuItem;
for each( item in itemList ) // 배열을 순환하고 있음에 유의
{
	i = itemList.indexOf( item );
	item.x = item.width * i;
}

F-4. Object는 변수에 넘버링.

Object는 위에서 이미 설명한대로, 순서가 보장되지 않으므로, 변수명에 넘버링을 하는 방법을 택하는것이 좋습니다.

0
1
2
3
4
5
6
7
8
9
10
11

var itemList:Object = new Object();
// 객체 생성하고 Object에 넣는 과정 코드는 생략
// Object 내부에 생성된 변수명은 item0, item1, ... 
 
var item:MenuItem;
var i:int;
var len:int = 10; // 객체를 생성한 갯수를 저장 (예시)
for( i = 0; i < len; ++i ) // for each..in 순환문은 Object 내부의 변수를 순차적으로 순환하지 못하므로 index를 이용해 순환하고 있음에 유의
{
	item = itemList[ "item" + i ];
	item.x = item.width * i;
}

F-5. DisplayObjectContainer는 getChildIndex()

DisplayObjectContainer 의 getChildIndex() 메서드를 이용해서 Sprite 객체에 addChild() 된 자식들의 index 를 이용하는 방법도 생각해 볼 수 있는 방법 중 하나 입니다.

0
1
2
3
4
5
6
7
8
9

// xml 객체는 생략
var container:Sprite = new Sprite();
var item:MenuItem, node:XML, i:int;
for each( node in xml.menu ) // XML 을 순환하고 있음에 유의
{
	item = new MenuItem();
	container.addChild( item );
	i = container.getChildIndex( item );
	item.x = item.width * i;
}

* * * * *

여기까지 인스턴스네임과 순환문과의 관계 부터, AS3.0 개발 과정에서 만나게 될 수 있는 여러가지 상황에 따른 보다 적절한 순환문의 사용까지 두루두루 살펴봤습니다. 실제 여러분들의 코딩 수준은 천차만별일지라도, 저는 글을 쓸때 여러분을 어느정도 일정한 범위로 특정한 후에 쓰고 있습니다. 그렇지 않으면 이도저도 아닌 이해하기 힘든 글이 되기 쉽상이니까요. 그러나 역시 제 블로그의 대부분의 글은 초보 개발자들에 포커스가 맞춰져 있죠. 게다가 이 글은 좀더 초보 개발자의 시각에서 바라보고 글을 썼습니다. 글의 소재가 그러하였으니까요. ^^

그러나 이렇게 끝내면 이 글이 쉽게 느껴지는 개발자 분들은 섭섭해 하실것 같아, 바로 이어서 속편이 이어지겠습니다.

1. for each .. in 순환문은 AS3.0에서 추가되었으므로 AS2.0에서는 사용하지 못합니다.
2. 물론, 현재는 숫자만으로 이루어지거나 숫자로 시작하는 인스턴스네임은 허용되지 않습니다.

그래서 결국 플래시로 프레임웍, 즉, UI는 여러분이 제작하게 되었고, (이 러닝 업계에서는 프로토타입을 만든다는 표현을 하죠) 차시별 작업은 경험이 많다고 하는 외주 팀에게 하청을 주기로 하였습니다. 여러분은 이제 제법 클래스를 이용해 프로젝트를 수행할 수 있게 되었고, AS2.0 으로 프로젝트를 만들지 않으므로 AS3.0 으로 이 러닝 프로젝트를 수행하려고 합니다. 흔하디 흔한 이 러닝 프로젝트지만 여러분은 좀 다르게 만들고 싶어하죠.

그런데 여기서 문제가 발생합니다.

차시개발을 하는 팀이 AS3.0을 모른다네요. 그렇죠. AS3.0을 다룰 수 있는 차시개발자들을 만나는 일은 두 발로 서는 고양이를 만나는 일과 비슷한 확률일 겁니다. 그렇다면 차시개발은 AS2.0 으로 작업하고, 프로토타입과 UI 는 AS3.0 으로 갑니다. 인트로 무비 같은것을 차시개발자들이 해주는 경우는 별로 없으므로 인트로 무비도 여러분이 AS3.0 으로 제작합니다.

결국 AS2.0과 3.0 파일을 동시에 보여줘야 하는 상황이 되었습니다. 여기까지도 문제는 없죠. AS3.0 에서 Loader 객체를 이용하면 AS2.0 으로 컴파일된 swf 파일도 로드가 가능하다는 것을 잘 알고 있으니까요.^[01]

그러나 정말 어려운 문제는 실제 코딩을 하다가 드러나게 됩니다. 애니메이션의 재생, 정지 등을 구현하기 유튜브의 비디오 플레이어와 비슷한 형태의 swf 플레이어를 만들어야 하고, 탐색(seeking) 기능을 넣기 위해서 전체 타임라인의 프레임 갯수를 알아야할 필요가 생겼습니다.

이런 형태의 seeking controller 말이죠!!

여러분이 만들기로 했던 인트로 swf 파일은, UI를 담당하는 swf 파일과 동일한 AS3.0 으로 컴파일되어있기 때문에 아래와 같이 로드 완료 이벤트를 받은 후 이벤트 target.content 를 MovieClip 으로 캐스팅 해서 간단히 사용할 수가 있습니다.

0
1
2
3
4
5
6
7

var objLoader:MovieClip;
loader.contentLoaderInfo.addEventListener( Event.INIT, initHandler );
function initHandler( $e:Event ):void
{
	objLoader = $e.target.content as MovieClip;
	// 이 시점 이후로 objLoader 객체는 무비클립과 동일하게 사용할 수 있음
	trace( objLoader.totalFrames, objLoader.stage.frameRate ); // 이렇게 totalFrames, frameRate 등의 속성을 직접 참조가능
}

그러나 차시개발 외주팀에서 보내준 AS2.0 버전의 swf 파일은 이게 안됩니다. 애초에 AS2.0 에서는 속성명 부터가 다르죠.^[02]

그래서 어쩔 수 없이 차시개발팀에게 약간의 코드를 넘겨주고 그쪽에서 만드는 모든 AS2.0 파일의 1프레임에 넣도록 요청했습니다. 로드 완료 후 첫 프레임에 진입할때 LocalConnection을 이용해 프레임웍(AS3.0 으로 만들어진 로더)에게 _totalframes 따위의 정보를 넘겨주는거죠. LocalConnection 은 생각보다 성능이 괜찮았습니다. 채널명 중복만 주의하면 거의 에러 없이 정확히 동작합니다. 그렇다면 로드 완료 이벤트 후에 AS2.0 과 AS3.0 의 경우를 분기해서 각각 처리하면 될 것 같습니다.

그런데 산넘어 산이네요. 로드한 파일이 AS2.0인지 AS3.0인지 대체 어떻게 알죠?

* * * * *

상황이 상당히 구체적으로 들어갔지만, 플래시 개발자들이라면 한번쯤 만나게 되는 상황 입니다. 제 경험담이냐고요? 가장 윗 부분에서 영업팀 때문에 프로젝트를 떠안은건 아니었지만, 코딩 상황은 제 경험담 그대로 입니다. 이 이야기, 꽤 오래전부터 “반드시 포스팅 해야지” 하고 마음먹고 있었습니다. ^^

Loader 객체로 가져온 swf 파일의 액션스크립트의 버전을 확인하려면, 아래와 같이 할 수 있습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// import 는 생략
 
var _url:String = "file.swf"; // 로드당하는 swf 파일
var _loader:Loader = new Loader();
_loader.contentLoaderInfo.addEventListener( Event.INIT, initHandler );
_loader.load( new URLRequest( _url ) );
 
function initHandler( $e:Event ):void
{
	if( isAVM1Movie( $e.target.content ) )
	{
		// AS2.0 으로 처리
	}
	else
	{
		// AS3.0 으로 처리
	}
}
 
//로드된 파일이 ActionScript 2.0 인지 확인
function isAVM1Movie( $swf:Object ):Boolean
{
	return ( $swf is AVM1Movie ) ? true : false;
}

이런식으로 간단하게 is 연산자를 사용하여 로드한 swf 의 액션스크립트 버전을 확인할 수 있습니다.

그리고 아래와 같이 flash.utils 패키지에 있는 getQualifiedClassName() 메서드로 정규화된 클래스 이름을 반환 받아 == 항등 연산자로 비교해 볼 수도 있습니다.

0
1
2
3
4

 // 이 코드도 마찬가지로 동작합니다. 어느쪽을 사용해도 무방.
function isAVM1Movie( $swf:Object ):Boolean
{
	return ( getQualifiedClassName( $swf ) == "flash.display::AVM1Movie" ) ? true : false;
}

1. 그와는 반대로 AS2.0 에서는 AS3.0 으로 컴파일된 swf 파일을 loadMovie() 하지 못한다는것은 다 알고 계실겁니다.
2. AS2.0 의 속성명에 대부분 붙어있던 _ 언더바(언더스코어)가 AS3.0 에서는 모두 없어졌잖아요. 게다가 AS2.0 의 _totlaframes와 AS3.0의 totalFrames는 가운데 F의 대소문자가 다릅니다. 이런식으로 미묘하게 조금씩 다르죠.

정확히 1년전에도 같은 내용을 다룬 포스트를 썼습니다. 작년에 비해 올해는 지역 구분에 호주와 뉴질랜드가 추가되어 2010년 6월 현재 Mature Markets^[01] 의 Flash Player 10의 설치율은 97.5% 이고(2009년 86.7%) 우리나라가 포함되어 있는 Emerging Markets^[02] 은 96.1%(2009년 81.8%) 의 설치율을 보이고 있습니다.

작년과는 다르게 Flash Player 9 버전과 10 버전의 차이가 2% 안팎이고 10 버전이 모든 지역에서 96% 이상의 설치율을 보이고 있으므로 거의 모든 pc 에 설치되었다고 봐도 무방하겠습니다. 이제는 Flash Player 10 의 API 를 사용한 플래시 컨텐를 제작해서 퍼블리싱 해도 무리가 없을것으로 보입니다.

네이버는 아직까지도 9 버전 embed 코드를 사용하고 있는데, 마켓 리더로서 어서 빨리 10 버전의 embed 코드를 사용했으면 합니다. (사실 지금도 굉장히 늦은편이지만 말이죠.)

1. 주류시장 : 미국, 캐나다, 영국, 독일, 프랑스, 일본, 호주, 뉴질랜드
2. 신흥시장 : 우리나라, 중국, 러시아, 인도, 대만

이 라이브러리는 단순히 swf, image, video 등을 로드하자는게 아니라 xml, css, mp3, txt 나 binary 데이터 까지 플래시에서 로드 가능한 거의 모든 종류의 외부 자원들을 로드할 수 있습니다.
사실 이것 뿐이라면 “그정도의 통합 로더는 나도 만들어 사용하고 있다” 고 하실 분들이 있을텐데요. 제작자인 GreenSock 은 이전에 발표한 TweenMax 에서 보여주듯이 개발자에게 상당히 매력적인 편의 기능을 동시에 제공하고 있습니다.

로드된 swf 에서 다시 한단계 건너 로드되는(2단계 이상의 로더구조) 외부 자원에 대한 관리를 하거나, 다수의 외부 자원을 동시에 로드할 수 있는 소위 벌크로더 구현, 그 벌크로더의 로딩 순서를 제어할 수 있는 기능도 제공합니다. 그중에서도 가장 주목할만한 것은 LoaderMax 와 관련 있는 미리 약속된 XML 노드이름을 자동으로 파싱해서 로더 객체를 만들어 내고 속성까지 설정할 수 있는 XML 자동 파싱 기능입니다.

아래 설명을 읽어내려가면, 전반적으로 개발자의 번거로운 코딩 작업들을 알아서 처리해 주는 정말 편리한 라이브러리라는것을 알 수 있습니다. 귀차니스트인 저에게는 딱이군요.

이 예제는 GreenSock 이 만든 데모 예제 입니다. LoaderMax 가 어떻게 동작하는지 확인해보세요. 썸네일이 뜨기 전의 전체 로딩 작업 부터 LoaderMax 의 영역입니다.

아래는 http://www.greensock.com/loadermax/ 의 요약 번역 입니다. 저는 전문 번역자가 아니므로 일부 번역에 에러가 있을 수 있습니다. 이상한 점이 있으면 원문을 확인하세요.

LoaderMax – Smart AS3 Loading

버전 : 1.01, 2010-06-16 업데이트
호환성 : AS3.0 (Flash Player 9 이상)

로더와 로더 내부의 서브로드 swf 파일의 통합

로드 당하는 swf 에서 다시 로드하는 자원의 로딩 관리를 조상님이 모두 해주신다는 이야기. doc 에 있는 코드로 보면 확 와닿으실 겁니다. 아래에 있는 모든 예제 코드는 doc 에 있는 코드를 기본으로 해서 현재 설명하고 있는 context 에 집중할 수 있도록 일부 편집했습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// LoaderMax 객체를 "mainQueue" 이름으로 생성하고 onProgress, onComplete 와 onError 리스너를 한꺼번에 설정
var queue:LoaderMax = new LoaderMax({name:"mainQueue", onProgress:progressHandler, onComplete:completeHandler, onError:errorHandler});
 
// 몇 개의 로더 객체를 LoaderMax 에 붙임(append)
queue.append( new XMLLoader("xml/data.xml", {name:"xmlDoc"}) );
queue.append( new ImageLoader("img/photo1.jpg", {name:"photo1", estimatedBytes:2400, container:this, alpha:0, width:250, height:150, scaleMode:"proportionalInside"}) );
queue.append( new SWFLoader("swf/main.swf", {name:"mainClip", estimatedBytes:3000, container:this, x:250, autoPlay:false}) );
 
// 로딩 시작
queue.load();
 
// 로딩 일시정지
queue.pause();
 
// 로딩 다시시작
queue.resume();
 
// 이렇게 LoaderMax 객체의 모든 하위 로더들의 이벤트를 통합하여 받을 수 있습니다.
function progressHandler(event:LoaderEvent):void {
	trace("progress: " + event.target.progress);
}
 
// 이벤트 완료 후에는 아래와 같이 content 를 잡아낼 수 있습니다.
function completeHandler(event:LoaderEvent):void {
	var image:ContentDisplay = LoaderMax.getContent("photo1");
	TweenLite.to(image, 1, {alpha:1, y:100});
	trace(event.target + " is complete!");
}
 
function errorHandler(event:LoaderEvent):void {
	trace("error occured with " + event.target + ": " + event.text);
}

XML 내부의 LoaderMax 관련 노드 자동 파싱

LoaderMax 의 일부인 XMLLoader 클래스의 경우, 파싱될 XML 파일이 일정한 네이밍 규칙대로 노드명과 속성명을 작성하면 관련 로더 클래스들을 생성하여 로딩까지 모두 끝낸 후 Sprite 를 상속한 ContentDisplay 형태로 넘겨줍니다.
아래와 같이 doc.xml 파일을 만든 후,

<?xml version="1.0" encoding="iso-8859-1"?>
<data>
	<LoaderMax name="dynamicLoaderMax" load="true" prependURLs="http://www.greensock.com/">
		<ImageLoader name="photo1" url="img/photo1.jpg" />
		<ImageLoader name="logo" url="img/corporate_logo.png" estimatedBytes="2500" />
		<SWFLoader name="mainSWF" url="swf/main.swf" autoPlay="false" estimatedBytes="15000" />
		<MP3Loader name="audio" url="mp3/intro.mp3" autoPlay="true" loops="100" />
	</LoaderMax>
</data>

아래와 같이 XMLLoader 를 통해 로드하면

0
1
2
3
4
5
6
7
8
9
10
11
12

// ImageLoader 를 활성화
LoaderMax.activate( [ImageLoader] );
 
var loader:XMLLoader = new XMLLoader("xml/doc.xml", {name:"xmlDoc", onComplete:completeHandler});
loader.load();
 
function completeHandler(event:LoaderEvent):void {
 
	// xml 파일에 정의되어있던 name="photo1" 속성을 가진 ImageLoader 를 찾아서 content 를 가져옴
	var photo:ContentDisplay = LoaderMax.getContent("photo1");
 
	addChild(photo);
}

이렇게 로드의 이벤트 완료 리스너에서 LoaderMax.getContent() 메서드를 이용해 name 속성으로 객체를 잡아내어 바로 addChild() 시켜버릴 수 있습니다. 초 간단이죠.

작은 파일 사이즈

보통의 경우 간단한 text 를 로드하는데도 16~24K 정도를 사용하게 되지만, LoaderMax 는 7K 정도만을 사용한다고 합니다. 어떻게 이럴 수 있나 하는 생각이 들어 소스코드와 docs를 살펴보니 아래 그림과 같이 Flash 네이티브 클래스는 flash.events.EventDispatcher 만 사용하고 그 이후는 직접 구현해버렸더군요.

flash.display.Loader 클래스의 상속 체인

GreenSock 의 LoaderMax 라이브러리 중 XMLLoader 클래스의 상속 체인

모든 로더간 공통 속성과 메소드

LoaderMax 의 여러가지 로더 클래스들은 load(), pause(), resume(), prioritize(), unload() 등과 같이 공통된 메서드명을 이용합니다. 코드 힌트를 지원하는 에디터를 사용한다고 하더라도 메서드 명이 모두 제각각이면 아무래도 불편하겠죠. 그런 점을 고려한듯 합니다.

상위 LoaderMax 객체는 내부에 다른 LoaderMax 객체를 원하는 깊이만큼 포함 가능

2단계 이상의 로더 구조를 지원하여 progress, bytesLoaded, bytesTotal 등을 속성을 사용하거나 최상위 로더객체가 하부 시스템을 제어할 수 있습니다.

AutoFitArea 클래스 제공

ImageLoader, SWFLoader, VideoLoader 를 로드하고 width나 height 속성을 조정 했을 경우, 자동으로 원본 비율에 맞게 조정할 수 있습니다. 이것은 GreenSock 이 직접 제작한 예제를 보면 빨리 이해가 될 것 같네요.

이런식으로 썸네일 이미지 따위를 만들때 반드시 만나게 되는 좌우상하 비율 문제를 명쾌하게 해결해 주고 있습니다.

여러가지 편리한 속성 제공

편리한 자동 이미지 smoothing, 중심점(registration point) 이동, noCache 기능, x, y, scaleY, rotation, alpha, blendMode 속성을 초기값 세팅, mp3, swf, video 등의 자동 플레이 옵션등을 제공합니다. 특히 noCache 속성은 같은 이름의 url 을 로드할때 브라우저의 캐시에서 다시 가져오는 것을 강제로 막는 옵션입니다. 보통 이제까지는 파일의 url 에 random() 값을 넣거나, 시간 값을 마이크로타임 단위로 넣어서 캐시를 막았었죠.

가비지 컬렉션 관련 불편/버그 우회법

GreenSock 은 로드된 하위 swf 의 가비지 컬렉션이 작동 안되던 문제를 우회해 버렸다고 합니다.

name 또는 url 로 로더객체와 content 찾기

LoaderMax.getLoader() 나 LoaderMax.getContent() 를 이용해 각 객체를 손쉽게 잡아낼 수 있습니다.

단일 로더가 다수의 LoaderMax 객체에 속할 수 있음

상기한대로 LoaderMax 는 여러가지의 로더 객체를 포함할 수 있는데, 각 객체들은 또다른 LoaderMax 객체에 속할수도 있습니다.

정확한 로드 진행상황 정보 제공

퍼포먼스를 내기 위해서 로드가 일어나기 전에는 예상 바이트 수를 하드코딩(또는 xml 에 속성으로 코딩) 해 넣어놓지만, 로드가 진행되가면서 실제 파일의 바이트를 정확히 계산하여 로딩 정보를 주고 받게 됩니다.

런타임에 로드의 우선순위 변경

언제든지 로더의 로드 우선순위를 바꿀 수 있는 prioritize() 메서드를 제공합니다. LoaderMax 는 다수의 로드 요청이 있을때 queue 형태로 로드를 순차적으로 처리하는데, 이걸 런타임에 동적으로 우선순위를 바꿀 수 있다는 의미 입니다.

강력한 이벤트 시스템

LoaderMax 의 계층과 대상을 식별하기 쉬운 일관된 이벤트 대상 등.

한 줄의 코드라인에 여러개의 이벤트 리스너 설정 가능

코드로 보면 한번에 이해가 됩니다.

0

LoaderMax({name:"mainQueue", onComplete:completeHandler, onProgress:progressHandler, onError:errorHandler});

maxConnections 속성 설정

동시에 받을 수 있는 연결 숫자를 정할 수 있습니다. 2 로 설정하면 벌크 로더 과정에서 동시에 받는 파일이 2개가 되는거죠. 데이터 크기가 작은 파일이 다수 있을 경우에는 숫자를 크게 하면 좋고, 파일 크기가 큰 경우라던가, 파일의 갯수가 적을 경우에는 1 에 가깝게 설정하는것이 좋습니다.

pause() / resume() 메서드

로드과정 어떤 시점에서나 이 메서드를 호출하여 전체 로드를 일시정지하거나 다시 시작할 수 있습니다.

Flex 친화적

LoaderMax.contentDisplayClass 에서 FlexContentDisplay 객체로 쉽게 변경(아마도 캐스팅인듯)할 수 있어 ImageLoader, SWFLoader, VideoLoader 는 UIComponent 로 감싸진 content 를 반환받을 수 있습니다.

* * * * *

아… 이건 너무 좋습니다. 제가 사용하고 있던 클래스 중 몇가지는 이 라이브러리로 대체 가능하겠습니다.
여러분들도 지금부터 사용하세요.

LoaderMax 링크 (소스코드는 제작자의 블로그에 직접 다운로드 하세요)

그리고 위의 두 가지 데모 샘플 swf 파일을 만든 fla 와 도큐먼트 클래스도 원문 페이지 중간 부분 FAQ 의 9번 항목에서 제공되고 있으니까 그것도 놓치지 마세요. 실제로 어떻게 적용시키는지 한눈에 알 수 있습니다.

영화의 전개 부분에는 사부님으로부터 배우는 혹독한 수련과정이 나오는데, 이 수련과정 또한 매우 스테레오타입인지라 마당쓸기, 물 길어오기, 빨래하기, 밥하기와 같은 허드렛 일을 열심히 했는데, 애초부터 책 같은 형태의 궁극의 비기(秘記) 따위는 없었고… 일견 쓸모 없어보였던 잡일이 알고보니 나중에 다 피가되고 살이되는 거였더라~ 라는 이야기 구성과 설정 또한 항상 같습니다.

오늘 다뤄볼 이야기는 이런 허드렛일과 비슷하고 기본 소양이 되는 그런 이야기 입니다. 코딩을 하다보면 이게 변수인지 파라미터인지 함수명인지 그것도 아니면 클래스명인지 알 수 없는 경험을 하고계신 분들이 있을겁니다.
변수도, 이게 전역변수인지 지역변수인지, 전역변수라면 public 인지 protected 인지 private 인지 구분하고 싶은데 맨 위까지 스크롤 했다가 다시 내려오는걸 반복했다가는 코딩하다가 금방 지쳐 쓰러지겠죠.

액션스크립트 3.0 디자인 패턴. 조이 로트,대니 패터슨 공저/정호연,양주일 공역

그래서 이런 경우 각 멤버들에 대한 네이밍 규칙을 정해 놓는다면, 코딩이 훨씬 수월해질 수 있다는거죠.
제가 지금부터 써 내려가는 규칙들은 세계의끝이 고심끝에 정한 궁극의 네이밍 규칙…이 아니라 조이 로트와 대니 패터슨 공저, 액션스크립트 3.0 디자인 패턴(Advanced ActionScript 3 Design Patterns) 의 내용에 기술되어 있는 네이밍 규칙을 다시 정리하여 여러분에게 알려드리는 것입니다.
이 책은 장호연씨의 번역과 양주일씨의 감수로 에이콘 출판사에서 번역서가 나와 있으므로 관심이 있는 분들은 읽어보시면 되겠습니다.

이 포스트에서 소개하게될 네이밍 규칙이 유일하고 절대적인 규칙이 아니라는 것을 책에서도 설명하고 있습니다. 이것은 다분히 스타일의 문제이고 가독성의 문제이지 프로그램 성능의 본질과는 직접적인 관계가 없기 때문입니다. 물론 내가 작성한 코드를 남이 볼 때 쪽이 덜 팔리는 부수적인(?) 효과정도는 보너스로 얻을 수 있을것 같습니다.
네이밍에 대한 규칙은 41페이지부터 나와 있는 내용이므로 이 책에서도 가장 기본 단계의 지식으로 다루고 있는 셈 입니다.

* * *

사용할 수 있는 문자

액션스크립트에서 클래스, 패키지, 변수, 함수, 인터페이스를 네이밍할 때 사용할 수 있는 것으로는

1. a부터 z까지 그리고 A부터 Z까지의 영문 문자열^[01]
2. 0부터 9까지의 숫자. 그러나 네이밍이 숫자로 시작할 수는 없습니다.
3. _ (언더바 또는 언더스코어), 그리고 $(달러) 기호의 단 두가지 특수기호.

이렇게 세 종류를 네이밍에 사용할 수 있습니다. 상당히 심플하죠? 세번째 항목의 두 가지 특수기호 외에는 모두 연산자 또는 정규표현식에서 사용하도록 예약되어 있는 기호들이라 네이밍에는 사용할 수가 없습니다.

* * *

변수의 네이밍 (캐멀 표기법)

변수는 소문자로 시작하고 의미가 있는 단어를 구분하여 첫 글자만 대문자로 표현합니다.

0

var myInstanceName:Sprite

위와 같은 형태입니다.
위와 같이 소문자 기본에 단어를 기준으로 첫 글자를 대문자로 작성하는 표기법을 캐멀 표기법(Camel Notation 또는 Camel case)이라고 합니다. 네, 여러분이 떠올리신 그 낙타 맞습니다. 이런거죠. ^^

위키백과의 Camel Case 에서 가져온 낙타 이미지

이 캐멀 표기법은 액션스크립트 코딩의 전반에 걸쳐 사용될 뿐만 아니라 거의 모든 객체지향 프로그래밍 언어들에서 사용하고 있는 방법이기도 합니다.

한편, 변수중에는 함수 내부에서 사용되는 지역 변수가 있을 수 있고 클래스 전체에서 사용되는 전역변수가 있죠?

0
1
2
3
4

function getHealthPoint():int{
	var value:int; // 함수 내부에서만 사용할 목적의 지역 변수를 생성하였습니다.
	value = _hp + _itemBonus;
	return value;
}

지역변수는 이렇게 함수 내부에서 잠깐 쓰이고 소멸시키는 변수이므로 간략하게 표현하는 경향이 있습니다. 함수가 길지 않은 경우라던가 무슨 의미인지 함수 바깥에서 굳이 알 필요가 없다면 더욱 간단하게 한글자 변수도 사용할 수 있습니다. 우리가 for 문에서 흔히 사용하는 i 나 j 같은 것이 그에 해당하겠죠.

0
1
2
3
4
5
6

package{
	public class PlayCharacter{
		public var name:String; // public 변수명은 그냥 평범하게 사용합니다.
		protected var _money:Number; // protected 와
		private var _hp:uint; // private 에는 변수명 앞에 _ 가 붙어있습니다.
	}
}

전역변수는 다시 public, protected, private, internal 네 가지로 나뉘지만 internal 은 거의 사용하지 않으므로 제외하고 위와 같이 세 가지의 접근제한자를 살펴보겠습니다.
외부로 노출되는 public 전역변수는 가장 위에서 살펴본 것과 같이 일반적인 네이밍을 해 줍니다.
private 는 이 클래스 내부에서만 사용할 수 있는 전역변수이므로 빠른 코드 힌팅을 위해 _ 언더바를 가장 처음에 붙여 네이밍 하는 경우가 많습니다. 우리는 이런 네이밍에 이미 익숙하죠? AS2.0 때부터 사용하던 네이밍 방식입니다. 물론 AS2.0 때는 언더바가 붙든 아니든 public 이었지만 말이죠.
protected 는 상속 체인상에서만 사용할 수 있는 전역변수이므로 private 와 같은 스타일로 코딩하면 편리합니다.

이렇게 클래스의 private 변수에 언더바를 붙이는 방식은 사용하는 개발자도 있고, 그렇지 않은 개발자도 있습니다. 서로 의견이 다를 수는 있지만 이거 하나는 확실하죠. 코드 힌트를 받을 수 있는 에디터에서는 _ 를 타이핑 하는 순간 public 이 제외된 private, protected 멤버만 쫙~ 볼 수 있다는거!

FlashDevelop 에서의 코드 힌팅

* * *

상수의 네이밍 (언더스코어 표기법)

상수(const)는 변하지 않는 값입니다. 상수 생성과 함께 한번 설정한 값은 수정할 수 없습니다.
변수는 var 키워드로 생성하지만, 상수는 const 키워드를 이용해 생성합니다.
이러한 특성 때문에 상수는 변수와 확연히 구분되는 언더스코어 표기법(Underscore notation 또는 Underscore case)을 사용합니다.

0
1

// MouseEvent 클래스의 상단에는 이와 같이 상수가 정의되어 있을 것입니다.
static public const ROLL_OVER:String = "rollOver";

액션스크립트에서 상수를 표기할때 사용하는 언더스코어 표기법은 모든 문자열을 대문자로 작성하고 단어와 단어 사이는 언더바로 연결하는것이 일반적입니다.

* * *

함수의 네이밍 (캐멀 표기법)

함수의 네이밍은 기본적으로 변수의 규칙과 동일합니다. 생성자 함수 외에는 첫 글자를 소문자로 시작하고 언더바는 사용하지 않는것이 보통입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

package{
	public class PlayCharacter{
		public var name:String;
		protected var _money:Number
		private var _hp:uint;
 
		public function PlayCharacter(){
			// 생성자 함수는 클래스의 이름과 동일해야 하기 때문에 예외적으로 첫 글자를 대문자로 사용합니다.
		}
 
		private function useWeapon():void{
			// 일반 함수의 네이밍
		}
	}
}

함수는 보통 어떤 행동을 묘사하는 경우가 많으므로 위의 예제코드 대로라면 “무기를사용” 한다라는 의미와 목적에 따라 단어를 조합해 사용하게 됩니다. 그리고 영어의 어순에 따라 weaponUse 보다는 useWeapon 과 같이 동사+명사의 순서로 조합사용하는 것이 좀 더 일반적인 형태 입니다.
물론 play() 와 같이 한 단어로 이루어진 함수명도 문제없습니다.
그러나 단어가 명사라면? 그러니까 name 이라든지 age 같은 것이라면 이것은 속성이 되야하는 것은 아닌가 생각해 볼 필요가 있습니다.

* * *

클래스의 네이밍 (파스칼 표기법)

클래스는 대문자로 시작하고 나머지는 소문자로 작성하되, 의미가 다른 단어가 나오면 첫글자를 다시 대문자로 작성합니다. 캐멀 표기법과 동일하지만 네이밍의 첫 글자가 대문자로 표기하는 이 방법을 파스칼 표기법이라고 부릅니다.

0
1
2
3
4
5
6

package{
	public class PlayCharacter{ // 클래스명의 첫 문자는 대문자
		public function PlayCharacter(){
			// 생성자 함수
		}
	}
}

간혹 코딩시작한지 얼마 안되는 초보분들이 클래스명을 소문자로 시작하거나 _ 언더바 기호를 단어 중간 사용하는 경우를 볼 수 있는데, 클래스의 대문자 시작 규칙과 특수기호를 사용하지 않는 규칙은 반드시 지켜주는 것이 좋습니다. 이 규칙이 깨질경우 변수, 함수와의 구분이 어려워지고 코드의 가독성이 떨어지게 됩니다.
클래스명은 다른 한편으로는 데이터 형(type) 이죠. 우리가 var i:number 라고 하지 않고 var i:Number 라고 사용한다는 것을 기억하시기 바랍니다.

* * *

인터페이스의 네이밍

여러분이 인터페이스를 사용할 정도라면 표기법 정도는 이미 알고 계실테지만, 빠짐없이 모두 짚고 넘어가보자는 취지를 살려보겠습니다.

인터페이스 역시 클래스와 마찬가지로 데이터형(type)이 될 수 있고, 상속과 비슷한 implements (구현)을 통해 클래스를 확장하는 기능을 합니다.
인터페이스를 메소드 상속이라고 부르는 사람도 있죠? 상속과 비슷하지만 메서드를 구현하는것을 강제하기 때문인데요. 메서드가 기본적으로 동사형태를 띄고 있으므로 메서드를 강제한다, 또는 사용할 수 있다는 의미로 “~를 할 수 있는” 의 의미를 가진 able 을 접미사로 붙이게 됩니다.^[02]
Java 인터페이스 역시 -able 을 붙이는 스타일이 일반적이고, 액션스크립트가 Java 로부터 많은 부분의 기원을 두고 있으므로 액션스크립트도 그런 스타일을 따르기도 합니다만, 액션스크립트는 그보다는 우리가 흔히 볼 수 있는 IEventDispatcher 에서 처럼 인터페이스 가장 첫 글자 앞에 대문자 I 를 붙이는 방법을 더 많이 사용합니다.
물론 IObserverble 과 같이 두 가지 방법을 모두 적용해도 무방합니다.

0
1
2
3
4

package{
	public interface IAttackable{
		function attack():Damage
	}
}

이런식이 되겠네요.

* * *

그리고 단어 줄임 또는 단어 이니셜 사용

위에서 소개한 네이밍 규칙들을 모두 적용해보면, 변수나 함수의 길이가 길어지게 됩니다만,^[03] 그렇다고 해서 단어를 약어나 이니셜을 과도하게 사용하게 되면 코드의 가독성이 떨어지게 됩니다.
“어차피 다른사람이 볼 코드도 아닌데 뭐” 라는 생각을 하고 계실지라도 말이죠. 정작 본인조차도 2주 후에는 알아볼 수 없는 코드가 되버립니다. 유지보수 효율성은 저 달나라로 가고 있습니다.
btn (button), mc (MovieClip), cfg (config), init (initialize) 같은 수준은 괜찮습니다. 줄인 단어일지라도 자주 사용되고 누가봐도 대부분 뜻이 통하면 사용에 지장이 생기지 않습니다.

무엇보다 과도하게 길어지지 않는 한도내에서 옆사람도 이해할 수 있도록 쉬운 영어로 풀어서 묘사적으로 네이밍 하는것이 기본이라 할 수 있습니다. 학교다닐때 영어공부를 열심히 하지 않으신 분은 인터넷 영어사전 하나 쯤 펼쳐놓고 코딩하는 자세가 좋을것 같습니다.

1. 물론 액션스크립트는 uft-8 로 인코딩을 하므로 한글을 포함한 모든 언어의 문자열을 사용할 수 있으나 여러 가지 문제가 생길 수 있는 여지가 있으므로 영문 문자열로 네이밍을 제한하는 것이 좋습니다. 이에 해당하는 내용은 차후 별도의 포스트로 정리할 기회가 있을것 같습니다.
2. Observer 패턴의 인터페이스로 able을 붙여 Observerable 이라고 네이밍 하는 식입니다.
3. 상하로 늘어나진 않겠죠. 좌우로 늘어납니다.

클래스와 객체는 엄연히 다르죠. 클래스는 설계도일 뿐 입니다. 이 설계도(Class)를 이용해서 무언가를 만들면, 그것이 바로 객체(Object) 입니다. 그러므로 상위 클래스든 하위 클래스든 상속 체인과는 상관없이 이 설계도를 가지고는 부모 객체를 만들수도 있고 자식 객체를 만들수도 있죠. 이 당연한 사실을 이제 막 액션스크립트에 입문한 초보 개발자들은 깨닫지 못하는 경우가 많습니다.

실제 예를 들어보면 명확해집니다. DisplayObject 구조 상속 체인상으로 MovieClip 은 Sprite 를 상속했지만, 실제 우리는 MovieClip 클래스로 만든 객체를 부모 객체로, Sprite 클래스로 만든 객체를 자식 객체로 만들수 있는것과 같습니다.

어쨌든 부모, 자식 부모, 자식이라는 용어가 객체에서 사용되는것처럼 클래스에서 사용되는 경우가 있기 때문에 초보 분들이 혼동을 일으키는 것입니다. 여기서는 혼동을 줄이기 위해 상위 클래스, 하위 클래스로 지칭하겠습니다.

A. 상속한 경우 하위 클래스가 상위 클래스의 멤버를 사용

하위 클래스에서 상위 클래스의 메서드나 변수를 사용하고 싶으면, 그냥 사용하면 되죠. 단, public 이나 protected 인 녀석들에 한정해서 입니다. 하위 클래스는 상위 클래스를 확장(extends 키워드를 사용합니다.)한 것이므로, 이런 상태에서 객체를 만들면 extends 한 클래스의 멤버를 하위클래스에서 이미 사용가능하도록 상위 클래스와 하위 클래스는 이미 합체 되어 있다고 보면 됩니다. (물론 private 는 제외)
그러므로 다들 잘 아시는 바와 같이 하위 클래스에서는 상위 클래스의 public 이나 protected 멤버를 그냥 사용할 수 있습니다.

0
1
2
3
4
5
6
7
8
9

package
{
	public class SuperClass
	{
		protected function doSomething():void
		{
			trace( "SuperClass 에서 실행된 doSomething()" );
		}
	}
}

하위 클래스의 클래스 정의 라인을 주의해서 보세요. extends SuperClass 입니다.

0
1
2
3
4
5
6
7
8
9
10

package
{
	public class SubClass extends SuperClass
	{
		public function SubClass()
		{
			// SuperClass 의 protected 메서드 호출가능
			doSomething();
		}
	}
}

B. 상속한 경우 상위 클래스가 하위 클래스의 메서드를 호출

그런데 그 반대의 경우는 어떤가요? 상위 클래스의 입장에서 보면 자신을 상속(확장)하게될 하위 클래스가 어떤 것이 될지 알 수 없으므로 하위 클래스의 메서드나 변수등을 알 수 있는 방법이 없습니다. 호출이 불가능한 경우의 예를 보면 이해가 빠를것 같습니다.

0
1
2
3
4
5
6
7
8
9
10

package
{
	public class SuperClass
	{
		public function SuperClass()
		{
			// 호출 불가 !!
			doSomething();
		}
	}
}

SuperClass 를 상속한 SubClass 의 doSomething() 메서드를 SuperClass 에서 호출하는 것은 불가능 합니다.

0
1
2
3
4
5
6
7
8
9

package
{
	public class SubClass extends SuperClass
	{
		protected function doSomething():void
		{
			trace( "SubClass 에서 실행된 doSomething()" );
		}
	}
}

덮어쓰세요!!

그래서 이런 경우, 하위 클래스에서 호출하고 싶은 메서드를 상위 클래스에 public 또는 protected 으로 만들어 놓고, 하위 클래스에서는 override 를 사용하여 같은 이름으로 메서드를 재정의 하면, 상위 클래스의 메서드 본문은 무시되고, 하위 클래스의 메서드를 호출하는 효과를 가질 수 있습니다.
override 를 사용할 때 메서드 정의 부분은 인자와 반환 타입까지 모두 완전히 동일해야 하지 않으면 컴파일 타임에 에러를 내므로, 메서드 본문과 override 키워드의 추가 외에는 모든 내용이 동일해야 합니다.

아래의 코드는 개선된 상위 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

package
{
	public class SuperClass
	{
		public function SuperClass()
		{
			doSomething();
		}
 
		protected function doSomething():void
		{
			throw new Error( "이런 이런~ doSomething() 메서드를 override 하는걸 까먹었군요!!" )
		}
	}
}

SuperClass 에 doSomething() 이 정의되어 있으므로 SuperClass 에서 doSomething() 메서드가 호출이 가능해 집니다. 그러나 실제로 실행 되는 메서드는 SubClass 에 있는 doSomething() 메서드 입니다.
아래는 상위 클래스를 상속한 개선된 하위 클래스 입니다.

0
1
2
3
4
5
6
7
8
9

package
{
	public class SubClass extends SuperClass
	{
		override protected function doSomething():void
		{
			trace( "SubClass 에서 호출된 doSomething()" );
		}
	}
}

이런 경우에 SubClass 의 doSomething() 메서드에 대한 상대적인 개념으로 SuperClass 에 있는 doSomething() 메서드를 추상 메서드 라고 할 수 있습니다. Java 의 abstract 키워드 같이 명시적으로 추상 메서드를 지원하는 것은 아니지만 위에 보는 바와 같이 메서드 바디 부분에 new Error 를 throw 해 놓음으로써 SubClass 에서 해당 메서드를 강제로 override 하게 만드는 기능을 대신하는 것이죠. SubClass 에서 override 하지 않으면 컴파일 에러가 발생합니다.

그냥 SubClass 형(type)에서 doSomething() 메서드를 사용하면 되지 않겠냐… 하시겠지만, 아래와 같은 이유를 고려할 필요가 있습니다.

1. 가능하면 상위 형(type)으로 객체를 핸들링 하는 것이 유리합니다.
   이 내용은 참으로 많은 의미를 가지고 있습니다만, 주제를 살짝 벗어나는 내용이므로 일단 이렇게만 알고 넘어가고 자세한 것은 차차 알아가도록 하죠.
2. throw new Error() 를 해 놓지 않으면 SuperClass 에서 SubClass 에게 doSomething() 메서드를 강제할 방법이 없어집니다.
   doSomething() 메서드는 반드시 구현되어야 할 메서드지만, SuperClass 에서 throw new Error() 해 놓지 않으면 doSomething() 메서드를 구현하는 것을 잊을 가능성이 생깁니다. “설마…” 하실지도 모르겠지만, 다른 개발자가 하위 클래스를 구현하는 경우라던가, 심지어는 자신이 SuperClass 를 만들었어도 일주일만 지나면 까맣게 잊는 경우가 허다합니다. override 를 하지 않은 상태에서 컴파일을 하면 아래 그림과 같이 컴파일러 또는 Flash Player가 친절하게도 에러를 발생해 주므로 쉽게 오류를 바로잡을 수 있게 되는거죠.

마땅히 override 해야할 하위 클래스에서 임무를 망각했을 때 Flash Player 가 보여주는 런타임 에러

* * *

그렇지만 위와같이 예제를 봐도 뜬구름 잡는 느낌일뿐 뭔가 잘 와닿지 않죠? 자 그럼 override 한 메서드를 이용하는 실제에 가까운 예를 보도록 합니다.

아래는 상위 클래스에 해당하는 추상층 Item 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
	import flash.filters.BitmapFilter;
 
	public class Item extends Sprite
	{
		protected var _filterList:Array = [];
		protected var _filter:BitmapFilter;
 
		public function Item( $color:uint )
		{
			// 클릭을 위한 RoundRect 그리기
			// 그림 그리기, 이벤트리스너는 공통이므로 상위 클래스에서 처리
			this.graphics.beginFill( $color );
			this.graphics.drawRoundRect( 0, 0, 100, 100, 60 );
 
			this.buttonMode = true;
			this.addEventListener( MouseEvent.ROLL_OVER, rollOverHandler );
			this.addEventListener( MouseEvent.ROLL_OUT, rollOutHandler );
		}
 
		private function rollOverHandler( $e:MouseEvent ):void
		{
			// 공통적인 로직은 상위 클래스에서 처리.
			filters = _filterList;
 
			// 개별적인 로직을 처리하기 위한 메서드를 실행.
			rollOverForm();
 
			// 이렇게 이 객체를 addChild 한 부모 객체가 수신할 수 있도록 dispatchEvent() 하면서
			// 커스텀 이벤트를 이용해 이 Item 객체 내부에 있는 필터 객체를 보냄
			this.dispatchEvent( new CustomEvent( CustomEvent.CALL, { filterObject: this._filter } ) );
		}
 
		private function rollOutHandler( $e:MouseEvent ):void
		{
			filters = [];
			rollOutForm();
		}
 
		/**
		 * 하위 클래스 에서 override 해야 하는 메서드.
		 * protected 로 선언되어 있음
		 */
		protected function rollOverForm():void
		{
			throw new Error( "이런 이런~ addFilter() 메서드를 override 하는걸 까먹었군요!!" )
		}
 
		protected function rollOutForm():void
		{
			throw new Error( "이런 이런~ removeFilter() 메서드를 override 하는걸 까먹었군요!!" )
		}
	}
}

마우스 롤 오버 인터랙션에 사용한 커스텀 이벤트 클래스는, 포스트 본문 가장 아래쪽 소스코드 다운로드에 포함되어 있습니다.

아래는 위의 Item 클래스를 상속한 하위 클래스인 GlowItem 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

package
{
	import flash.filters.BlurFilter;
	import flash.filters.GlowFilter;
 
	public class GlowItem extends Item
	{
		private var _rollOutFilterList:Array = [];
		private var _blurFilter:BlurFilter;
 
		public function GlowItem( $color:uint )
		{
			super( $color );
			_filter = new GlowFilter( 0x6699FF, 1, 20, 20 );
			_filterList.push( _filter );
 
			_blurFilter = new BlurFilter( 20, 0 );
			_rollOutFilterList.push( _blurFilter );
			rollOutForm();
		}
 
		override protected function rollOverForm():void
		{
			// 여긴 딱히 할일이 없군요.
		}
 
		override protected function rollOutForm():void
		{
			// 이 클래스는 롤아웃 상태에서 블러 필터를 적용한다는 설정
			filters = _rollOutFilterList;
		}
	}
}

아래는 Item 클래스를 상속한 하위 클래스인 DropShadowItem 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package
{
	import flash.filters.DropShadowFilter;
 
	public class DropShadowItem extends Item
	{
		public function DropShadowItem( $color:uint )
		{
			super( $color );
			alpha = 0.5;
			_filter = new DropShadowFilter( 5, 45, 0x000000, 0.7, 5, 5 );
			_filterList.push( _filter );
		}
 
		override protected function rollOverForm():void
		{
			// 이 클래스는 GlowItem 클래스와는 달리 alpha 속성을 함께 변경한다는 설정
			alpha = 1;
		}
 
		override protected function rollOutForm():void
		{
			alpha = 0.5;
		}
	}
}

여기까지는 하나의 Item 상위 클래스에 두 가지 형태로 하위 클래스를 만들었습니다. 클래스 다이어 그램으로 보면 좀더 한눈에 이해하기 쉬울것 같습니다.

그리고 아래는 도큐먼트 클래스 입니다. 두 종류의 하위 클래스로 각각 한개씩의 객체를 생성했습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package
{
	import flash.display.Sprite;
 
	[SWF ( width = 440, height = 160, frameRate = 30, backgroundColor = 0xE3E3E3 ) ]
 
	public class DocumentClass extends Sprite
	{
 
		public function DocumentClass()
		{
			var item1:Item = new GlowItem( 0x336699 );
			with ( addChild( item1 ) )
			{
				name = "item1";
				x = 100;
				y = 30;
				addEventListener( CustomEvent.CALL, callHandler );
			}
 
			var item2:Item = new DropShadowItem( 0x008FCC );
			with ( addChild( item2 ) )
			{
				name = "item2";
				x = 240;
				y = 30;
				addEventListener( CustomEvent.CALL, callHandler );
			}
		}
 
		private function callHandler( $e:CustomEvent ):void
		{
			trace( $e.currentTarget.name, "filterObject:", $e.data.filterObject );
		}
	}
}

이 도큐먼트 클래스를 컴파일 하면 아래와 같은 swf 파일이 됩니다. 각각의 아이콘에 마우스를 올려보세요.

마우스 롤 오버에 필터를 적용하여 공통적으로 처리하는 부분은 상위 클래스에서 처리하게 되고, 공통적이지 않은 부분, 즉 GlowItem 의 경우 롤 아웃 상황에서 Blur 필터를 적용하는 것과, DropShadowItem 의 경우 alpha 속성을 변경하는 것을, 각각의 클래스에서 처리하게 하는 방법을 표현해 봤습니다.

메서드의 호출은 모두 상위 클래스인 Item 클래스에서 일어나게 되고, 하위 클래스에서는 각각의 상황에 맞는 상태를 상위 클래스에 공급해 놓는 역할을 한 것입니다.

  override 예제 코드 다운로드

* * *

이렇게 클래스의 상속 구조에서 상,하위 클래스간 메서드의 호출 방법을 알아보았습니다. 이와는 다르게 객체간 통신 방법에 대해 궁금하신 분들은, 지난 포스트 “AS3.0 클래스 구조의 여러가지 상황에서 부모, 자식 객체의 참조 방법” 을 읽어 보시기 바랍니다.

그러나 클래스를 이용하여 객체를 생성하는 경우에는 그렇게 단순하게만 돌아가지는 않습니다. 필연적으로, 원하지 않아도 부모 객체와 자식 객체를 생성하게 되는데, 몇 가지 규칙을 알고 있어야만 올바른 객체간 통신을 할 수 있게 됩니다.

이 내용은 AS2.0을 다루던 초보 개발자들이 AS3.0에 와서 가장 먼저 부딪히는 부분이며, 가장 많이 헤메는 부분이기도 합니다. 이제까지 MovieClip 이나 Sprite 객체를 만들어 마우스 클릭 이벤트만 걸고 노는 것에만 익숙했던 분들은 이 포스트를 정독하시면 많은 것을 얻으실 수 있을겁니다. 그런 즉슨 이 포스트는 AS3.0 에 막 입문한 초보분들을 위한 포스트 입니다.

아래에 설명한 방법들은 객체간 통신을 하기 위해 사용하는 여러가지 방법들 입니다. 물론 이 외에도 다른 방법이 있을 수 있습니다만, 가장 사용빈도가 높고 반드시 알아야 하는 몇 가지 방법을 소개하겠습니다.

A. 부모 객체가 자식 객체를 참조

객체간 관계에서 가장 흔한 상황이 되겠습니다. 부모 객체는 다수의 자식 객체를 가질 수 있고, 자식 객체에 public 으로 선언된 변수나 함수에 대해서는 자식 객체의 객체이름을 통하여 참조할 수 있다는것을 모두들 잘 알고 계실겁니다. 코드로 보면 아래와 같죠.
아래는 부모 객체를 생성한 부모 클래스의 코드 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13

package
{
	import flash.display.Sprite;
 
	public class ParentClass extends Sprite
	{
		public function ParentClass()
		{
			var _childInstance:ChildClass = new ChildClass();
			addChild( _childInstance );
			_childInstance.doSomething();
		}
	}
}

아래는 자식 객체를 생성한 자식 클래스의 코드 입니다.

0
1
2
3
4
5
6
7
8
9
10
11

package
{
	import flash.display.Sprite;
 
	public class ChildClass extends Sprite
	{
		public function doSomething():void
		{
			trace( "하위 클래스 : do something in ChildClass !!" );
		}
	}
}

B. 자식 객체가 부모 객체를 참조 – 첫 번째 방법

자, 그럼 거꾸로 자식 객체가 부모 객체에 있는 함수나 변수를 참조하려면 어떻게 하면 될까요? 자식 객체에서 parent 키워드를 사용하면 자신을 addChild 한 부모에게 접근할 수 있습니다만, DisplayObject 상속구조상의 메서드, 속성만 사용 가능할뿐 부모 객체에 정의된 것을 사용할 수는 없습니다.
이것의 논리적 원인을 따져보자면 이렇습니다. 우리가 부모, 자식 객체를 맺어주는데 사용한 메서드는 addChild() 입니다. addChild() 메서드는 Sprite 클래스가 바로 윗 단계에서 상속한 DisplayObjectContainer 클래스의 메서드죠. 아래의 레퍼런스 스샷에서 보시는 바와 같이 parent 를 사용해도 반환되어 나오는 것은 DisplayObjectContainer 입니다.

DisplayObjectContainer 의 읽기 전용 속성인 parent. 반환되어 나오는 것도 DisplayObjectContainer.

다시말해, DisplayObject 상속 체인 구조^[01] 에서 부모와 자식 객체간의 결합은 DisplayObjectContainer 가 담당하고 있다는 것이죠… 라는 내용은 당연스러운 사실이지만, 무심코 사용한 parent 역시 DisplayObjectContainer 형(type)을 반환 하므로, DisplayObjectContainer 를 상속한 Sprite 도, 그 Sprite 를 상속한 개별 클래스(ParentClass) 역시 DisplayObjectContainer 까지의 메서드, 속성만 사용할 수 있습니다.^[02]
약간 어려운가요? 논리적 원인을 따지자니 오히려 어려워진 감이 있는데, 어쨌건 ParentClass 의 메서드나 속성을 사용하기 위해서는 ParentClass로 형 변환을 해줘야 한다는 것만 이해하고 있다면 오케이 입니다.

아래는 부모 객체를 만드는데 사용한 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package
{
	import flash.display.Sprite;
 
	public class ParentClass extends Sprite
	{
		public function ParentClass()
		{
			var childInstance:ChildClass = new ChildClass();
			addChild( childInstance );
		}
 
		public function doSomething():void
		{
			trace( "상위 클래스 : do something in ParentClass !!" );
		}
	}
}

아래는 자식 객체를 만드는데 사용한 클래스 입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class ChildClass extends Sprite
	{
		public function ChildClass()
		{
			// 클릭을 위한 RoundRect
			this.graphics.beginFill( 0x336699 );
			this.graphics.drawRoundRect( 10, 10, 100, 100, 60 );
 
			this.buttonMode = true;
			this.addEventListener( MouseEvent.CLICK, clickHandler );
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			trace( this.parent ); // 출력 : [object ParentClass]
 
			// this.parent 는 DisplayObject 구조의 메서드나 속성만을 사용할 수 있음.
			// 상위 클래스 형(type)으로 형변환(casting:캐스팅) 하면 public 멤버를 사용할 수 있음
			ParentClass( this.parent ).doSomething();
 
			// 아래는 컴파일 에러
			// this.parent.doSomething();
		}
	}
}

trace( this.parent ) 출력 결과에서 보는것과 같이 parent 는 확실히 부모 객체 자체 까지는 참조 가능하지만 parent 가 가리키고 있는 것은 부모 객체의 DisplayObjectContainer 형태이기 때문에 부모 객체의 doSomething() 을 호출하게 되면 컴파일 에러가 발생합니다.
그래서 위와 같이 ParentClass로 형변환을 해야 부모 객체의 메서드를 사용할 수가 있습니다.

또한 형변환은 아래와 같이 할 수도 있습니다.

0
1

var parentInstance:ParentClass = this.parent as ParentClass;
parentInstance.doSomething();

C. 자식 객체가 부모 객체를 참조 – 두 번째 방법

자식 객체에서 부모 객체의 public 메서드를 사용하는 방법은 B 케이스와 같이 형변환 하는 방법 외에도 한가지 더 있습니다. 부모객체가 자식객체에게 부모 객체 자신을 참조할 수 있는 참조(레퍼런스)를 넘겨주는 방법입니다. 아래와 같이 말이죠.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import flash.display.Sprite;
 
	public class ParentClass extends Sprite
	{
		public function ParentClass()
		{
			var childInstance:ChildClass = new ChildClass();
			addChild( childInstance );
 
			// 이렇게 자식 객체에게 this(부모 자신의 객체 레퍼런스)를 넘겨줌
			childInstance.updateParent( this );
		}
 
		public function doSomething():void
		{
			trace( "상위 클래스 : do something in ParentClass !!" );
		}
	}
}

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class ChildClass extends Sprite
	{
		private var _parent:ParentClass;
 
		public function ChildClass()
		{
			// 클릭을 위한 RoundRect
			this.graphics.beginFill( 0x336699 );
			this.graphics.drawRoundRect( 10, 10, 100, 100, 60 );
 
			this.buttonMode = true;
			this.addEventListener( MouseEvent.CLICK, clickHandler );
		}
 
		/**
		 * 부모 객체의 레퍼런스를 저장함 (부모 객체에서 호출)
		 * @param	부모객체를 인자로 받아 전역변수에 저장
		 */
		public function updateParent( $parent:ParentClass ):void
		{
			this._parent = $parent;
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			this._parent.doSomething();
		}
	}
}

마치…부모가 통장과 도장과 비밀번호를 자식에게 알려주는 것과 같은 느낌이네요.

D. 자식 객체가 부모 객체에게 이벤트를 보냄

위의 B, C 케이스를 이벤트로 통신을 하는 형태로 바꿔보면 어떨까요? 흔히 사용하는 MouseEvent 도 이에 해당하지만, MouseEvent 같이 사용자의 인터랙션에 의한 이벤트는, 이벤트를 발생하는 객체(dispatcher:디스패쳐)가 하는일이 없는것처럼 보이므로 아래와 같이 일부러 디스패쳐를 사용하는 상황을 구성해보았습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class ParentClass extends Sprite
	{
		public function ParentClass()
		{
			var childInstance:ChildClass = new ChildClass();
			addChild( childInstance );
			childInstance.addEventListener( Event.COMPLETE, animationComplete );
		}
 
		private function animationComplete( $e:Event ):void
		{
			trace( "부모 객체에서 자식 객체에 걸어놓은 Event.COMPLETE 를 캐치함 !!" );
		}
	}
}

자식 객체를 만든 클래스 입니다. 클릭을 하게 되면 객체 자신에게 Event.ENTER_FRAME 을 걸게 되고 매 프레임마다 enterFrameHandler() 핸들러를 실행하게 됩니다. 자세한 내용은 주석을 참고하세요.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class ChildClass extends Sprite
	{
		public function ChildClass()
		{
			// 클릭을 위한 RoundRect
			this.graphics.beginFill( 0x336699 );
			this.graphics.drawRoundRect( 10, 10, 100, 100, 60 );
 
			this.buttonMode = true;
			this.addEventListener( MouseEvent.CLICK, clickHandler );
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			this.addEventListener( Event.ENTER_FRAME, enterFrameHandler );
		}
 
		private function enterFrameHandler( $e:Event ):void
		{
			// x 가 200이 될 때까지 감속운동 (easeOut)
			this.x += ( 200 - this.x ) * 0.1;
 
			// 200이 되면 엔터프레임을 중단하고 Event.COMPLETE 를 dispatchEvent() 함
			if ( Math.round( this.x ) >= 200 )
			{
				this.removeEventListener( Event.ENTER_FRAME, enterFrameHandler );
				this.dispatchEvent( new Event( Event.COMPLETE ) );
			}
		}
	}
}

실제 작업에서는 이런 종류의 코드를 작성해야 하는 경우가 많을 겁니다. 자식 객체에서 발생한 어떤 상황을 모두 실행한 후, 그 결과를 부모에게 알리고 싶은거죠.

E. 부모 객체가 자식 객체에게 이벤트를 보냄

부모 객체가 자식 객체에게 이벤트를 보낼 경우도 있겠죠? 부모 객체 입장에서는 자식 객체의 public 멤버들은 모두 참조가 가능하므로 자식 객체의 메서드나 변수를 직접 참조하여 데이터를 전달하거나 메서드를 호출할수도 있습니다. 바로 A케이스와 같은거죠.
그러나 A 케이스의 경우 부모 객체가 자식객체의 public 멤버들이 뭔지 알고 있어야 합니다. 물론 Flash(Flex) Builder 나 FlashDevelop, 또는 FDT, 그리고 Flash CS5 같이 코드 힌트를 지원하는 에디터에서는 자식객체가 가지고 있는 public 멤버들을 볼 수 있지만, 여기서 말하는 것은 그런 기능적인 부분을 이야기 하는 것이 아니라 객체지향 프로그래밍에서의 설계 원칙의 문제입니다. 예를 들어보죠.

만약 부모 객체와 자식 객체가 서로 분리되야할 상황이 생겼습니다. A나 B 케이스는 부모 자식객체간에 서로 직접 참조하고 있으므로, 이 두 객체를 만든 클래스가 분리되는 순간 서로를 참조하고 있던 부분은 모두 컴파일 에러가 발생합니다. 이런 것을 보고 두 객체간 강한 결합을 했다고 표현하죠.
한편, D나 E 케이스는 이벤트를 통해 이 결합을 다소 약하게 만들 수 있습니다. 데이터를 이벤트를 통해 전달하고 이벤트를 보냈다고 어떤 행동을 강제하지 않습니다. 이벤트를 보내는 입장에서는 보내는 걸로 역할을 다 한 것이고 받는 입장에서는 받긴 받았지만 이것을 실행할지 말지는 자신이 결정할 수 있기 때문입니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class ParentClass extends Sprite
	{
		private var _roundRect:Sprite = new Sprite;
		private var _childInstance:ChildClass = new ChildClass;
 
		public function ParentClass()
		{
			// 클릭을 위한 RoundRect
			_roundRect.graphics.beginFill( 0x996633 );
			_roundRect.graphics.drawRoundRect( 10, 10, 100, 100, 60 );
 
			_roundRect.buttonMode = true;
			_roundRect.addEventListener( MouseEvent.CLICK, clickHandler );
 
			addChild( _roundRect );
 
			addChild( _childInstance );
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			// _roundRect 의 MouseEvent.CLICK 를 캐치하면
			// _childInstance 객체에 MouseEvent.ROLL_OUT 이벤트를 보냄
			_childInstance.dispatchEvent( new MouseEvent( MouseEvent.ROLL_OUT ) );
		}
	}
}

부모 객체에서 사용자의 인터랙션에 의해 발생한 MouseEvent.CLICK과는 다른 이벤트를 고르느라 자식 객체에는 MouseEvent.ROLL_OUT 를 보내는 다소 엉뚱한 예제 입니다만, 이벤트는 이렇게도 할 수 있다는것을 보여주는 예시라고 볼 수도 있겠습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class ChildClass extends Sprite
	{
		public function ChildClass()
		{
			// ChildClass 객체의 존재를 확인하기 위한 RoundRect
			this.graphics.beginFill( 0x336699 );
			this.graphics.drawRoundRect( 120, 10, 100, 100, 60 );
 
			this.buttonMode = true;
			this.addEventListener( MouseEvent.ROLL_OUT, rollOutHandler );
		}
 
		private function rollOutHandler( $e:MouseEvent ):void
		{
			trace( "부모 객체가 자식 객체에게 dispatchEvent() 한 MouseEvent.ROLL_OUT 을 캐치함 !!" );
		}
	}
}

부모 객체(왼쪽에 그려진 RoundRect 그림)를 클릭하면 자식 객체에게 MouseEvent.ROLL_OUT 이벤트를 발생시킬수가 있습니다. 또한 자식객체에는 addEventListener( MouseEvent.ROLL_OUT ) 가 걸려 있으므로 자식 객체를 표시한 오른쪽 RoundRect 그림에 마우스를 올렸다가 밖으로 빼도 동일한 이벤트가 발생하게 됩니다.

F. 이벤트 발생위치를 바꿈

E 케이스의 코드는 부모객체가 자식객체에게^[03] dispatchEvent() 메서드를 사용한 것이지만, 반대로 부모객체 내부에서 dispatchEvent() 를 하고 자식객체에서 이것을 addEventListener() 할 수도 있습니다.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

package
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class ParentClass extends Sprite
	{
		private var _roundRect:Sprite = new Sprite;
		private var _childInstance:ChildClass = new ChildClass;
 
		public function ParentClass()
		{
			// 클릭을 위한 RoundRect
			_roundRect.graphics.beginFill( 0x996633 );
			_roundRect.graphics.drawRoundRect( 10, 10, 100, 100, 60 );
 
			_roundRect.buttonMode = true;
			_roundRect.addEventListener( MouseEvent.CLICK, clickHandler );
 
			addChild( _roundRect );
 
			addChild( _childInstance );
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			// 이번에는 부모 객체인 this 에 dispatchEvent() 를 함
			// _childInstance 객체에서 addEventListener() 하고 있건 말건 무조건 이벤트가 발생
			this.dispatchEvent( new Event( Event.SELECT ) );
		}
	}
}

아래는 자식 객체를 만드는 클래스 입니다. 자세한 내용은 주석을 참고하세요.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class ChildClass extends Sprite
	{
		public function ChildClass()
		{
			// ChildClass 객체의 존재를 확인하기 위한 RoundRect
			this.graphics.beginFill( 0x336699 );
			this.graphics.drawRoundRect( 120, 10, 100, 100, 60 );
 
			// 이 객체가 addChild() 되면 핸들러 실행
			// 즉, 어떤 객체의 자식 객체가 된 상황
			this.addEventListener( Event.ADDED, addedHandler );
		}
 
		private function addedHandler( $e:Event ):void
		{
			// 어떤 부모 객체인지는 모르겠지만 부모 객체에 addEventListener() 를 걸어놓음
			// addEventListener() 는 ParentClass 형(type)이 아니더라도 사용할 수 있으므로 캐스팅이 필요 없음
			this.parent.addEventListener( Event.SELECT, selectHandler );
		}
 
		private function selectHandler( $e:Event ):void
		{
			trace( "부모 객체의 이벤트를 자식 객체에서 캐치함 !!" );
		}
	}
}

또는 반대로, 자식 객체에서 this.addEventListener() 하지 않고, 부모객체에서 이벤트가 일어나도록this.parent.dispatchEvent() 한 후, 부모객체가 this.addEventListener() 까지 하게 할 수도 있습니다. 이벤트가 발생(dispatchEvent)하는 위치만 다를뿐 부모, 자식 객체간은 서로를 자유롭게 참조할 수 있으므로 addEventListener() 메서드는 어디나 걸어 놓을 수 있는 것이죠.

이렇게 부모, 자식 객체간의 여러가지 상황에서 서로를 참조하는 방법에 대해 알아보았습니다. 어떤 방법이 절대적으로 옳지 않으므로 상황에 따라 적절하게 사용하면 됩니다. 또한, 어떤 방법이 절대적으로 옳은건 아니지만, 모든 방법을 제대로 이해하고 있어야 합니다. 그 만큼 객체 지향 프로그래밍에서 가장 기초적이고 중요한 내용입니다.

이해가 잘 안되는 케이스가 있다면, 빈 fla 파일에 ParentClass 를 도큐먼트 클래스로 설정하고 컴파일을 해 보세요.

* * *

만약 이벤트와 함께 데이터를 보내야 할 필요가 있을 경우에는 커스텀 이벤트를 사용하면 됩니다. 커스텀 이벤트는 이 포스트의 범위를 벗어나는 내용이므로 “이벤트에 뭔가 같이 보내보자 – 커스텀 이벤트 만들고 사용해보기” 를 읽어보시기 바랍니다.

또한, 객체간 더욱 약한 결합을 구현하기 위한 별도의 방법으로는 옵저버 디자인 패턴을 이용하는 방법이 있습니다. “Observer Pattern 옵저버 패턴 – 이벤트 디스패처를 이용해 구현” 을 참고하세요.

이 포스트는 부모, 자식 객체간 참조 방법을 다룬 글이었습니다. 객체가 아닌 상위 클래스와 하위 클래스의 참조 방법에 대한 글 “AS3.0 클래스의 상속(extends)구조에서 상위, 하위 클래스의 메서드 호출방법” 도 초보 개발자 여러분들에게 많은 도움이 될 것입니다.

1. Object – EventDispatcher – DisplayObject – InteractiveObject – DisplayObjectContainer – Sprite
2. Object, EventDispatcher, DisplayObject, InteractiveObject, DisplayObjectContainer 의 메서드, 속성만 사용할 수 있고, Sprite 이하의 메서드, 속성은 사용할 수 없습니다.
3. 즉, 자식객체의 입장에서 보면 this.dispatchEvent() 된 것입니다.