정확히 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() 된 것입니다.

도제 시스템에 의한 학습의 기회라도 있었다면 그나마 운이 좋은 쪽이랄까요. 액션스크립트를 다루는 사람들의 출신성분중 대다수를 차지하는 디자이너 계통은 거의 대부분 독학으로 액션스크립트를 배우게 됩니다. 이래서야 제대로된 플래시 애플리케이션이 나올리가 없겠죠. 객체지향이라는 개념조차 피상적으로만 이해할 뿐, AS2.0이나 다를바 없이 메인타임라인에 코드 늘어놓기만 한참 하기 마련입니다. 도큐먼트 클래스를 사용할 수 있게 되고 자신이 직접 코딩한 클래스를 new 키워드로 객체 생성하여 사용할 수 있게 되기까지는 참으로 오랜 시간이 필요합니다.

특히, 다른 개발자와 협업을 해야 하거나, 유지보수를 위해 내가 개발한 코드를 다른 사람에게 넘겨 줘야 하는 경우라면 독학에 의한 프로그램적 구멍(?)이 더욱 눈에 띄게 됩니다.
이런 현상들은 여러가지 원인이 있겠지만, 결국 다른사람은 어떻게 코딩하는지 잘 모르기 때문에(나홀로 코딩) 생기는 것이라 할수 있습니다. 그렇다고 다짜고짜 플래시 동네의 유명한 누군가에게 가서 “공부 좀 하게 코드를 내놔라” 라고 할 수도 없는 노릇이고 말이죠.

이럴 때 좋은 참고자료가 되는 것이 구글코드검색 입니다.
구글코드검색으로 구글 코드의 프로젝트 호스팅을 통해 전세계 개발자들이 협업 또는 오픈소스 프로젝트를 진행하면서 공개한 코드를 검색해 볼 수 있습니다.

위의 이미지와 같이 검색창에 키워드와 한칸 띄고 lang:actionscript 를 추가해 넣으면 해당 키워드에 대한 액션스크립트 코드를 검색할 수 있습니다. 마우스 포인터가 가리키는 “고급코드검색“으로 들어가면, 위에서 한 것과 같은 프로그램 언어 설정이라던지, 라이센스, 패키지 등의 세부적인 설정과 함께 검색을 할 수 있습니다. 위의 스크린샷에 나온대로 검색하면 스트래티지 패턴(strategy pattern:전략패턴)에 관한 액션스크립트 클래스들이 검색되겠죠.

액션스크립트가 가장 위에 있죠? 알파벳 순서로 정렬되어 있기 때문인데, 스크롤을 하지 않아도 되서 편리합니다.

검색된 코드는 실무 프로젝트인 경우가 압도적으로 많으므로, 전체 프로젝트를 전반적으로 이해하지 않으면, 초보 개발자의 눈에는 이 클래스가 뭐하는 클래스인지 단번에 이해하기 어려운 점이 있기도 합니다만, 분명 다른 개발자의 코드를 참고할 수 있다는 것만으로 위안이 될 겁니다. ^^

또한 구글코드에서 검색되는 클래스들은 대부분 어느 수준 이상의 완성도가 보장되어 있습니다. 오픈소스로 공개되어 있는 코드들이기 때문에 공개하기 전 다른 개발자들이 제대로 사용할 수 있도록 자체 검증을 거치게 되기 때문입니다. 물론, 미완성이나 오작동하는 클래스도 간혹 존재합니다만, 이런 것을 가려서 참고를 하는 것은 역시나 사용자의 몫이 되겠죠.

* * *

보너스로 웹 브라우저의 검색도구에 구글코드검색을 추가하는 방법을 알아보겠습니다.

FireFox 의 검색 도구에 codesearch 추가하기

FireFox 에서는 간단히 애드온을 설치하기만 하면 됩니다.
https://addons.mozilla.org/ko/firefox/addon/46201

Internet Explorer 의 검색 공급자에 codesearch 추가하기

IE의 경우 검색 공급자 풀다운 메뉴를 눌러 “추가 검색 공급자 찾기…” 를 선택합니다.

이 페이지의 가장 아랫 부분에 있는 “나만의 검색 공급자 만들기“를 클릭합니다.

그런 후 나온 페이지에서 URL 입력에 액션스크립트 검색 설정을 포함한 검색 결과인 http://www.google.com/codesearch?hl=en&lr=&q=TEST+lang%3Aactionscript&sbtn=Search 를 입력하고, Name 에는 표시될 적당한 이름을 입력해 준 후, 검색 공급자 설치 버튼, 추가 버튼 클릭 하면 IE의 오른쪽 위의 검색공급자에 Google CodeSearch 가 추가됩니다.

우리가 Fla 에 도큐먼트 클래스를 연결해서 swf 를 만들었을 경우, Main.as 도큐먼트 클래스에서 trace( this ) 를 하면 [object Main] 이 출력 됩니다. “AS3.0 로더(Loader)로 불러온 다른 swf 의 클래스 사용하기” 의 예제 코드를 보면 다른 swf 의 도큐먼트 클래스의 이름을 통해 런타임으로 클래스로 만들고 그것을 객체화 하여 도큐먼트 클래스 내부에 있는 여러가지 자원들을 참조하게 됩니다. 도큐먼트 클래스의 이름이 곧 ApplicationDomain 이 되는 것이죠. 그것은 결국 도큐먼트 클래스의 클래스 이름을 알 수 없다면 getDefinition() 으로는 참조가 불가능하다는 이야기가 됩니다.

그런데 만약 도큐먼트 클래스를 사용하지 않은 fla 파일로 만든 swf 파일이라면 어떻게 되는 걸까요? “료”님의 질문을 받고 저역시 이 부분에서 살짝 당황했습니다. 도큐먼트 클래스 as 파일이 없는데 도큐먼트 클래스의 이름을 어떻게 알아낼 수 있을까 하는 것이었죠.

그런데 결국 추론를 통해 도큐먼트 클래스의 이름을 알아냈습니다.
라이브러리에 클래스 정의를 한 무비클립에도 물리적 as 파일을 연결하지 않으면, 컴파일 과정에서 자동으로 as 파일을 생성한다는것에 힌트를 얻었습니다.

라이브러리의 속성창에서 클래스 이름만 써 넣고 as 파일은 연결하지 않을때 나타나는 경고 다이알로그 박스

위의 다이알로그 박스의 메세지 내용인 즉슨, 클래스가 필요한 객체는 어떠한 형태로든 클래스 파일을 생성한다는 것이죠. 이와 마찬가지로 Flash IDE에서 도큐먼트 클래스 없이 컴파일을 하더라도 어딘가 가상으로 파일을 만들어 낼 거라는 생각이 들었습니다.

이때 빛을 발휘하는 프로그램이 바로 FlashDevelop(이하 FD) 이죠. FD 의 Project 패널은 as 파일과 디렉토리를 네비게이션 하는 1차적 용도를 가지고 있지만, 컴파일된 swf 파일이나 swc 파일의 구조를 분석할 수 있도록 기능도 가지고 있습니다.

FlashDevelop 의 Project 패널

FlaSubSystem.fla 은 도큐먼트 클래스가 없는 fla 파일 입니다. 이 파일로 FlaSubSystem.swf 파일을 컴파일 했습니다. 이 파일의 1프레임에는 간단한 무비클립과 코드 몇줄을 넣어놓았습니다.
Main.as 파일은 FD에서 프로젝트를 생성할때 만든 도큐먼트 클래스 입니다. 이 도큐먼트 클래스로는 GetDefinition.swf 파일을 만들었죠.

그러니까 “AS3.0 로더(Loader)로 불러온 다른 swf 의 클래스 사용하기” 의 내용과 매칭하자면 FlaSubSystem.swf 파일이 SubSystem.swf 이 되는 것입니다.

컴파일된 FlaSubSystem.swf 파일의 왼쪽에 있는 + 기호를 이용해 펼치면 swf 파일 내부에 정의되어 있는 클래스들을 모두 볼 수 있는데요, 보시는 바와 같이 fla 의 파일명에 _fla 라는 문자가 붙고 점 찍은 후에 MainTimeline 이 클래스 화 되어 있는것을 볼 수 있습니다. 1프레임에 코드를 넣게 되면 위와 같이 MainTimeline 이 클래스 화 되고, 프레임에 코드가 없으면 클래스가 생성되지 않습니다.

그러면 Main.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

package
{
	import flash.display.DisplayObject;
	import flash.display.Loader;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.net.URLRequest;
	import flash.system.ApplicationDomain; 
 
	public class Main extends Sprite
	{
		private var loader:Loader = new Loader();
		private var request:URLRequest = new URLRequest( "FlaSubSystem.swf" );
 
		public function Main()
		{
			loader.contentLoaderInfo.addEventListener( Event.INIT, completeHandler );
			loader.load( request );
			trace( this )
		}
 
		private function completeHandler( e:Event ):void
		{
			var runtimeClassRef:Class = loader.contentLoaderInfo.applicationDomain.getDefinition( "FlaSubSystem_fla.MainTimeline" ) as Class;
			var displayObj:DisplayObject = new runtimeClassRef(); //addChild 하려면 DisplayObject 로 캐스팅
			addChild( displayObj );
 
			var subSystemObj:Object = displayObj as Object; //메서드를 호출하려면 다시 Object 로 캐스팅
 
			// 아래의 member 들은 모두 fla 파일의 stage 또는 타임라인의 1프레임에 정의한 내용.
			trace( subSystemObj.myInstance ); // stage 에 인스턴스네임 부여한 무비클립 객체. 참조 가능 // 출력 : [object MovieClip]
			trace( subSystemObj.myString ); // 변수에는 접근안됨 // 출력 : null
			trace( subSystemObj.myGetter ); // getter/setter 메서드 접근 가능
			trace( subSystemObj.myFunction() ); // 함수 접근 가능
		}
	}
}

getDefinition() 메서드를 보면 fla 파일의 메인 타임라인 클래스에 접근하기 위해 FlaSubSystem_fla.MainTimeline 라는 문자열을 사용한것을 볼 수 있습니다. 이 ApplicationDomain 을 런타임 클래스 화 하고 객체로 만들어 내는 과정은 동일합니다.

각 요소들에 대한 참조 여부는 코드 내부의 주석에 적었으므로 그것으로 설명을 대신합니다.

타임라인 코드에 var 키워드를 이용해 생성한 변수에는 접근이 되지 않는데, 차후에 방법을 알게되면 추가하겠습니다. 그러나 getter/setter 가 가능하므로 굳이 필요하다면 변수 대신 사용할 수 있을것 같습니다.

레퍼런스란 필요한 부분을 검색하여 원하는 정보를 찾아보는 대상을 의미 합니다. 레퍼런스는 그 자체로 이미 사전과 같은 역할을 하는 것인데 개발자 출신이 아닌 플래시 액션스크립터 지망생들은 이 레퍼런스를 어려워 하여 멀리하고 오히려 포털 검색으로 지식을 얻으려고 하는 경향이 있습니다.
차라리 검색을 구글에서라도 하면 상위에 리스트업 되는 Adobe 의 레퍼런스를 보게 될 텐데, 그것도 아니고 국내 포털 검색으로 주로 지식검색이나 카페에서 자신과 딱 맞는 케이스의 질문과 답변을 얻으려고 하니 참으로 딱한 상황이 아닐 수 없습니다. 이러한 경향은 지식검색이 만능이라고 생각하는 우리나라에서 좀더 두드러지는 경향이기도 하지만, 외국이라고 예외는 아니어서 RTFM 라는 재미있는 관용구도 있습니다.

어쨌건 이러한 형태의 레퍼런스에 친숙해 진다면 다른 언어로 개발하는 것도 꿈속의 일만은 아니게 되는것이죠. 우리에겐 레퍼런스가 있으니까요.

1. 패키지 영역

패키지는 여러 클래스의 묶음 단위라고 이해하면 어렵지 않습니다. 우리가 가장 많이 사용하는 flash.display 패키지를 클릭하면 아래쪽 클래스 영역의 내용이 flash.display 항목들로만 필터링 되서 보여지고, 본문 영역도 그에 맞게 화면이 변경 됩니다.
레퍼런스에서 패키지 영역은 일종의 대분류 목차와 같은 성격을 가지고 있습니다. 클래스 이름을 알고 있다면 굳이 클릭할 필요가 없는 영역이기도 하죠.

그러나 이 영역에만 있어 별도로 살펴봐야할 항목도 몇 가지 있습니다.
스크롤바를 죽 내려보면 “패키지” 부분과 “언어요소” 부분, 그리고 “부록” 부분이 있는데 이것들 중 아래에 나열한 것들은 한번 쯤 훑어 보고 뭐가 있는지는 파악해 놓는게 좋습니다.

• 최상위 : import 를 사용하지 않아도 바로 사용할 수 있는 클래스들과 전역상수, 전역함수 들이 나열되어 있습니다. 우리가 흔히 사용하는 Array, String, Number 등이 최상위 클래스에 속합니다.
• 연산자 : 사실상 액션스크립트의 모든 기호는 연산자 입니다. 게다가 new 같은 것들도 연산자의 범주에 들어갑니다.
• 명령문, 키워드 및 지시문 : 프로그래밍의 형식이나 골격을 구성하는 것들 입니다. package, class, public, var, this 등이 여기에 속합니다.
• ActionScript 2.0 마이그레이션 : AS2.0의 클래스, 메서드, 속성이 AS3.0 으로 어떻게 변경 되었는지 리스트업 되어있습니다. (이 문서가 여기 있다는것만 알면 됩니다.)

나머지 부분들은 읽어본다면 어떤 형태로건 도움이 될 수 있지만, 딱히 읽지 않아도 지장이 없는 부분이므로 대략 스물스물 넘어가도 되겠습니다.

2. 클래스 영역

이 영역은 크게 클래스와 인터페이스 항목으로 나뉘는데, 이 중 이탤릭체로 되어 있는 애들이 인터페이스 입니다. AS3.0을 처음 배워나가는 과정에서는 인터페이스를 몰라도 괜찮기도 하고, 이 포스트의 내용에서 벗어나는 내용이므로 다음 기회를 잡아 설명하도록 하겠습니다.

이 영역을 스크롤 해서 보면 액션스크립트에서 사용하는 모든 클래스들이 나열되어 있습니다. 클래스의 이름을 알고 있다면, 딱히 검색할 필요 없이 클릭으로 본문 영역에 필요한 정보를 펼칠 수가 있습니다.

3. 본문 영역

우리가 가장 흔하게 사용하는 객체인 Sprite 를 펼쳐보겠습니다.

(1) 패키지

이 클래스가 어디 소속인지 알려줍니다. Sprite 클래스는 물리적으로 flash.display.Sprite 라는 경로에 있다는 것을 의미하죠. 실제로 액션스크립트의 내장 클래스는 플래시 플레이어에 내부에 들어 있으므로 실재로 Sprite.as 파일이 존재하지는 않습니다만,^[02] 실제로 파일이 존재한다고 생각해도 무방합니다.

(2) 클래스

클래스 정의를 표현 합니다. Sprite 클래스의 경우 어디서나 자유롭게 불러 사용할 수 있는 public 접근 제한을 가지고 있으며, class 라는 것을 의미합니다.

(3) 상속

이 클래스의 상속 체인을 모두 표시해 줍니다. Sprite 클래스가 정말 저렇게 5단계에 걸친 많은 클래스를 상속하고 있냐고요? 네 정말 그렇습니다. Sprite 는 이벤트를 발생시키기도 해야하고(EventDispatcher), 시각적인 표현도 해야하고(DisplayObject), 마우스 인터랙션도 받아야 하는데다가(InteractiveObject), Sprite 안에 있는 여러 가지 다른 요소들의 위 아래 순서도 정의해야 하기 때문에(DisplayObjectContainer) 해야 할 일이 꽤나 많은편이죠.

(4) 하위클래스

Sprite 클래스를 상속한 클래스의 목록 입니다.

(5) 언어 버전

이 클래스를 사용할 수 있는 액션스크립트의 버전입니다. Sprite 의 경우에는 ActionScript 3.0 부터 사용할 수 있다는 의미입니다.

여기서 잠깐 여러분의 이해를 돕고자 재미있는 이야기를 하나 꺼내보겠습니다.
현재 이 레퍼런스를 사용할 수 있는 ActionScript 버전 중에는 3.0이 가장 낮은 버전입니다. “당연하잖아!” 라고 생각하시는 분들에게 아래와 같이 질문을 드려볼까요?

“AS2.0 의 MovieClip 과 AS3.0 의 MovieClip 은 같은 클래스인가요, 다른 클래스 인가요?”

우리는 AS2.0과 3.0 모두에서 MovieClip 을 사용할 수 있고, 사용 방법 또한 같으며, 성질도 다르지 않습니다. 그러나 아래의 스크린샷을 볼까요?

그런데 뭔가 이상하죠? MovieClip 은 분명 AS2.0 에서도 사용할 수 있는데, 어째서 언어 버전이 ActionScript 3.0 이라고 써 있으며 런타임 버전 AIR 1.0, Flash Player 9 일까요?

그 해답은 AS2.0 레퍼런스를 보면 알 수 있습니다. 이걸 보면 AS2.0의 MovieClip 과 AS3.0의 MovieClip 은 클래스 이름은 같지만 엄밀히 말하면 별개의 클래스라는 것을 알 수 있습니다.

우선 상속 체인이 완전히 다릅니다. AS2.0은 Object 에서 단 한번 상속했을 뿐이지만, AS3.0의 MovieClip 은 위에서 살펴본 Sprite 를 상속 했으니까 무려 6단계의 상속 체인을 가지고 있습니다.

또한 속성도 다르죠. AS2.0이 AS3.0으로 바꼈어도 MovieClip 이라는 클래스 명은 동일하기 때문에 개발의 편의를 위하여 대부분의 속성명을 동일하게 유지했지만, 속성명 앞에 있던 _ (언더 바 또는 언더 스코어) 들이 사라졌습니다. 다르게 말한다면 속성이 죄다 바뀐거라고 할 수 있습니다.

(6) 런타임 버전

Flash Player 또는 AIR 런타임^[03] 의 최소 요구 버전을 나타냅니다.
초보분들은 Flash Player 의 버전과 ActionScript 의 버전, 그리고 Flash IDE의 CS 버전은 서로 다른 것을 이야기하는 것이므로 혼동하지 마시기 바랍니다.

(7) 그리고 개괄적 설명

이 부분은 이 클래스의 성격과 특성을 나타내므로 새로운 클래스를 만나게 되면 한번씩은 정독 해주는것을 권장합니다.

(8) 참고 사항

이 부분은 레퍼런스에 존재하는 관련 사항의 링크나 Adobe Flash용 Adobe ActionScript 3.0 프로그래밍쪽의 관련 페이지 링크를 제공하기도 합니다. 문제 해결에 결정적인 도움을 주기도 하는 부분이니 디버깅 할 경우라면 주의깊게 살펴보세요.

* * * * *

여기부터는 본문의 속성, 메서드, 이벤트 목록을 표시하는 부분 입니다.

- Public 속성 -

“상속되는 Public 속성 표시” 는 클릭하면 “상속되는 Public 속성 숨기기”로 링크가 변경됩니다. 이 기능은 클래스가 상속을 하게 되면 부모의 속성, 메서드, 이벤트도 모두 가지게 되기 때문에 상속체인상의 하위 클래스로 갈수록 속성, 메서드, 이벤트의 숫자가 상당히 많아집니다. Sprite 만 봐도 상당히 많은 숫자를 볼 수 있죠.

위 그림에서 우리가 흔하게 사용하는 alpha 속성을 잠시 살펴볼까요? alpha 는 소수점 표시를 해야하기 때문에 Number 의 데이터 형을 가지고 있다는 것을 표시하고 있고, 간단한 설명도 볼 수 있습니다.
오른쪽을 보면 “다음에 의해 정의됨” 항목에 DisplayObject 라고 되어 있군요. 즉, alpha 라는 속성은 DisplayObject 에서 정의되어 있으므로 상속 체인상에서 DisplayObject 를 포함한 InteractiveObject, DisplayObjectContainer, Sprite 의 자식 클래스에서 사용 가능하고, 상위 클래스인 EventDispatcher 나 Object 에서는 사용할 수 없는 속성이 되겠습니다.

여기서 잠깐 !

정말 쌩초보스럽지만 정말 중요한 질문하나가 있습니다.
속성은 어떻게 사용하나요?
코드로 보면 아래와 같습니다.

0
1
2
3
4
5
6
7
8
9
10

// 객체 생성 및 초기화
var instance:Sprite = new Sprite();
 
// 객체 속성에 값을 대입함
// buttonMode 속성은 Boolean 데이터 형이므로 true 아니면 false 둘 중 하나를 대입해야 함
// 객체.속성 = 속성값
instance.buttonMode = true;
 
// 객체 속성을 참조함
// 출력 : true
trace( instance.buttonMode );

속성은 클래스 내부에서 getter/setter 로 구현합니다. 읽기전용, 쓰기전용, 읽기쓰기 모두가능의 3가지가 있지만 쓰기전용이라는 것은 실제 사용할 일이 별로 없으므로, 일반적으로 getter 메서드만 있는 읽기전용, getter/setter 둘다 있는 읽기쓰기 모두가능한 두 가지 속성으로 나뉜다고 볼 수 있습니다.
위에서 코드로 예를 든 것과 같이 buttonMode 속성의 경우에는 읽기/쓰기가 모두 가능한 속성이므로 속성에 값을 대입할 수도 있고 값을 참조할 수도 있지만, numChildren 속성 같은 경우는 읽기전용 이므로 대입연산자 = 를 통해 값을 입력할 수 없는 차이가 있습니다.

getter/setter 는 어려운 내용은 아니지만 개념에 대한 이해가 필요하므로 이에대한 설명을 나중에 별도의 포스팅을 하겠습니다.

- Public 메서드 -

메서드 역시 부모로부터 상속한 모든 메서드를 사용할 수 있습니다. Sprite 클래스에서 정의한 메서드는 Sprite(), startDrag(), stopDrag() 이 세 가지 뿐이군요.^[04] 나머지는 모두 부모 클래스에서 정의한 메서드들이라는 의미 입니다.
위 그림중 우리가 흔하게 사용하는 addChild() 메서드를 살펴보도록 하죠. 함수연산자 () 안에 DisplayObject 타입의 객체가 들어와야 한다는 것을 나타내고 있습니다. child 라는 이름 자체는 의미가 없습니다. 다만 메서드명이 addChild() 이므로 add 하는 대상이 무엇인지 힌트를 주고 있는 것이죠.
그리고 addChild() 메서드가 반환하는 값 역시 DisplayObject 라고 되어있죠? addChild() 의 파마미터에 넣은 child 가 메서드 실행의 결과로 반환됩니다.

- 이벤트 -

이벤트는 addEventListener() 나 dispatchEvent() 메서드를 통해 사용하게 됩니다. dispatchEvent() 는 어떻게 사용하는 건데? 라는 질문을 하고 싶은 분이라고 하더라도 나중에 필요할 때 알게 됩니다. addEventListener() 만 사용할 줄 알아도 당장 AS3.0에 입문하는데 지장 없으니 걱정하지 마세요.

이벤트 목록의 오른쪽에 있는 “다음에 의해 정의됨”을 보면 Sprite 클래스에서는 정의한 이벤트가 없고 모두 부모 클래스에서 상속한 이벤트 뿐이군요. 사용자의 인터랙션, 즉 마우스나 키보드 입력에 의한 이벤트는 InteractiveObject 에서 상속했고, 인터랙션과 관계 없는 이벤트는 DisplayObject 에서 상속했습니다. 요약설명 부분에 [브로드캐스트 이벤트] 라고 표시되어 있는 것들 중에 몇몇 이벤트는 EventDispatcher 까지 거슬러 올라가기도 합니다.
브로드캐스트 이벤트가 뭔지 궁금한 분은 여기를 클릭해서 “DisplayObject 클래스에는 몇 가지 브로드캐스트 이벤트가…” 부분을 읽어보세요. 아직까지는 딱히 몰라도 관계 없습니다.

* * * * *

여기부터는 목록 더 아랫 부분의 상세 설명 본문 부분 입니다.

- 속성 정보, 생성자 정보, 메서드 정보 -

레퍼런스의 더 아랫 부분은 위의 이미지와 같은 현재 선택한 클래스의 속성, 메서드, 이벤트에 대한 좀더 자세한 설명이 있습니다. 각 속성이나 메서드의 상세 설명은 사실 알고 있으면 좋지만, 레퍼런스의 모든 부분을 읽는다는건 입문자에겐 불가능할 뿐더러, 읽는다 하더라도 전체적인 그림이 머리속에 그려지지 않은 상태에서는 사실 무슨 의미인지 이해가 되지 않는 경우가 많습니다. 그러므로 아래의 두 가지 방법 중 하나를 선택하는 것이 현실적인 방법 입니다.

1. 실제 코딩을 하면서 처음보는 속성이나 메서드가 나오면 레퍼런스에서 찾아서 한번 읽어 보는, 약간 더디지만 확실한 학습 방법.
2. 일단 코딩하면서 문제가 생기게 되면 문제가 생긴 부분의 레퍼런스를 읽어보는, 뭔가 빼먹을 가능성이 있긴 하지만 좀더 빠른 방법.

둘 중 자신에게 맞다고 생각하는 방법으로 그때그때 맞게 읽어 나가면 되겠습니다.
중요한 것은 무작정 레퍼런스나 책을 정독 또는 독파한다고 실력이 느는 것이 아니라, 실제 코딩을 해 나가면서 여러가지 문제에 봉착해 보고 해결 방법을 습득해 나가야 한다는 것입니다. 코딩 한줄 하지 않고 실력이 저절로 늘수는 없거든요.

본문 영역 중간중간에 해당 속성과 메서드에 해당하는 예제 코드가 있고 가장 아래쪽에 현재 선택된 클래스를 아울러 설명해 주는 예제 코드도 있으니 나중에 필요할 때 이용하면 되겠습니다.
커뮤니티 질문게시판에 올라오는 90%는 이미 레퍼런스에 있는 내용입니다. 버젓이 질문내용과 동일한 코드 예제가 있는 경우도 허다하죠. 다만 어디 있는지 못찾는 것이거나, 찾기 귀찮거나 둘 중 하나입니다.

자, 이렇게 레퍼런스의 구석구석을 설명을 통해 알아 봤습니다. 이제는 레퍼런스의 특정 부분의 의미를 몰라서 레퍼런스를 기피하는 현상은 좀 줄어드리라 기대해 봅니다.

* * * * *

글을 쓰는 현재 시점(2010년 1월)은 Flash CS5 가 나오기 직전의 시점이고 CS5 가 베타 버전으로 존재합니다. Flash Player 는 10.1 이 되는군요. 언어 버전은 AS3.0 으로 현재와 변화가 없으므로 골격이나 구조의 변화는 없고 마이너한 요소들이 추가되었습니다.

위에서도 잠깐 설명했지만 액션스크립트의 내장 클래스들은 Flash Player 에 존재합니다. CS4, CS5 와 같은 Flash IDE 버전에 따라 액션스크립트 API가 버전이 올라간다고 생각하기 쉽지만 그렇지 않습니다. Flash IDE는 저작 환경일 뿐이고 액션스크립트 버전과는 직접적인 관계가 없습니다.^[05]

마지막으로 Flash CS5와 함께 공개될 새로운 레퍼런스의 모습을 구경해 볼까요?
CS4 버전의 현재 레퍼런스와 크게 달라지는 부분은 없습니다. Beta 라고 군데군데 명시되어 있고, Flex Builder 3 에서 Flash Builder 4 로 명칭이 변경된 만큼 Flex 에서 사용하던 mx 패키지가 들어왔습니다. (예전엔 서로 별개의 레퍼런스처럼 취급되었죠)

베타 레퍼런스에 도입된 필터링 시스템 중 Runtimes 필터링

Products 의 필터링

이전에는 없던 필터링 기능이 눈에 띄는데, Runtimes 으로 Flash Player와 AIR를 구분하여 버전별로 필터링 할 수 있게 했고, Products 에는 Flex SDK 버전과 Flash IDE 버전 그리고 Blaze 서버와 LiveCycle, ColdFusion 까지, 액션스크립트와 관련을 가지는 다른 프로그램들의 레퍼런스들을 총 망라 하고 있습니다.
그 결과 왼쪽 패키지 목록과 클래스 목록에서 다루는 패키지와 클래스의 갯수가 꽤 많이 늘어 난 것처럼 보이는데, 적절한 필터링을 해서 사용하면 되겠습니다.

Flash Player 10.1 에 새로 추가된 Multitouch 클래스

이렇게 버전이 올라서 새로운 클래스가 업데이트 되어도 현재의 레퍼런스와는 크게 달라지는 점이 없습니다. 현재의 레퍼런스를 읽는데 어려움이 없다면 앞으로 훨씬 순조로운 개발을 할 수 있게되겠죠.

1. ASDoc은 작은의미로 Flex SDK에 포함된 레퍼런스를 만드는 프로그램의 이름이기도 한데, 이 포스트에서는 그것보다는 큰 의미로 레퍼런스와 동일한 의미로 사용하였습니다.
2. 모든 내장 클래스들이 마찬가지 입니다.
3. AIR의 R은 이미 Runtime 의 이니셜 입니다만, 여기서는 런타임이라는 것을 강조하기 위하여 상가”집” 식의 중복을 사용했습니다.
4. Flash Player 10.1 부터는 모바일 디바이스를 위한 터치관련 메서드들이 조금 더 추가됩니다.
5. 그러나 한편으로는 Flash IDE버전에 올라가면 Flash Player 의 버전도 같이 올라가는 경우가 대부분이므로 완전히 별개라고 보기에도 어려움이 있긴 합니다.

아이폰 출시와 함께 판매 고공 행진중

1. 스마트폰의 폭발적 유행

우리나라도 아이폰이 출시되면서 스마트폰 시장이 불이 붙기 시작했습니다. 출시한 KT 조차도 놀랄만큼 뜨거운 반응이 계속 이어지고 있죠. 아이폰이라는 뉴스메이커의 등장으로 매스컴에서 비중을 가지고 보도를 시작하자 이제까지는 거의 언급되지 않던 “스마트폰” 이라는 키워드가 일반인들에게도 상당히 높은 빈도로 노출되고 있습니다.

2. 재앙을 떠안고 있는 삼성 옴니아

유행에 민감한 우리나라 소비자들의 특성 덕분에 비슷한 시기에 같은 통신사에서 출시된 쇼옴니아도 덩달아 판매대수가 올라갔지만, 이것은 우리나라에서의 스마트폰이라는 신규 시장 초기의 반짝 현상일 뿐이고^[01] 전반적으로 아이폰에 비하면 처참한 성적을 보이고 있습니다. 마치 아이폰이 일으키고 있는 스마트폰 대유행에 옴니아가 무임승차한 모양새라 할까요?

이 차이는 무엇때문인가요?
하드웨어의 스펙으로만 보자면 세계 최고의 단말 제조사 중 하나인 삼성이 만든 옴니아가 대만의 OEM기업이 만든 아이폰에 밀릴 이유가 없습니다. 외형 디자인도 아이폰이 뒤통수가 약간 더 매끄러울 뿐 다른 디바이스들에 비해 전 세계적으로 이정도의 신드롬을 일으킬 정도의 특출한 디자인을 가지고 있다고 보기 힘듭니다.

그렇다면 아이폰의 운영체제와 앱스토어의 앱 들이 그 차이의 대부분을 차지하는 원인이라고 봐도 무방할 것입니다. 실제로 앱스토어에서 공급하는 앱들이 없다면 아이폰을 사용할 이유가 없어지죠. 인터넷 풀브라우징이 되는 피쳐폰과 다를바가 없습니다.

옴니아는 현재 모바일 운영체제중에는 최악이라 할 수 있는 WM^[02] 을 채택하고 있습니다. 옴니아가 떠안고 있는 재앙의 구체적인 모습이 바로 WM 입니다. 모바일 디바이스에서 점유율이 점점 떨어지고 있는 WM과 그다지 좋은 환경이라 볼 수 없는 개발환경을 말해주고 있는 빈약한 애플리케이션들이 옴니아에게 최악의 스마트폰이라는 오명을 씌우고 있습니다.

3. MS 의 역습

MS 에서도 시장상황이 자신들에게 별로 좋지 않게 돌아가고 있다는 것을 잘 알고 있습니다. 그렇다고 WM을 버릴 수도 없는터라 어떻게 하면 WM을 살리고 시장의 주도적 공급자로 도약할지 고민한 결과 참신하게도 X-box 라는 무기를 꺼내 들 모양입니다. (또 다른 기사)
Sony의 PS에게 콘솔게임 시장을 빼앗은 MS를 생각해보면 아직 MS 에게도 기회가 남아 있다는 희망이 보입니다. 물론 그럼에도 불구하고 WM이 최악의 모바일 운영체제라는 사실이 변하는 것은 아니지만 말이죠.

4. 안드로이드 탑재 스마트폰 국내 출시

우리나라에 출시될 XT720 과 외형이 같은 중국향 XT701

한편, 구글에서 오픈소스로 내놓은 운영체제인 안드로이드는 엄청난 파괴력을 내재하고 아이폰을 맹추격하고 있습니다. 이미 운영체제의 성능과 UX, 그리고 UI 디자인에서 아이폰을 거의 따라잡았거나 이미 추월했고, 안드로이드 마켓도 점차 활성화 되고 있습니다.
안드로이드에 대해 잘 모르시는 분들을 위해 안드로이드의 위상을 잘 표현한 포스팅을 하나 알려드립니다.

“구글폰에서 새 삶의 기회를 쫓는 한국 개발자들”

올해초 국내에 첫 출시되는 안드로이드 탑재 스마트폰은 SKT의 서비스를 달고 모토로라에서 시작 테이프를 끊을 모양입니다. 안드로이드 관련 커뮤니티에서 현재 최고의 안드로이드 단말로 통하는 드로이드가 아닌 다른 기종이 들어올 가능성이 높다는 것이 다소 아쉬운 점입니다만, 물꼬를 트게 되면 곧 다른 안드로이드 단말이 출시되는 것도 시간 문제입니다. 아이폰의 성공이 거의 예견되었듯이 안드로이드도 이미 검증된 운영체제이기 때문입니다.
1월 5일에는 구글의 브랜드를 달고 나오는 Nexus One 의 발표도 있을 예정입니다.

5. 애플의 타블렛 pc

루머로 돌고 있는 애플의 타블렛 이미지

애플은 2007년도에 아이폰을 출시하면서 Apple Computer Inc.라는 회사이름에서 Computer 를 빼 버리고 Apple Inc.가 되었습니다. 더이상 컴퓨터만을 만드는 회사가 아니라고 공표한 셈입니다. 그렇게 아이폰으로 모바일 생태계를 재편한 애플이 올해에는 타블렛 pc 를 발표할 모양입니다.
이 타블렛 pc 가 iPhone에 가까울지, MacBook에 가까울지는 아직 확실하진 않습니다. 유출된 제품 사진에 의하면 MacBook에 가까울것 같긴 하지만, 애플은 일부러 루머를 생산하도록 정보도 흘려주기도 하고 항상 스티브 잡스의 깜짝쑈를 최우선으로 하기 때문에 확실한 것은 나와봐야 아는 것입니다.
앱스토어의 혁신으로 아이폰의 성공을 이루었으므로 타블렛 pc 에서도 앱스토어 방식을 도입할 가능성이 크지만, 한편으로는 크기가 다른 스크린 해상도 때문에 별도의 앱스토어를 열어야 하는 부담도 존재 합니다.

아마존의 킨들

6. e-book 시장 가속화

애플의 타블렛 시장 진입은 오래전부터 예견되어 왔던 만큼 기존 e-book 단말기 공급자들은 긴장하고 있습니다. 물론 애플의 타블렛이 e-book 단말기와 포지션이 완전히 일치하는 않지만, 적어도 e-book 단말기의 일정부분 파이를 차지할 수 밖에 없는데다, 애플이 만들면 뉴스가 되니까 말이죠.
이미 안드로이드를 채택한 e-book 단말기도 출시 되었고, 반즈앤 노블의 누크, ASUS 의 단말 등, 기존 사업 진출자인 아마존의 킨들과 일대 격돌이 불가피하게 되었습니다. (e-book 관련 종합 기사 링크)
우리나라에서도 한글과 컴퓨터, 인터파크가 손을 잡고 e-book 관련 서비스를 런칭할 예정인데 아직까지 활발한 움직임을 보이고 있진 않습니다.
그나저나 이제는 종이책 보다 e-book 을 더 많이 보게 될 날도 멀지 않은것 같습니다.

7. 모바일 관련 사업 재편 원년

2010년은 모바일 관련 사업의 원년으로 기록 될 것 같습니다. 거의 모든 매체들이 올해의 이슈에서 모바일이라는 키워드를 제시하고 있습니다. 작년말에 출시된 아이폰을 시작으로 곧 있을 안드로이드 단말의 출시가 후폭풍을 예고합니다.
스마트폰의 점유율에 따라서 국내 시장에서는 다음과 같은 현상들이 보일 예정입니다.

• 기존 피쳐폰 제작사들과 기존 무선통신사업자들에 컨텐츠를 공급하는 cp들^[03] 의 사업축소 또는 스마트폰 컨텐츠로의 사업 영역 확장
• 모바일 쇼핑 확대
• 안드로이드 마켓과 아이폰 앱스토어에 앱을 공급하여 판매하는 개인 개발자들과 사업체들의 대거 등장
• 스마트폰과 SNS서비스를 접목하여 신규 서비스를 제공하는 사업체들의 등장
• Daum이 초기 선점한 모바일 포털과 검색서비스 시장을 탈환하기 위한 Naver의 추격

모바일 시장이 점점 커지면 기존의 데스크탑 pc 위주의 웹 서비스역시 많은 부분 변해야 합니다. ActiveX 를 사용하지 않는 서비스, 플래시 개발자의 입장에서 보면 안타깝지만 플래시 컨텐츠의 사용 어려움, 웹 표준을 좀더 준수 해야 하는등의 이슈가 있습니다.

1. 대부분의 일반인들은 아이폰과 옴니아가 다르다는 것을 인식하지 못할 뿐더러 스마트폰과 일반 피쳐폰과의 구분도 못합니다.
2. Window Mobile
3. 컬러링(벨소리), mp3 음원판매, 핸드폰 기종에 종속된 게임을 개발하여 통신사업자들에게 납품

플래시 개발자들은 최신의 API 활용과 Flash Player 컴파일을 위해 Flash IDE 를 최신 버전으로 항상 유지 합니다.(유지해야 합니다)

그런 반면, Flash IDE 버전이 항상 구 버전인 디자이너들도 있죠. 디자이너들은 대체로 보수적이고 한번 습득한 지식을 계속 움켜쥐고 놓지 않으려는 습성이 강합니다.^[02] 그들은 새로운 기술에도 둔감하고 기존에 잘 사용하고 있던 어떤 시스템이나 tool을 어지간하면 바꾸려 하지 않습니다.
어느 정도냐 하면, 지금 글을 쓰고 있는 시기가 2009년에서 2010년으로 바뀌는 시점이고 곧 Flash CS5 버전이 나올텐데, 아직도 Flash 8 을 사용하는 디자이너들이 많습니다. 심지어 MX 2004 버전을 사용 하는 경우도 있더군요. 아무리 AS3.0 을 사용할 일 없는 디자이너라고 해도 말이죠.

문제는 이 두 부류의 사람들이 사용하는 Flash IDE의 버전이 다른데서 옵니다. 아시다시피 fla 파일 포맷은 하위 호환성이 없으므로, 상위 버전에서 만든 fla 파일을 별도로 하위 버전에서 열리게끔 한단계 낮게 저장^[03] 하지 않는 이상 Ctrl + S 로 저장하면 하위 버전에서 fla 를 열 수가 없습니다.

상위 버전으로도 한 단계는 가능하지만 두 단계 이상의 상위버전에서는 불가능하죠. Flash 8에서 저장한 fla 파일은 CS4에서 열리지 않습니다.

플래시 같이 기술의 변화가 급격한 성향을 띄는 프로그램은 항상 최신 버전을 사용해야 함을 잊지 마세요.

***

2. 필요하다면 한글판 Flash IDE를 사용하세요.

컴파일 에러나, 대화상자를 읽지 못하는 사람들이 있습니다. 다른 이유가 있는게 아니라 단지 영어를 해석 못해서라면 이런 분들은 한글판 Flash IDE를 사용해야 합니다. 한글판은 뭔가 어색하고 뽀대가 안난다는 이유로 영문판을 고집하는 걸로 알고 있습니다만, 결코 컴파일 에러의 올바른 이해보다 중요하지 않습니다.

저는 모든 Adobe 프로그램들을 영문판으로 사용하지만,^[04] 유일하게 Flash만은 한글판을 사용하고 있습니다. AS3.0을 공부할 때 컴파일 에러 메세지를 정확하게 이해하기 위해서 처음 사용하기 시작했고, 지금은 한글판을 사용할 필요가 거의 없어졌어도 오래 사용하다 보니 이미 한글판의 어색함 따위는 느껴지지 않기 때문에 그냥 계속 한글판을 사용하고 있습니다.

그리고 컴파일 에러 뿐만 아니라 여러가지 대화상자의 의미 또한 명확하게 이해할 수 있게 됩니다.

영문판에서의 이 경고 메세지의 의미를 정확히 이해하십니까?

맥OS 에서는 이렇게 보이는 경고 창 입니다.

의미를 모른 채 Don’t warn me again 에 체크한 후 OK 를 누르지는 않았나요?

이런 대화상자의 경우 한글판에서 보면 명확하게 이해 됩니다.

1. 우리가 흔히 말하는 Flash CS4, CS5 같은 것들을 Flash IDE (Integrated Development Environment : 통합 개발 환경)라고 말합니다.
2. 손에 쥐고 있는 것이 썩은 도끼 자루인지도 모르고 말이죠.
3. 이 저장 방법은 정말 매번 귀찮은 작업입니다.
4. Photoshop 같은 경우는 한글판의 메뉴 명칭이 과도하게 번역되어 혼동을 일으키는 경우가 실제로 있습니다.

이 방법은 앞서 포스팅 한 라이브러리의 무비클립에 직접 클래스 파일을 연결한 경우와 비교하여 컴파일러의 선택이라는 측면에서 좀더 넓은 선택의 폭을 제공합니다. 라이브러리에 직접 클래스 파일을 연결한 경우는 최종 컴파일을 Flash IDE에서만 할 수 있는 반면, 오늘 소개할 Embed 태그를 이용해 그래픽 자원을 클래스에 직접 붙이는 경우에는 Flash IDE에서 컴파일을 할 수도 있고, Flex SDK를 통해 mxmlc 에서 컴파일을 하는 경우에도 사용할 수 도 있습니다. 무슨소리인지 잘 이해가 되지 않으셔도 일단 다음으로 패스! 포스팅의 내용과 살짝 거리가 있는 내용이므로 컴파일러에 대해 다루는 글을 나중에 별도로 포스팅 할 예정입니다.

***

먼저, fla 파일을 만들어 보겠습니다. 이름을 무엇으로 짓건 관계 없지만 이왕이면 파일이름에 어떤 역할을 하는 파일인지 네이밍을 해 준다면 Flash IDE를 열어서 어떤 파일인지 확인하는 수고를 덜 수 있겠죠. 그러므로 이 파일은 asset 이라는 폴더를 새로 만든 후 그 안에 TestProject_graphic_asset.fla 라고 약간 설명적으로 네이밍을 하고 저장했습니다.

드로잉 도구를 이용하거나 비트맵 이미지등을 import 하여 적당히 디자인을 하고 F8 단축키를 이용해 무비클립으로 만들어 줍니다. 라이브러리에서 방금 만든 MovieClip의 속성창을 열고 class 이름을 부여해 줍니다. 별 그림 이므로 클래스 이름은 MyStar 라고 지어보죠. 이때 Sprite로 만들고 싶으면 라이브러리의 무비클립을 클래스로 만들어 사용하기의 중간에 있는 관련 내용을 살펴보세요.

무비클립에 클래스 이름을 준 이후에는 무비클립이 스테이지에 놓여있건 아니건 우리나 사용하는데는 관계가 없습니다. 이 fla 파일은 그래픽 자원만을 사용하려는 목적으로 만들어진 것이므로 라이브러리 목록에 클래스 정의되어진 무비클립만 사용할 수 있습니다. 스테이지에 무엇이 놓여있건 최종 결과물과는 관계 없으므로 무비클립들을 배치하여 디자인을 미리 보는 용도로 활용할 수도 있습니다. 전체 예제 파일을 다운로드 하여 TestProject_graphic_asset.swf 을 확인해 보세요.

디자인이 완료되면 테스트 무비(Ctrl + ENTER) 나 퍼블리싱 메뉴(Ctrl + Shift + F12)를 통해 swf 를 생성합니다. 별다른 설정을 하지 않았다면 파일이름은 TestProject_graphic_asset.swf 이 되겠습니다. 그렇다면 asset 폴더 안에는 TestProject_graphic_asset.fla 파일과 TestProject_graphic_asset.swf 두개의 파일이 있을 겁니다.

자 그럼, 이 무비클립을 사용할 클래스를 하나 작성합니다. 클래스의 이름은 역시 MyStar 라고 지었는데요, 위에서 TestProject_graphic_asset.swf 의 라이브러리에 지정한 클래스의 이름과 동일하게 네이밍 했습니다. 이름이 반드시 같아야 할 필요는 없지만, 후일 클래스의 그래픽 자원을 라이브러리에서 찾아야 할 경우, 이름이 같으면 쉽게 찾을 수 있으므로 잇점이 생기는 거죠.

클래스 내용은 아래와 같습니다.

0
1
2
3
4
5
6
7
8
9
10

package items
{
	import flash.display.Sprite;
 
	[Embed(source='../../asset/TestProject_graphic_asset.swf', symbol='MyStar')]
 
	public class MyStar extends Sprite
	{
 
	}
}

src 폴더를 만들고 다시 그 안에 items 폴더를 만들어 MyStar.as 파일을 그 안에 저장했습니다. Embed 태그 의 source 속성에 swf 파일의 경로를 as 파일 기준으로 넣어주고, symbol 속성에 TestProject_graphic_asset.fla 의 라이브러리에 지정했던 클래스 이름이 들어가 있는 것이 보입니다. 이 클래스는 아직까지 그림 외에는 별다른 역할을 하지 않으므로 생성자 함수조차도 필요 없습니다. TestProject_graphic_asset.fla 파일의 라이브러리에는 MyEarth 클래스도 하나 더 만들어 놓았습니다. MyEarth.as 파일은 하단에 있는 전체 파일 다운로드에서 확인하세요.

여기까지 하면 모든 준비가 끝났습니다. 아래 도큐먼트 클래스에서 new 연산자로 MyStar 객체를 생성하고 addChild 메서드를 통해 화면에 표시했습니다.

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 items.*;
 
	public class TestProjectMain extends Sprite
	{
		private var star:MyStar;
		private var earth:MyEarth;
 
		public function TestProjectMain()
		{
			star = new MyStar();
			addChild( star );
 
			earth = new MyEarth();
			addChild( earth );
			earth.x = star.width;
		}
	}
}

위의 도큐먼트 클래스를 Flash Builder 나 FlashDevelop 등의 외부 에디터에서 직접 컴파일을 해도 무방하지만, 이번에는 TestProjectMain.fla 파일에 연결하여 컴파일을 해 보겠습니다. 아래 컴파일 결과에서 보는것과 같이 TestProjectMain.fla 파일에는 배경이미지가 있습니다.

이 방법이 가져다 주는 장점으로는 디자인단과 개발단이 명확하게 구분되어 협업 시스템에서 큰 이득을 가져다 주는 것이라고 할 수 있겠습니다. 디자이너는 그래픽 자원만을 가지고 있는 fla 파일을 수정하면 되고, 수정이 완료되면 컴파일 한번, 해야할 일은 그것으로 끝 입니다.

한편 개발자는 코딩을 하고 최종 컴파일을 하는 권한(또는 의무)을 가지게 됩니다. 디자인과 개발을 분업할 만한 정도 규모의 프로젝트라면 최종 컴파일은 개발자가 하는 것이 유리하다고 할 수 있고, 게다가 누군가 fla 파일을 열고 있으면 다른 사람이 수정하거나 심지어는 copy 조차도 되지 않은 fla 파일의 특성상, 개발자는 TestProject_graphic_asset.fla 파일을 만질 필요가 없고, 디자이너는 TestProjectMain.fla 파일을 만질 필요가 없는 이런 작업영역 분배는 상당히 바람직한 방법이라 할 수 있겠습니다.

  Embed 태그를 이용한 그래픽 자원 사용 예제

AS3.0 에서는 기존의 linkage^[02] 를 사용할 수 없는 대신, class 정의를 하고 new 연산자를 통해 객체를 생성한다는것은 알고 계실 겁니다. 라이브러리에 등록된 무비클립의 속성을 선택하면 아래와 같은 화면을 볼 수 있습니다.

라이브러리에 있는 무비클립의 속성메뉴를 선택한 화면

AS2.0 같으면 라이브러리 무비클립의 linkage 를 myMc 같은 스타일로 네이밍 했겠죠? AS3.0 은 본격적인 클래스 기반 프로그래밍이므로 MyClass 라고 네이밍 해 보았습니다. 클래스 이름의 첫 알파벳은 대문자로 시작하는것이 통상이므로 그것 역시 반영하였습니다.

그래서 이렇게 설정해 놓았으면, 아래와 같이 사용할 수 있게 되는거죠.

0
1

var instance:MyClass = new MyClass();
addChild( instance );

그런데 속성을 설정할 때 아래와 같은 대화상자가 나온 분도 있을 것입니다.

이 경고메세지는 “다시 표시하지 않음” 에 체크 한 후 닫으면 이후로는 보이지 않습니다. 간혹 영문 Flash IDE^[03] 에서 뭔가 자꾸 똑같은 것이 뜨는 것이 귀찮아서 무슨 내용인지도 모른 채 체크한 적이 있는 분은, 이 대화상자의 중요한 의미를 모르고 지나칠뻔 한 경우입니다.

다시 내용으로 돌아갑니다. 저 경고 메세지의 의미는 fla 파일과 같은 디렉토리에는 MyClass.as 라는 파일이 없다는 경고 메세지 입니다. 맞는 말이죠? 이런 파일을 우리는 만든일이 없습니다. 그래서 Flash IDE 는 swf 파일을 내보낼 때^[04]  MyClass.as 를 가상으로 만들어서 임의로 연결 한 후, swf 파일을 생성하게 됩니다.

가상으로 만들어진 그 파일의 내용은 어떤 내용을 가지고 있을까요? 간단합니다.

0
1
2
3
4
5
6
7
8

package
{
	import flash.display.MovieClip;
 
	public class MyClass extends MovieClip
	{
		public function MyClass ();
	}
}

즉, MovieClip 을 상속했고 아직까지는 인스턴스라던가 멤버함수와 같은 다른 내용이 없는 기본형태의 클래스 입니다. 우리가 만들지 않아 Flash IDE가 대신 만들어준 것이죠. 이것은 무엇을 말합니까? 라이브러리에 있는 클래스 화(化) 되어 있는 요소들은 우리가 *.as파일을 만들었건, 만들지 않았건 간에 모두 클래스 정의를 가지고 있다는 것을 말합니다.

“그럼 Sprite 로는 못만드나요?”

가능합니다. 클래스 이름란 아래에, 기본 클래스 라는 항목이 있고, 기본값으로 flash.display.MovieClip 이 지정되어 있는것을 가장 위의 스크린샷에서 확인할 수 있었습니다. 이 기본 클래스 항목을 flash.display.Sprite 로 바꿔주면 이 라이브러리 항목은 이제부터 Sprite 를 상속한 녀석이 됩니다. 더 이상 무비클립이 아니죠.

기본 클래스를 MovieClip 에서 Sprite 로 바꾸게 되면, 라이브러리 목록상에 보이는 아이콘의 색상도 아래와 같이 녹색으로 바뀌게 됩니다. 또한 가상으로 만들어지는 MyClass.as 파일도 MovieClip 대신 Sprite 를 상속한걸로 변경됩니다. 타임라인의 2프레임 이상을 사용할일이 없는 그래픽 자원이라면 Sprite 로 바꿔주는 것이 좋겠죠.

만약 이 Sprite 에 MovieClip 이었을적 만들어진 타임라인 애니메이션이 있다면 모두 무시되고 1프레임의 내용만이 유효한 내용으로 고정됩니다.

***

위에서는 클래스 정의만 하고 실제 클래스 파일(MyClass.as) 은 만들지 않았는데요, 매우 간단한 플래시 결과물이라면 그렇게 해도 별 지장 없을 것입니다. 클래스 정의를 하긴 하되, 그래픽 자원 이상의 취급을 해주진 않는 거죠.

그러나 점점 난이도와 복잡도가 높은 플래시 애플리케이션을 만들다 보면 클래스 파일이 그림이상의 역할을 해야할 경우가 생깁니다. 따라서 클래스 파일을 실제로 만들고 필요한 변수와 함수를 추가하는 등의 작업을 하게 됩니다만, 이 포스트의 범위를 벗어나는 내용이 되므로 다른 포스트에서 기회가 닿으면 살펴보기로 하고, 실제 클래스 파일을 만들어 연결하는 것은, 가상으로 클래스 파일이 연결되어지는것과 어떤 부분이 다른가를 짚어보도록 하겠습니다.

파일을 실제로 만들기 전에 매우 현실적인 상황 하나를 설정하겠습니다.  만들어야 하는 파일의 갯수가 많아질것을 대비해서 MyClass.as 파일을 fla 파일과 같은 디렉토리가 아닌 “ui” 라는 이름의 하위 디렉토리에 넣고 싶어졌다면 어떻게 해야할까요?

다음은 실제로 만들 MyClass.as 파일의 내용입니다.

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

package ui
{
	import flash.display.Sprite;
 
	public class MyClass extends Sprite
	{
		public function MyClass()
		{
			trace( "MyClass 클래스를 이용해 생성된 객체" );
		}
	}
}

위에서 Sprite 로 변경했으므로 그에 맞게 부모클래스를 설정했고, package 키워드 오른쪽에 ui 라고 디렉토리 이름을 붙였습니다.

이 파일을 fla 파일 기준 ui 디렉토리에 넣고, Flash IDE의 라이브러리의 MyClass 에 해당하는 Sprite 의 속성을 열고 왼쪽과 같이 디렉토리 경로를 추가해 줍니다. 디렉토리 경로는 곧 패키지 이름과 같게 되는것인데, 이 내용도 차차 알아나가기로 하겠습니다.

***

여기까지 확실히 이해를 했다면 Flash IDE 기준의 프로젝트에서 라이브러리의 그래픽 자원을 클래스로 만들어 사용하는 데에는 문제가 없으리라 생각합니다.

이어지는 내용으로는 라이브러리의 그래픽 자원을 클래스 파일에서 이용하는 다른 몇 가지 방법들에 대한 내용이 되겠습니다.

1. 별도의 지칭이 없는 한 이 블로그에서 AS2.0 방식 프로그래밍이라 함은 클래스를 이용하는 방식이 아닌, fla 파일의 타임라인에 코딩하는 방식을 이야기 합니다.
2. 한글판 Flash IDE 에는 “식별자”라는 명칭으로 되어있습니다만, 영어 단어를 발음 그대로 옮겨쓴 “링키지”로 더 많이 알려져 있죠.
3. 우리가 흔히 말하는 Flash CS4, CS5 같은 것들을 Flash IDE (Integrated Development Environment : 통합 개발 환경)라고 말합니다.
4. 컴파일 또는 테스트무비 한다는 의미입니다.

며칠전에 뤽 베송의 초기작 "마지막 전투"를 본 김에 생각나서 레옹(원제:The Professional)의 포스터를 넣어보았습니다.

제목을 위와 같이 잡아 본건 다음과 같은 흥미로운 이야기가 곁들여져 있습니다.

제가 주로 활동하고 있는 플생사모에는 “고수”를 찾는 질문글이 하루에도 몇십개씩 올라옵니다. 하나같이 고수님이 자신의 문제를 해결해 주길 바라고 있는데, “이 문제를 해결하실 수 있는 고수님들만 보세요.” 같은 스타일의 제목이라면, 고수가 아닌 저는 답변도 달지 말라는건가요?

“고수” 라는 단어가 언제부터 이렇게 흔하게 쓰였는지는 모르겠지만, 단어에 특별히 좋지않은 이미지가 스물스물 배어들은것 같습니다.

한편 제가 참여하고 있는 스터디 그룹의 리더인 우야꼬군은 평소에 “고수”와 “프로”와의 구분을 이렇게 한다고 합니다.

고수는 엄청나 보이는 로직과 현란한 코드 테크닉으로 빠르게 프로그램을 짜고 버그를 재빨리 알아내어 순식간에 수정을 해치우는 반면, 프로는  같은 기능의 프로그램을 만들어도 코드가 훨씬 간단하고 애초부터 버그가 일어나지 않도록 프로그램을 작성한다고 합니다. (우야꼬 어록?)

위의 내용에서, 누군가를 가르치는 입장으로 상황으로 바꾸어 정의해 본다면,

고수는 자신의 뛰어난 실력을 발휘하여 학생이 무엇이 부족한지 신경쓰지 않고 어려운 테크닉을 늘어놓는 반면, 프로는 학생이 현재 무엇이 필요한지 파악하고 그것을 적절하고도 가볍게 이해시켜줍니다.

가장 불행한 케이스는 학생 자신도 무엇을 모르는지 조차 잘 모르는 경우와, “이건 어려운게 아닌데…” 라고 고수가 대답하는 경우 입니다. 그래서 이 시리즈 포스트의 제목에 있는 “고수” 라는 단어는 사실상 이리저리 긍정적인 의미로 사용되지 않았음을 미리 밝히는 바입니다.

***

이런 느낌?

그러나 꼭 위의 이유 때문이 아니더라도 AS3.0 시작하는 사람들은 그 앞에 놓인 무언가에 탁 하고 막히는 느낌과 만나게 됩니다. 저는 그것을 “AS3.0 주위를 둘러싸고 있는 벽들” 이라고 표현을 합니다. 이 벽의 높이는 프로그램적 이론과 지식기반이 없는 디자이너 계층의 경우에 한층 높아지고, 아이러니 하게도 AS2.0을 다룰 줄 아는 사람에게 더 높게 보이는 경향이 있습니다.

이 시리즈는 그 높아 보이는 벽을 넘을 수 있는 수준으로 낮게 보이도록 하는 몇가지 방법을 소개하게 됩니다. (한편으로는 저의 경험담에 다름없을 것입니다.)
특정한 수준에 위치한 사람이 다음 단계로 넘어갈 수 있게 도움을 주고자 하는 것이 이 포스트들의 목적이기 때문에 이 시리즈를 읽을 필요가 있는 분은 아래 분들에 한정됩니다. (이 외의 분들이 읽어주시는 것은 시간낭비가 될 가능성이 높습니다.)

1. AS2.0 은 다룰줄 아는데 AS3.0 은 무비클립을 addEventListener 를 이용해 버튼으로 만들어 사용할 수 있는 수준.
2. 온라인 강좌와 책을 읽을때는 무슨소리인지 알것 같으나, 막상 코드를 짜려고 하면 뭐부터 해야할지 막막.
3. AS3.0 코드는 fla 파일의 1프레임에만 작성해 봤을 뿐.

이것은 마치… 그 예전 동네 어귀에 들어온 약장수의 멘트 같지 않습니까?
어쨌건 대략 위와 같은 분들을 이 포스트 시리즈의 독자로 설정했습니다.

AS3.0을 공부하기로 마음먹고 이런 저런 것을 해 보는데 위에서 말한 어떤 벽에 막혀서 버둥대다가 시간을 허비하고 생업(아마도 디자인)으로 돌아가고 하는 것을 여러번 반복해본 사람들이죠. 눈치채신분들이 있을지 모르겠는데, 맞습니다. 바로 제가 그렇게 AS3.0 을 접할 기회를 몇번을 만들었음에도 불구하고 매번 벽에 막혀 시간을 허비한 사람이죠. ^^

그러다가 어느 특정한 시점에 이제까지 막혔던 원인이 바로 이 부분을 몰라서 라는 것을 깨닫게 됩니다. 벽에 막혔을때 누군가 관대하시고 관대하신 분이 “이 부분을 확인해 보거라” 라고 한마디만 해 줬다면, 저는 몇년의 시간을 절약하고도 남았을 것입니다.

***

그렇지만 무엇보다 중요한 것은 실제 AS3.0 으로 무엇인가는 만들어 봐야 한다는 것입니다. 제아무리 훌륭한 강좌에, 온갖 원서, 번역서를 다 떠안고 있어도 실제 만들어보지 않으면 그냥 허공으로 날아가는 지식일 뿐입니다.

또한 이 포스트 시리즈는 강좌가 아닙니다. 레퍼런스 스타일로 하나부터 열까지 다 나열해가며 설명하는 것이 아니라 특정한 몇가지 방법을 몰라서 겪게 되는 문제의 해결을 다루고 있습니다. 좀더 정확하게 표현하자면 “고수”들은 대수롭지 않게 생각해서 지나친 그 부분이 어떤 부분인지 알려 드립니다.

과연 몇 분이 각성을 해주실지, 저도 기대 되는군요.

ExternalInterface 를 이용해 JavaScript 를 호출할때 생긴 스크립트 에러

EditPlus 의 내장 브라우저는 IE 엔진을 사용해서 렌더링을 하죠. 현재 EditPlus 의 최신 버전인 3.11의 내장 브라우저는 IE8과는 매우 다르고 IE6은 아닌것 같으면서 IE7과도 약간 다른, 어느쪽에 가장 가깝느냐 하면 버전 7에 가깝고, 숫자로 표현하면 체감상 6.7정도 되는 렌더링 엔진입니다.^[01]

EditPlus 에서는 Ctrl + B 를 이용해서 브라우저 미리보기를 하면 위의 스크립트 에러창이 모달(modal)창으로 자동으로 뜨고, 실제 데스크탑에 설치된 IE8로 보면 왼쪽 아래에 노란색 삼각형 스크립트 에러 표시가 나는 상황입니다. 에러 메세지로 보아 ActionScript 에서도 흔하게 보는 null 객체 에러네요.

그럼 FF나 GC 에서는? 괜찮습니다. 이 에러는 IE 에서만 나오는 문제였고, IETester 로 확인한 결과 IE6, 7, 8 모두에서 동일하게 발견되었습니다.

한참동안 원인을 찾을 수가 없어 꽤 오랜 시간을 헤메다가^[02] , 다시 처음부터 되짚어가보자는 생각에 Flash IDE의 퍼블리싱 세팅(Ctrl + Shift + F12)에서 html 을 포함하여 퍼블리싱을 한 후, 새로 만든 html로 swf 을 보니 이번에는 ExternalInterface가 정상적으로 동작하는 겁니다.

기존 html 에 사용한 object , embed 코드와, 새로 만든 코드의 다른점을 살펴본 결과, 기존 html 코드에는 object 태그의 id 값을 주지 않은 것을 발견했습니다.

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0" width="100%" height="100%" id="" align="middle">
	<param name="allowScriptAccess" value="sameDomain" />
	<param name="allowFullScreen" value="false" />
	<param name="movie" value="swf_app.swf" />
	<param name="quality" value="high" />
	<embed src="swf_app.swf" quality="high" width="100%" height="100%" name="" align="middle" allowScriptAccess="sameDomain" allowFullScreen="false" type="application/x-shockwave-flash" pluginspage="http://www.adobe.com/go/getflashplayer_kr" />
</object>

object 태그 속성중 height="100%" 다음에 보이는 id="" 의 공백문자가 보이시나요?
한편, 비 IE 계열 브라우저들이 사용하는 embed 태그에는 id 속성이 있어야 할 자리에 name 속성이 있는데요, FF나 GC 는 이렇게 name="" 속성이 공백이라도 ExternalInterface 가 동작하는데에는 전혀 문제가 없습니다. 실제로 object 의 id 속성과 embed 의 name 속성은 Flash IDE에서 퍼블리싱 했을 때, 그다지 의미 없어 보였던 swf 의 파일명이 기본값으로 입력되는것에 이런 이유도 포함되어 있었던 겁니다.

‘설마…’ 하면서 임의의 값을 넣었더니 허무하게도 정상적으로 동작합니다. 임의 값이란 정말 임의의 값입니다. 공백문자만 아니라면 아무 문자나 상관이 없습니다.

ExternalInterface 를 사용하지 않는다면 id 속성이 공백문자라도 swf 의 동작 자체는 문제가 생기지 않습니다. 결국 JavaScript 함수 호출을 하기 위해, swf 무비와 html 컨테이너 사이에서 함수 호출이 발생한 객체(swf)를 IE가 찾지 못해서 생기는 에러인 것이죠.

1. 실제로 이런 버전의 IE는 없지만, html의 표준화 표현 정도와, 여러 가지 렌더링 표현등을 고려해 봤을때 그정도 될것 같다는 의미 입니다.
2. 지금 기억을 더듬어 보면 몇시간 동안 원인을 못찾았던것 같습니다

1. 첫 번째로는 개행문자 입니다.

왼쪽과 같이 나오길 기대하지만 개행 문제 때문에 오른쪽과 같이 되버립니다.

2. 두 번째로는 탭 문자 입니다.

이런 화면, 종종 만나보셨을 겁니다.

Edit plus 에서의 화면, 왼쪽과 같이 입력되지만 탭 문자 때문에 오른쪽 같이 수정해야하는 경우가 있습니다.

3. 세 번째로는 & (앰퍼샌드) 문자입니다.
xml 은 모든 특수문자가 입력 가능하지만, &만큼은 예외로 xml 노드명, 노드값, 속성명, 속성값 어디에 있건 파싱 에러를 내게 됩니다. 액션스크립트가 에러를 내기 이전에 xml 파일을 브라우저로 열어보는것 만으로도 &는 xml 에 사용될 수 없음을 잘 알 수 있습니다.
그렇다고 &를 안쓸 수 있느냐 하면 그럴수도 없습니다. 네비게이션 바 만들때 Q&A 같은 문자열은 매번 문제가 되죠. &를 입력할 일이 있을 때 and 로 바꿔서 입력하려는 노력도, Q&A 앞에서는 한동안 멍때리게 됩니다.
그래서 &의 코드 값인 “%26″으로 입력하고 액션스크립트에서 “&”로 바꿔 줍니다. Q&A 는 Q%26A 로 입력하면 되겠죠.

이렇게 xml 단골 replace 를 모아서 한번에 처리할 수 있는 클래스를 만들었으니 이름하여 OptimizeXMLString 입니다.

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

package kr.ufx.utils
{
	import kr.ufx.text.replaceString;
 
	/**
	 * ...
	 * @author 원종선(세계의끝) http://ufx.kr/blog
	 */
	public class OptimizeXMLString
	{
		// 찾을 문자열
		private var _arrStringList:Array = [ "\r\n", "\t", "%26" ];
 
		// 바꿔낼 문자열
		private var _arrReplacedList:Array = [ "\n", "", "&" ];
 
		private var _text:String;
 
		public function OptimizeXMLString( $text:String = null )
		{
			this._text = $text;
		}
 
		public function addReplace( $string:String, $replaced:String ):void
		{
			_arrStringList.push( $string );
			_arrReplacedList.push( $replaced );
		}
 
		public function optimizing( $text:String = null ):String
		{
			var str:String = getText( $text );
 
			var len:uint = _arrStringList.length;
			for ( var i:uint = 0; i < len; ++i )
			{
				str = replaceString( str, _arrStringList[ i ], _arrReplacedList[ i ] )
			}
			return str;
		}
 
		private function getText( $text:String ):String
		{
			var str:String;
 
			if ( $text )
				str = _text = $text;
 
			else if ( _text )
				str = _text;
 
			else
				str = "";
 
			return str;
		}
 
 
		public function get stringList():Array { return _arrStringList; }
 
		public function get replacedList():Array { return _arrReplacedList; }
 
		public function get text():String { return _text; }
 
		public function set text( $value:String ):void 
		{
			_text = $value;
		}
	}
}

이렇게 기본적으로 위에서 열거한 세 가지의 단골 문자열을 배열로 기본 입력해 놓고, replace 가 필요한 문자열이 더 있다면 추가해서 사용하는 방식으로 클래스를 구성하였습니다.
실제로 이 클래스는 replace 를 할 문자열을 추가, 관리, 조회 하는 내용만 존재하고, 실제로 문자열을 바꿔주는 기능은 이전 포스트에서 소개해 드린 replaceString 파일에서 수행합니다.^[02]

OptimizeXMLString 를 이용해서 여러가지 형태로 사용하는 방법을 아래의 호스트코드에서 보시죠.

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 kr.ufx.utils.OptimizeXMLString;
 
var str:String = "세계의끝 %26 플래시 %26 원더랜드";
trace( str );
// 출력 : 세계의끝 %26 플래시 %26 원더랜드
 
// 생성자에서 변환할 text 대입
var optimizer:OptimizeXMLString = new OptimizeXMLString( str );
trace( optimizer.optimizing() );
// 출력 : 세계의끝 & 플래시 & 원더랜드
 
// optimizing 메서드에 직접 text 를 대입하여 변경
trace( optimizer.optimizing( "2001 %26 스페이스 %26 오딧세이" ) );
// 출력 : 2001 & 스페이스 & 오딧세이
 
// getter 메서드를 이용해 text 대입 ( text 내용 변경 )
optimizer.text = "시계태엽 %26 오렌지";
trace( optimizer.optimizing() );
// 출력 : 시계태엽 & 오렌지
 
// 변환할 단어를 추가
optimizer.addReplace( "오렌지", "어린쥐" );
trace( optimizer.optimizing() );
// 출력 : 시계태엽 & 어린쥐

  OptimizeXMLString class

이렇게 해서 String 클래스의 replace() 가 API 차원에서 학습 된 후, 재사용이 가능한 *.as 파일 로 만들어지고 (또는 클래스 파일로 만들어지고), 그것이 다시 확장되어 다른 클래스에서 활용되는 과정( 이 포스트 ) 을 모두 살펴보았습니다.

1. xml 뿐만 아니라 html, php, jsp 등 서버사이드쪽에서 사용되는 텍스트 문서 전체에 해당되기도 하죠.
2. OptimizeXMLString 클래스 상단에 kr.ufx.text.replaceString 파일이 import 된 것을 확인할 수 있습니다.

코딩하다보면 문자열에 replace() 를 사용해야 할 경우가 많이 있죠. split 과 join 을 사용해 문자열을 바꾸는 방법은 AS2.0 때부터 사용해 오던 방법으로 널리 알려져 있습니다. 그렇지만 AS3.0가 나온 이후로는 훨씬 세련된 문자열 치환 방법인 String 클래스에 replace()메서드를 사용하지 않을 이유가 없죠.

많은 개발자들이 자신만의 문자열 replace 함수를 만들어 사용하거나, 또는 replace 는 간단한 함수이므로 따로 클래스를 만들지 않고 그때그때 코딩해서 사용하기도 합니다.
저의 경우에는 워낙에 사용 빈도가 빈번한 함수라 재사용에 최적화 할 필요가 느껴졌는데요, 저는 이런 방법을 사용했습니다.

0
1
2
3
4
5
6
7

//replaceString.as 파일의 내용
package kr.ufx.text
{
	public function replaceString( $text:String, $string:String, $replacedString:String, $option:String = "g" ):String
	{
		return $text.replace( new RegExp( $string, $option ), $replacedString );
	}
}

이 replaceString.as 파일은 클래스가 아니라 replaceString() 함수만 존재하는 파일 입니다.^[01]
저는 replaceString() 함수를 kr.ufx.text 패키지 레벨로 빼냈는데요, 이것은 replace() 정도의 간단한 작업을 하기 위해 클래스 객체를 만들필요 없이 곧바로 호출해서 사용하기 위함입니다.
즉, 사용방법은 아래와 같습니다.

0
1
2
3
4

import kr.ufx.text.replaceString;
 
var str:String = "세계의끝과 하드보일드 원더랜드";
str = replaceString( str, "하드보일드", "플래시" );
trace( str ); // 출력: 세계의끝과 플래시 원더랜드

그리고 RegExp 의 option 을 “g” (global) 로 기본값 설정하였기 때문에 while 을 사용할 필요 없이, 모든 문자열을 한번에 치환해줍니다.^[02]

이렇게 해서 String 클래스의 replace() 가 API 차원에서 학습 된 후, 재사용이 가능한 형태의 *.as 파일로 만들었습니다.(이 포스트)
다시 이 기능을 확장하여 구체적인 기능을 가진 다른 클래스로 활용되는 과정을 xml 작업에 최적화된 문자열 바꾸기 String replace 클래스 에서 살펴보세요.

1. 이 파일에는 클래스 키워드 class 의 클래스 정의나 생성자 함수가 존재하지 않습니다
2. 이 option 에 대해서 더 자세한 정보는 http://help.adobe.com/ko_KR/AS3LCR/Flash_10.0/RegExp.html#RegExp() 를 참고하세요.

이런 것은 optical(시각적인) iterator pattern 이라 할 수 있겠죠.

9장의 내용은 이터레이터 패턴과 컴포지트 패턴을 식당 통합 메뉴를 구현하는 연속되는 내용으로 설명하고 있는데요, 이 한 개 챕터의 페이지가 다른 부분보다 훨씬 많은 70페이지인데다가 설명해야 하는 부분도 많고 코드도 복잡하기 때문에 이터레이터와 컴포지트를 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
36
37

package 
{
	public class MenuItem
	{
		private var name:String;
		private var description:String;
		private var vegetarian:Boolean;
		private var price:uint;
 
		public function MenuItem( $name:String, $description:String, $vegetarian:Boolean, $price:uint )
		{
			this.name = $name;
			this.description = $description;
			this.vegetarian = $vegetarian;
			this.price = $price;
		}
 
		public function getName():String
		{
			return name;
		}
 
		public function getDescription():String
		{
			return description;
		}
 
		public function getPrice():uint
		{
			return price;
		}
 
		public function isVegetarian():Boolean
		{
			return vegetarian;
		}
	}
}

특별히 어려운 부분은 없는것 같습니다. 메뉴 이름, 메뉴 설명, 채식주의자용 메뉴여부, 가격의 네 가지 변수를 가져오는 getter 메서드 들이 있고, 생성자에서 객체를 만들면서 해당 변수에 대입합니다.

양쪽의 식당은 이 메뉴구현에 맞추어 각자의 메뉴를 입력하면 됩니다만 기존에 사용하던 메뉴 구조가 서로 다릅니다. 먼저 짚고 넘어갈 부분은 책 본문에서는 양쪽의 형식이 다르다는 것을 표현하기 위해 자바의 ArrayList 와 Array 를 사용했지만, 액션스크립트에 ArrayList 는 없기 때문에 이번에 FlashPlayer 10에서 지원하게 된 Vector 로 바꿔서 코드를 번역하였습니다. 또한 원래 DinerHouse 의 메뉴가 배열원소의 갯수를 제한한 Array 였기 때문에^[01] DinerHouse 의 Array 를 원소 갯수를 제한할 수 있는 Vector 로 바꾸고, PancakeHouse 의 ArrayList 를 Array 로 구현하였습니다.

그럼 PancakeHouse 의 메뉴를 먼저 보겠습니다.

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 
{
	public class PancakeHouseMenu implements IMenu
	{
		private var menuItems:Array;
 
		public function PancakeHouseMenu () 
		{
			menuItems = new Array()
 
			addItem( "K&B 팬케이크 세트", "스크램블드 에그와 토스트가 곁들여진 팬케이크", true, 2990 )
			addItem( "레귤러 팬케이크 세트", "달걀 후라이와 소시지가 곁들여진 팬케이크", false, 2990 )
			addItem( "블루베리 팬케이크", "신선한 블루베리와 블루베리 시럽으로 만든 팬케이크", true, 3490 )
			addItem( "와플", "와플, 취향에 따라 블루베리나 딸기를 얹을 수 있습니다.", true, 3590 )
		}
 
		public function addItem( $name:String, $description:String, $vegetarian:Boolean, $price:uint ):void
		{
			var menuItem:MenuItem = new MenuItem( $name, $description, $vegetarian, $price )
			menuItems.push(menuItem);
		}
 
		/*
		 * 이터레이터 패턴 구현으로 사용하지 않게된 메서드
		public function getMenuItems():MenuItem
		{
			return menuItems;
		}
		*/
		public function createIterator():IIterator
		{
			return new PancakeHouseIterator( menuItems )
		}
 
		//기타 메뉴관련 메서드
	}
}

위에서 언급한대로 Array 를 이용하여 메뉴를 구현하고 있습니다.

그럼 DinerHouse 의 메뉴구현은 어떤가요?

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

package 
{
	public class DinerMenu implements IMenu
	{
		private static const MAX_ITEM:uint = 6;
		private var numberOfItems:uint = 0;
		private var menuItems:Vector.<MenuItem>;
 
		public function DinerMenu () 
		{
			menuItems = new Vector.<MenuItem>( MAX_ITEM, true )
 
			addItem( "채식주의자용 BLT", "통밀 위에 (식물성)베이컨, 상추, 토마토를 얹은 메뉴", true, 2990 )
			addItem( "BLT", "통밀 위에 베이컨, 상추, 토마토를 얹은 메뉴", false, 2990 )
			addItem( "오늘의 스프", "감자 샐러드를 곁들인 오늘의 스프", false, 3290 )
			addItem( "핫도그", "사워크라우트, 갖은 양념, 양파, 치즈가 곁들여진 핫도그", false, 3050 )
		}
 
		public function addItem( $name:String, $description:String, $vegetarian:Boolean, $price:uint ):void
		{
			var menuItem:MenuItem = new MenuItem( $name, $description, $vegetarian, $price )
			if ( numberOfItems >= MAX_ITEM )
			{
				trace( "죄송합니다, 메뉴가 꽉 찼습니다. 더 이상 추가할 수 없습니다." )
			}
			else
			{
				menuItems[numberOfItems] = menuItem;
				numberOfItems++
			}
		}
 
		/*
		 * 이터레이터 패턴 구현으로 사용하지 않게된 메서드
		public function getMenuItems():MenuItem
		{
			return menuItems;
		}
		*/
		public function createIterator():IIterator
		{
			return new DinerMenuIterator( menuItems )
		}
 
		//기타 메뉴관련 메서드
	}
}

팬케익하우스보다 약간 복잡하지만 Vector 를 사용했기 때문에 전체 메뉴의 갯수가 6개로 제한되어 있다는것 외에는 딱히 다른점은 없습니다.

그럼 이제 이터레이터 인터페이스를 보겠습니다.

0
1
2
3
4
5
6
7

package 
{
	public interface IIterator
	{
		function hasNext():Boolean;
		function next():Object;
	}
}

다음 수행할 항목이 있는지 알아보는 hasNext() 메서드와 다음 항목을 리턴해주는 next()메서드가 있습니다.

팬케익하우스 이터레이터가 위의 인터페이스를 어떻게 구현했나 살펴볼까요?

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 
{
	public class PancakeHouseIterator implements IIterator
	{
		private var items:Array;
		private var position:int = 0;
 
		//생성자에서는 메뉴에서 넘어온 모든 메뉴를 한꺼번에 받음
		public function PancakeHouseIterator ( $items:Array )
		{
			this.items = $items;
		}
 
		//다음 메뉴 배열원소를 리턴
		public function next():Object
		{
			var memuItem:MenuItem = items[position];
			position++;
			return memuItem;
		}
 
		//다음 메뉴가 있는지 확인하고 Boolean을 리턴
		public function hasNext():Boolean
		{
			if ( position >= items.length )
			{
				return false;
			}
			else
			{
				return true;
			}
		}
	}
}

다음은 디너하우스의 이터레이터 입니다. MenuItem 을 Vector 에 저장하고 있습니다.

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 
{
	public class DinerMenuIterator implements IIterator
	{
		private var items:Vector.<MenuItem>;
		private var position:int = 0;
 
		public function DinerMenuIterator ( $items:Vector.<MenuItem> )
		{
			this.items = $items;
		}
 
		public function next():Object
		{
			var memuItem:MenuItem = items[position];
			position++;
			return memuItem;
		}
 
		public function hasNext():Boolean
		{
			//Vector 의 경우 원소가 없는 것은 null 이기 때문에 null 도 검사
			if ( position >= items.length || items[position] == null )
			{
				return false;
			}
			else
			{
				return true;
			}
		}
	}
}

그럼 실제 메뉴를 찍어줄 웨이트리스를 만나보겠습니다.

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 
{
	public class Waitress
	{
		private var pancakeHouseMenu:IMenu;
		private var dinerMenu:IMenu;
 
		//웨이트리스는 생성자에서 양쪽 식당의 메뉴를 받아 변수에 저장
		public function Waitress( $pancakeHouseMenu:IMenu, $dinerMenu:IMenu ) 
		{
			this.pancakeHouseMenu = $pancakeHouseMenu;
			this.dinerMenu = $dinerMenu;
		}
 
		//이터레이터 객체를 준비
		public function printMenu():void
		{
			var pancakeIterator:IIterator = pancakeHouseMenu.createIterator();
			var dinerIterator:IIterator = dinerMenu.createIterator();
			trace( "\n메뉴n----\n아침메뉴" );
			printItMenu( pancakeIterator );
			trace( "\n메뉴n----\n점심메뉴" );
			printItMenu( dinerIterator );
		}
 
		//실제 개별 메뉴를 찍어줌
		private function printItMenu( $iterator:IIterator ):void
		{
			while ( $iterator.hasNext() )
			{
				var menuItem:MenuItem = MenuItem( $iterator.next() );
				trace( menuItem.getName(), ", ", menuItem.getPrice(), "--", menuItem.getDescription() );
			}
		}
	}
}

웨이트리스 코드에서는 각메뉴의 createIterator() 를 호출하여 이터레이터 객체를 얻고 MenuItem 의 갯수만큼 반복하여 메뉴를 얻습니다.

호스트코드에서는 웨이트리스 객체를 만들어 팬케익하우스와 디너하우스의 메뉴를 인자로 던져 모든 메뉴를 출력합니다.

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

package 
{
	import flash.display.Sprite;
 
	public class Main extends Sprite 
	{
		public function Main():void 
		{
			var pancakeHouseMenu:PancakeHouseMenu = new PancakeHouseMenu();
			var dinerMenu:DinerMenu = new DinerMenu();
 
			var waitress:Waitress = new Waitress( pancakeHouseMenu, dinerMenu );
			waitress.printMenu();
		}
	}
}

출력된 모든 메뉴 입니다.

메뉴
—-
아침메뉴
K&B 팬케이크 세트 , 2990 — 스크램블드 에그와 토스트가 곁들여진 팬케이크
레귤러 팬케이크 세트 , 2990 — 달걀 후라이와 소시지가 곁들여진 팬케이크
블루베리 팬케이크 , 3490 — 신선한 블루베리와 블루베리 시럽으로 만든 팬케이크
와플 , 3590 — 와플, 취향에 따라 블루베리나 딸기를 얹을 수 있습니다.

메뉴
—-
점심메뉴
채식주의자용 BLT , 2990 — 통밀 위에 (식물성)베이컨, 상추, 토마토를 얹은 메뉴
BLT , 2990 — 통밀 위에 베이컨, 상추, 토마토를 얹은 메뉴
오늘의 스프 , 3290 — 감자 샐러드를 곁들인 오늘의 스프
핫도그 , 3050 — 사워크라우트, 갖은 양념, 양파, 치즈가 곁들여진 핫도그

일견 왜 이렇게 복잡하게 반복을 수행해야하나 하는 생각이 들 수 있겠습니다. 책의 359페이지에 따르면 메뉴 항목을 구현하는 방식의 차이^[02] 때문에 항상 다른형식 메뉴판 숫자만큼의 for 문이 필요하게 되고, 웨이트리스가 채식주의자용 메뉴만 출력하는 메서드를 구현해야한다면 다른 메서드에서 계속 반복적인 코드를 추가해야 하고, 게다가 구현방식이 다른 다른 식당 메뉴를 더 구현해야 한다면 또다시 모든 메서드에 반복문을 하나씩 더 추가해야 하는데, 이터레이터 패턴으로 구조를 잘 짜 놓으면 이러한 경우에 생길 수 있는 에러를 미연에 방지하고 유지보수성도 좋아지게 되는 것입니다.

그러나 이터레이터는 이러한 상이한 형식을 통합하여 반복시키는것 이상의 훨씬 추상적인 작업도 수행할 수 있습니다. 이터레이터 패턴을 자유자재로 구현하게 되면 반복이 될 것 같지 않은 요소들을 반복시킬 수 있는 길이 열리게 되는 것이죠. 이터레이터 패턴을 다루는 다른 글을 포스팅 하게 되면 이 패턴을 사용하는 진짜 이유에 대해서도 살펴보도록 하겠습니다.

  Iterator Pattern Example 액션스크립트 코드 다운로드 -
이 샘플코드는 Vector 클래스를 사용했기 때문에 Flash Player 10 으로 컴파일 해야 합니다.

2009년 5월 27일 초안 작성 / 2009 11월 24일 약간 수정하여 출판

1. 액션스크립트랑은 약간 다릅니다.
2. Array 와 Vector

그렇다면 기술적으로 이런것이 가능하게 하는 요인은 무엇인가요? 소스코드가 프로그래밍 되고 패키지화 되어 날짜 제한을 걸 수 있고, 일반인들은 그것을 해제할 수 없도록 컴파일 되어있기 때문이라 할 수 있겠습니다.
swf 파일도 위와 같은 특성을 모두 가지고 있으므로, 플래시 개발자들도 산출물(아주 구체적으로는 swf 가 되겠습니다.)에서 이와 같은 장치를 사용할 수 가 있습니다.

프리랜서로 일을 하다 보면, 간혹 이런 경우가 있죠. 작업은 완료 되었고, 내가 만든 플래시 애플리케이션이 서비스되고 있는데, 아직 잔금은 지불받지 못한 경우 !
보통 작업 종료는 작업 일정에 맞춰 빠듯하게 진행되는 반면, 지불이 되려면 결재를 받아 일정 선까지(중소규모 회사의 경우 보통은 사장 까지) 올라갔다가 다시 지불계통으로 내려가 (즉시 입금해주는 것도 아니고 며칠에 한번씩 다른 처리 건들과 함께 몰아서) 처리해 주기 때문인데요, 이런 경우 아무리 빨라도 지불기간은 1~2주일 걸리게 마련입니다.
그래서 프로젝트 진행중에는 회사측에서 아쉬운 반면(플래시 개발자는 숫자가 많지 않으므로), 프로젝트가 일단락 된 상태는 프리랜서가 아쉬운 소리를 해야하는 입장에 놓이게 됩니다.

보통, 개념이 상식의 사정거리 내에 위치한 회사들은 아무리 늦어도 월말에는 지급을 해줍니다만, 간혹 프로젝트 후의 프리랜서 보수를 지급해주는 것을 중요하게 생각하지 않는 회사들도 있어서, 매우 스트레스를 받곤 합니다.

그래서 만들었습니다.

날짜제한 평가판 클래스

이 클래스는 다음과 같은 특성을 가지고 있습니다.

1. 컴파일 하는 시점에서 특정 날짜를 지정하여 작동하도록 할 수 있고,
2. 디자인을 fla 에서 변경해서 사용할 수 있고, (fla 의 EvaluationCopyGraphic 무비클립 디자인을 수정)
3. 평가판 이미지에 url 을 지정하여 클릭하면 이동시킬 수 있습니다. (선택사항)

사용법은, 도큐먼트 클래스 또는 ui 를 담당하는 클래스 DisplayObject의 가장 상위에 위치할 수 있도록 아래와 같이 객체 생성과 addChild() 해 주기만 하면 끝.

0
1

var ec:EvaluationCopy = new EvaluationCopy( 2009, 11, 1, 9, "http://www.ufx.kr/blog" )
addChild( ec );

지금 글을 읽고 계시는 시점은 2009년 11월 1일 9시 이후이므로, pc 의 시계가 엉뚱한 날짜에 설정되어 있지 않은 대부분의 여러분들 화면에 Evaluation Copy 라는 Sprite 가 나타나 있습니다. 이게 제대로 작동한 것인지 확인해보기 위해서 운영체제의 시간을 위의 시간 이전으로 바꿔 놓고 현재 페이지를 새로 고침 하면 Sprite 가 보이지 않는 것을 확인할 수 있습니다.
매우 간단하지만 확실한 기능을 하죠.
Sprite 의 크기를 좀더 크게 화면을 거의 다 덮고 싶다던가, 아니면 좀더 눈에 거슬리지 않게 디자인을 변경하고 싶다면 fla 에서 디자인을 변경한 후, 컴파일 또는 테스트 무비를 한번 해 주면, 다음번 이 클래스를 포함하여 다른 애플리케이션을 컴파일 할 때에는 변경된 디자인이 적용됩니다.

이렇게 서비스 런칭 시점에는 평가판 기능이 활성화 된 버전의 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
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 kr.ufx.app.evaluation
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.net.URLRequest;
	import flash.net.navigateToURL;
 
	/**
	 * ...
	 * @author Won, Jong-sun (cuebrick) http://ufx.kr/blog
	 */
 
	[ Embed ( source = "EvaluationCopy_graphic_asset.swf", symbol = "EvaluationCopyGraphic" ) ]
 
	public class EvaluationCopy extends Sprite
	{
		public var bg:Sprite;
		private var expireDate:Date;
		private var nowDate:Date;
		private var _request:URLRequest = new URLRequest();
 
		public function EvaluationCopy( $year:uint, $month:uint, $day:uint, $hour:uint, $returnUrl:String = null, $x:Number = 10, $y:Number = 10 )
		{
			expireDate = new Date( $year, $month - 1, $day, $hour );// note!! : month = 0 --> January
			nowDate = new Date();
			this.visible = false;
			this.x = $x;
			this.y = $y;
 
			if ( expireDate < nowDate ) init( $returnUrl );
		}
 
		private function init( $returnUrl:String ):void
		{
			this.visible = true;
			if ( $returnUrl != null ) initClickSetting( $returnUrl );
		}
 
		private function initClickSetting( $returnUrl:String ):void
		{
			_request.url = $returnUrl;
			bg.buttonMode = true;
			bg.addEventListener( MouseEvent.CLICK, clickHandler );
		}
 
		private function clickHandler( $e:MouseEvent ):void
		{
			navigateToURL( _request );
		}
	}
}

Date 클래스의 달을 표시하는 숫자는 0이 January (1월), 11이 December(12월)을 나타내므로 좀더 직관적으로 사용하기 위해서 객체 생성 시점에서 날짜를 지정할때는 우리가 보통 사용하는 달로 숫자를 입력하고 생성자에서 – 1 을 해 주었습니다.

–

클래스를 사용하는데 한가지 주의할 점이 있습니다. 이런 평가판 기능을 사용할 예정이라는 것을 프로젝트 초반 또는 계약 시점에 담당자에게 알리는 것이 좋습니다. 우리의 목적은 회사를 골탕먹이는데 있는 것이 아니라 정당한 보수를 제때 받기 위함이니까요.
제한 날짜도 회사쪽의 담당자와 상의한 후 여유있게 잡는 것이 좋습니다.
만약 서비스가 중단되면 매우 곤란한 대규모 웹사이트에 사용될 경우 이 평가판 기능이 발동된다면 회사측에 미리 알리지 않은 이런 장치는 법적인 문제를 야기할 가능성이 크고, 그런 경우 사안이 크면 클수록, 상대방 회사의 규모가 크면 클수록, 잔금을 못받은것 과는 별건으로 서비스 중단등으로 입은 손해배상 청구등이 들어 올 수 있습니다.
즉, “내가 잔금을 못받았으니 서비스는 중단되도 무방하다” 일리가 없다는 것이죠. 잘 생각해 보시면 금방 답이 나올겁니다. 게다가 나중에 잔금을 받은 이후 평가판 기능을 제거한 swf 을 건넬때 어차피 담당자가 알게 될 가능성이 높은데, 그 시점에서 담당자가 비로소 사실을 알게 되면 발주한 회사와 프리랜서와의 관계가 좋게 유지되기가 힘들겠죠.

–

어쨌건 이런 사소한 아이디어로 프리랜서나 사이드잡으로 일을 해주고 돈을 못받아 속을 썩히는 일이 조금이나마 줄어들까 해서 포스팅 해보았습니다.

위의 코드가 액션스크립트의 전체 코드지만, fla, swf 파일이 포함되어 있는 전체 파일을 아래의 링크에서 받을 수 있습니다.

  EvaluationCopy

오늘 포스팅하게 될 내용도 그런 신기한 것 중 하나로, 커맨드 패턴을 이용한 작업취소(언두: undo) 또는 작업내역(history) 기능 구현 입니다.
헤드퍼스트 디자인 패턴에 있는 디자인 패턴 부분의 내용을 기본으로 이해하기 좋도록 시각적인 구성을 추가했고, 중요한 기능 중 하나를 추가해 보았습니다.

undo 나 history 기능 자체는 디자인 패턴이 아닙니다. 이 기능은 커맨드 패턴을 구현하다 보면 서비스로 딸려오는 (자연스럽게 구성할 수 있는) 기능 정도로 이해하는 것이 좋습니다.

먼저 최종 결과 파일부터 볼까요?

위의 컴파일 결과물에서 왼쪽은 리모컨 입니다. 각 숫자는 선풍기의 회전수를 나타내는 회전 강도가 되겠고요, 아래쪽에 undo, redo 버튼, 그리고 현재 history 내역이 무엇인지 볼 수 있는 view history 버튼도 만들어져 있습니다.
각각의 버튼을 눌러보세요.

패턴과는 관계 없지만, 화면에서 보이는 선풍기는 정확하게 표현하자면 실링팬 입니다. 더운 지방이 나오는 영화를 보면 천정에서 천천히 돌아가는 선풍기가 바로 이것이죠. 영어 단어로는 ceiling fan 이라 하는데, 직역하자면 천정 선풍기라는 의미가 되겠습니다.
한편 ceil 이라는 단어는 Math 클래스 에서도 볼 수 있죠. Math.ceil( 1.3 ) 의 결과는 소수점 올림이 적용되어 2 가 나오게 되겠죠? 이때 ceil 이라는 의미가 ‘천정’ 또는 ‘올림’ 이라면, floor 는 ‘바닥’ 또는 ‘내림’ 이라는 상대적인 의미로 Math.floor() 에서도 사용됩니다.

ICommand 인터페이스는 이전 커맨드 패턴을 다룬 예제와 전혀 다르지 않습니다.

0
1
2
3
4
5
6

package 
{
	public interface ICommand
	{
		function execute():void
	}
}

아래는 선풍기를 off 한 상태의 커맨드 클래스 입니다. 이렇게 선풍기의 속도를 커맨드 클래스로 만든 클래스가 속도별로 3개가 더 있습니다. (전체 코드는 하단에 다운로드 링크가 있습니다)

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

package 
{
	public class CeilingFanOffCommand implements ICommand
	{
		private var ceilingFan:CeilingFan;
 
		public function CeilingFanOffCommand( $ceilingFan:CeilingFan ) 
		{
			this.ceilingFan = $ceilingFan
		}
 
		public function execute():void
		{
			ceilingFan.off();
		}
	}
}

CeilingFan 클래스는 아래와 같습니다. 4가지 속도에 해당하는 메서드를 public 으로 제공하고 있고, 메서드가 실행되면 speed 라는 이름의 변수에 저장하고 있습니다.

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

package 
{
	import flash.display.Sprite;
	import flash.events.*;
 
	public class CeilingFan extends Sprite
	{
		private var location:String = "";
		private var speed:int;
		public static const HIGH:int = 3;
		public static const MEDIUM:int = 2;
		public static const LOW:int = 1;
		public static const OFF:int = 0;
 
		public function CeilingFan( $location:String ):void
		{
			this.fan.cacheAsBitmap = true;
			this.location = $location;
			this.speed = OFF;
			this.addEventListener( Event.ENTER_FRAME, onEnterFrameHandler );
		}
 
		public function high():void
		{
			speed = HIGH;
			outputText();
		}
		public function medium():void
		{
			speed = MEDIUM;
			outputText();
		}
		public function low():void
		{
			speed = LOW;
			outputText();
		}
		public function off():void
		{
			speed = OFF;
			outputText();
		}
		public function getSpeed():int
		{
			return speed;
		}
		private function outputText():void
		{
			txtSpeed.text = location + " : Fan Speed - " + speed;
		}
		private function onEnterFrameHandler( e:Event ):void 
		{
			this.fan.rotation += speed;
		}
	}
}

화면에 있는 선풍기의 날개를 속도에 맞게 회전시킬 것이므로 Event.ENTER_FRAME 을 이용해 fla 의 스테이지에 정의 되어 있는 fan 무비클립을 계속 갱신시키고 있습니다. 가장 아래쪽에 있는 onEnterFrameHandler() 메서드에 있는 fan 의 회전속도는 변수 speed 의 숫자값에 따라 달라지겠죠. speed 가 바뀌는 즉시 fan 의 회전속도도 바뀌게 될 것입니다.

그럼 이제 리모컨 클래스를 살펴볼 차례군요.

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
135
136
137
138
139
140
141

package 
{
	import fl.controls.Button;
	import flash.display.Sprite;
	import flash.events.*;
	import flash.text.*;
 
	public class RemoteControlWithHistory extends Sprite 
	{
		private var arrCommands:Array = new Array();;
		private var commandHistory:Array = new Array();
		private var historyIndex:int;
		private var txtHistory:TextField = new TextField();
 
		public function RemoteControlWithHistory( $ceilingFan:CeilingFan, $numberOfbuttons:uint = 4 )
		{
			var noCommand:ICommand = new NoCommand();
			for ( var i:int = 0; i < $numberOfbuttons; i++ )
			{
				arrCommands[ i ] = noCommand;
			}
 
			var ceilingFanHigh:CeilingFanHighCommand = new CeilingFanHighCommand( $ceilingFan );
			var ceilingFanMedium:CeilingFanMediumCommand = new CeilingFanMediumCommand( $ceilingFan );
			var ceilingFanLow:CeilingFanLowCommand = new CeilingFanLowCommand( $ceilingFan );
			var ceilingFanOff:CeilingFanOffCommand = new CeilingFanOffCommand( $ceilingFan );
 
			setCommand( 0, ceilingFanOff );
			setCommand( 1, ceilingFanLow );
			setCommand( 2, ceilingFanMedium );
			setCommand( 3, ceilingFanHigh );
 
			init( $numberOfbuttons );
		}
 
		private function init( $numberOfbuttons:uint ):void
		{
			this.x = this.y = 10;
 
			for ( var i:uint = 0; i < $numberOfbuttons; i++ )
			{
				var button:Button = new Button();
				button.addEventListener( MouseEvent.CLICK, buttonWasPushed );
				button.label = i.toString();
				button.height = 30;
				button.y = i * ( button.height + 5 );
				addChild( button );
			}
 
			var undoButton:Button = new Button();
			var redoButton:Button = new Button();
			var historylistButton:Button = new Button()
			undoButton.y = 200;
			redoButton.y = 230;
			historylistButton.y = 260;
			undoButton.label = "undo";
			redoButton.label = "redo";
			historylistButton.label = "view history";
 
			undoButton.addEventListener( MouseEvent.CLICK, undoButtonWasPushed )
			redoButton.addEventListener( MouseEvent.CLICK, redoButtonWasPushed )
			historylistButton.addEventListener( MouseEvent.CLICK, historyView );
 
			addChild( undoButton );
			addChild( redoButton );
			addChild( historylistButton );
 
			txtHistory.width = 300;
			txtHistory.height = 300;
			txtHistory.x = historylistButton.width;
			txtHistory.y = historylistButton.y;
			addChild( txtHistory );
 
			//선풍기의 초기값은 정지상태
			this.buttonWasPushed( null );
		}
 
		public function setCommand( $slot:int, $command:ICommand ):void
		{
			arrCommands[ $slot ] = $command;
		}
 
		public function buttonWasPushed( $e:MouseEvent = null ):void
		{
			var slot:uint = ( $e == null ) ? 0 : uint( $e.target.label );
			arrCommands[ slot ].execute();
			stackProcess( arrCommands[ slot ] );
		}
 
		private function stackProcess( $command:ICommand ):void
		{
			//historyIndex가 undo 중일때 undo나 redo가 아닌 새로운 command가 들어올경우 redo 부분이 없어지도록 배열길이를 조정
			commandHistory.length = historyIndex;
			commandHistory.push( $command );
			historyIndex = commandHistory.length;
		}
 
		public function undoButtonWasPushed( $e:MouseEvent = null ):void
		{
			if ( historyIndex > 1 )
			{
				commandHistory[ ( --historyIndex - 1 ) ].execute();
			}
			else
			{
				trace( "No more Undo" )
			}
		}
 
		public function redoButtonWasPushed( $e:MouseEvent = null ):void
		{
			if ( historyIndex < commandHistory.length )
			{
				commandHistory[ historyIndex++ ].execute();
			}
			else
			{
				trace( "No more Redo" )
			}
		}
 
		public function getCommandList():String
		{
			var str:String = "\n------ Remote Control -------"
			for ( var i:int = 0; i < arrCommands.length; i++)
			{
				str += "\n[slot " + i + "] " + arrCommands[i] 
			}
			str += "\n[undo] " + commandHistory
			return str
		}
 
		private function historyView( e:MouseEvent ):void 
		{
			txtHistory.text = "******History list******"
			for each( var element:Object in commandHistory )
			{
				txtHistory.appendText( ( "\n" + element.toString() ) );
			}
		}
	}
}

클래스가 좀 길군요. 하지만 대부분 생성자 함수와 init() 메서드의 초기화 내용들이므로 지나쳐도 무방하고, 실제 커맨드 패턴을 구현한 내용은 setCommand() 메서드 부터 입니다. 이전 두 개의 커맨드 패턴 관련 포스팅을 읽으신 분들은 이 메서드가 리모컨의 각 버튼에^[02] 커맨드 객체를 저장해 주는 역할을 한다는 것을 알고 계실겁니다.

setCommand() 메서드 아래에 있는 buttonWasPushed() 메서드 에서는 각 속도가 할당된 버튼을 클릭하면 커맨드 객체를 통해 CeilingFan 객체에 각 속도에 해당하는 메서드를 실행하게 됩니다. 추가로 stackProcess() 메서드를 실행시키고 있는데, stackProcess() 에서는 history undo 기능을 수행할때 필연적으로 만나게 되는 문제에 대한 해결 방법을 제시하고 있습니다.

history undo 실행 중에 만나는 새로운 커맨드에 대한 처리

stackProcess() 메서드가 실행되면 인자로 받은 커맨드 객체를 commandHistory 배열에 넣는 기본 기능을 수행하면서 마지막 라인에서 commandHistory 의 배열 길이를 historyIndex 라는 별도의 변수에 저장합니다. 배열 길이는 언제든 참조가 가능한데 왜 이렇게 하는 것일까요?
stackProcess() 가 그렇게 한번 실행된 후, 두 번째 실행되면 그 이유를 알 수 있습니다.

stackProcess() 메서드의 첫 번째 라인을 보면 commandHistory 의 배열 길이를 강제로 historyIndex 로 맞줘주는 내용이 보입니다. 커맨드 객체가 계속 새로운 커맨드로 진행되는 경우라면 commandHistory.length 와 historyIndex 의 길이는 같을 것이므로^[03] 이 코드는 실행되는 듯 마는 듯 지나치게 됩니다만, 만약 현재 상태가 undo 상태라면 이야기는 달라집니다.

이 문제는 모든 history undo 기능이 가지고 있는 공통의 문제라 할 수 있겠는데요, 사용자가 A, B, C, D 의 커맨드를 순서대로 실행하다가 undo 를 두번 했다면 현재는 B가 실행되고 있겠죠? 여기서 사용자가 고맙게도 redo 를 다시 두번 실행해 준다면 좋겠지만, 사용자가 어디 그런가요? 현재 B가 실행되고 있는 상황에서 C을 건너뛰고 D를 선택하는 상황이 발생하게 됩니다.

만약 stackProcess() 에서 push() 만 하는 경우라면 어떻게 될까요? undo 상태의 B위치에서 누른 새로운 D는 commandHistory의 5번째 원소가 될테죠.
commandHistory 를 나열해보면 이렇게 되어있겠네요. [ A, B, C, D, D ].
이것은 우리가 바라는게 아니라는것을 알 수 있습니다. undo 상태에서 redo 가 아닌 새로운 커맨드가 들어올 때, history 를 저장하고 있는 배열에서 redo 가 될 부분은 모두 버리고 새로운 커맨드를 쌓아나가야 하는 것이죠.
그래서 우리가 의도한 [ A, B, D ] 가 되도록 하기 위해서 commandHistory.push( $command ) 를 하기 직전에, 별도로 저장한 historyIndex 로 배열의 길이를 조절해 주는 것입니다.

—

stackProcess() 메서드 아래에는 undoButtonWasPushed() 메서드와 redoButtonWasPushed() 메서드가 있어서 undo나 redo 버튼이 눌렸을때에는 새로운 커맨드를 실행하는 것이 아니라 commandHistory 배열에서 앞뒤로 인덱스를 움직이며 커맨드를 실행해 줍니다.

마지막으로 호스트코드를 살펴보겠습니다. 이쪽은 뭐 간단합니다.
선풍기와 리모컨 객체를 하나씩 만들어 addChild 했을 뿐이네요.

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

package 
{
	import flash.display.Sprite;
 
	public class Main extends Sprite 
	{
		public function Main():void 
		{
			var ceilingFan:CeilingFan = new CeilingFan( "Living Room" )
			ceilingFan.x = 400;
			ceilingFan.y = 200;
			addChild( ceilingFan );
 
			var remoteControl:RemoteControlWithHistory = new RemoteControlWithHistory( ceilingFan, 4 );
			addChild( remoteControl );
 
		}
	}
}

이 예제는 fla 에 있는 이미지 자원을 사용하기 때문에 컴파일도 fla 에서 합니다. 화면에서 모든것을 표현하고 있기 때문에 trace() 대신 화면을 관찰하면 됩니다. 현재 히스토리 현황을 알기 위해서 view history 버튼을 누르세요.

  Command Pattern ( History Undo) 액션스크립트 코드 다운로드

1. 액션스크립트로 말하자면 도큐먼트 클래스 이죠
2. 정확하게는 커맨드 슬롯을 저장하는 배열에
3. 아직 commandHistory.push( $command ) 하기 이전이므로

발등 뿐만 아니라 머리위에도 불이 떨어졌던...

이전의 포스팅이 8월 9일 이었으니까, 무려 두달 보름동안이나 아무 포스팅 없이 블로그를 방치해 두고 있었습니다.

그 동안 한가하게 낚시나 하고 있…었던건 물론 아니고, 나름 프로젝트 두 개를 마무리 짓고, 간단한 액션스크립트 개발도 사이드 잡으로 같이 해가면서 일을 계속 하고 있었죠. 문제는 일정이 너무 빠듯해서 월화수목금금금으로 계속 작업을 밀어붙이다 보니, 간간히 올라오는 댓글에 응답해드리는 정도를 할 수 있을 뿐, 포스팅은 절대 무리였습니다.

항상 이런 상황일때마다, 앞으로는 이렇게 일정을 잡지 말아야지 생각하지만, 그 때가 지나면 또 그 밤샘의 괴로움을 까마귀 고기를 먹은것 마냥 까먹고 다시 무리한 일정을 잡는 저를 보면, 오늘의 경험이 내일의 교훈이 되지 못하고 있군요.

어쨌건 그간의 작업 중, 환경부 산하 환경관리공단의 실시간 측정 시스템 웹 사이트 작업이 있는데, 이 작업중 일부를 블로그에 tutorial 또는 case study 형태로 포스팅을 해 봐도 좋겠다는 생각이 들어, 조만간 정리해 올릴 예정입니다.

그리고 글과 예제까지 거의 대부분 작성해 놓고 정리가 되지 못해 올라가지 못하고 있는 디자인 패턴 관련 포스팅도 이어지겠습니다.