Rhio.Kim's Blog - drawing Laputa Web -

Design by Design Pattern정의


모티브 :
HTML 디자인을 개발자에 의해서 동적으로 생성되도록 처리하려면 개발자에 의해서 디자인을 javascript의 정해진 변수에 넣고 프로세서에 맞춰 필요한 디자인을 Document에 렌더링을 해야합니다.  유지보수 시 디자인적인 추가 요소가 발생할 경우 개발자가 디자인을 수정하거나 편집해야 하는 일이 발생한다.

목적 및 장점 :

조건 :


제약 :

단점 :


좀더 자세한 패턴에 대한 설명은 PDF 문서에 담았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다.  또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

Javascript Optional pattern

디자인 패턴에 이미 있나? 패턴에 대한 심도 있는 연구를 해본 적이 없지만 javascript 개발을 하다 보니 자주 사용하게 되는 패턴이라 정리해봅니다.  (이미 GoF 나 POSA 에 일부분에 적용되어져 있을 수도 있습니다.)

간단하면서 이미 많은 개발자들이 이런 방식으로 개발하고 있을지 모른다고 생각한다.  외국 라이브러리 역시 이런 방식으로 개발된 라이브러리가 꾀나 있다. 거론하자니 생각이 나지 않네요. Javascript Lib 카테고리 가면 몇몇 링크가 있는데 그들 중에도 있었다.

의도 :
  하나의 클래스를 통하여 다양한 표현할 수 있다.

동기 :
  컴포넌트, 위젯 형태의 개발에 좀더 사용자 설정을 강화하여 다양한 형태의 결과를 표현하고 싶을 때, 이로 개발된 산물은 pre-config 에 대한 이해를 통해 디자이너도 쉽게 접근할 수 있도록 해보자.

sample code
//Prototype Object.extend like function extend(dest, sous) { for (var property in sous) dest[property] = sous[property]; return dest; } function foo(options) { /* private * pre-config object for this class */ var options = extend({ target: '', x: 100, y: 200, width: 300, height: 300, title: 'Optional Pattern', hook: ['click', 'mouseover'] }, options || {}); return { /* public * get pre-config object of class * @param {string} key config property name * @return {All} value */ getOption: function(key) { return (typeof key == 'string') ? options[key] : options; }, /* public * get pre-config X,Y position value * @return {Array} value */ getXY: function() { return [options['x'], options['y']]; } }; } var Foo1 = new foo(); Foo1.getXY(); //[100, 200] var Foo2 = new foo({ target:'rhio', x:300, y:300}); Foo2.getXY(); //[300, 300]

위 소스에서도 알 수 있듯이 사용자는 Hash형 Object 타입으로서 pre-config를 설정하여 해당 클래스가 new 키워드로 인스턴스화 되어질 때 해당 객체의 초기 설정값에 의해 동작한거나 config의 설정된 Option을 참고하여 객체가 동작되게 됩니다.

foo 클래스는 new 키워드에 의해 인스턴스화 될때 options 이라는 파라미터를 받아서 내부의 설정값으로 동작하게 됩니다.  컴포넌트의 Positioning, Sizing, Target Element 등을 생성할때 마다 다른 형태의 결과물을 볼 수 있습니다.

간단하게 생성한 객체들의 getXY 메서드를 수행했을 때 다른 결과 즉
Foo1 의 x, y 포지션은 생성시 아무런 파라미터도 주지 않았기 때문에 [100, 200]이 출력되었고
Foo2 의 x, y 포지션은 생성시 Hash 형태의 Object에 { x:300, y:300 } 을 넘겼기 때문에 생성시 넘겼던 옵션값을 그대로 취하게 됩니다.

이는 위젯 방식의 컴포넌트 개발 시에 매우 유용하며 javascript를 이용한 Rich UI, Application 개발 시 기획에 의도를 다양하게(?) 받아들일 수 있다.

또한 디자이너나 개발자들도 pre-config에 대한 이해만 있다면 값의 설정을 통해서 쉽게 원하는 결과물을 얻을 수 있다.

부제 : Javascript의 prototype은 어떤 의미를 갖는가?



그럼 오브젝트는 무엇일까요?

다시 MDC 에서 정의한 프로토타입에 대한 설명입니다.

Constructor

prototype 이라는 것은
javascript의 표준인 ECMAScript의 오브젝트 중 하나입니다.


이렇게 정의를 하고 계속해서 좀더 상세히 알아보도록 합니다.


ECMAScript는 C++, Smalltalk, Java 처럼 클래스의 개념이 존재하지 않지만 오히려 오브젝트를 위해 스토리지를 할당하고 그들의 프로퍼티에 초기값 할당을 통해 그것들의 일부 혹은 모든것을 초기화하는 실행 코드로 오브젝트를 만드는 생성자를 제공합니다.

생성자를 포함하는 모든 함수들은 오브젝트이지만 모든 오브젝트가 생성자가 되는 것은 아닙니다.

각각의 생성자^constructor는 프로토타입 기반^{prototype-based} 상속^inheritance과 공유^shared 프로퍼티^properties를 구현하기 위하여 프로토타입 프로퍼티 갖습니다.

오브젝트는 new 연산자에 생성자를 사용하여 생성되어짐 : 예를 들어 new String(“A String”)는 새로운 string 오브젝트를 생성합니다.

new를 사용하지 않고 생성자를 적용하는 것은 생성자에 따른 결과를 갖습니다.

예를 들어 String(“A String”) 는 초기 문자열이 만들어집니다. 하지만 오브젝트는 아닙니다.

ECMAScript는 프로토타입 기반^{prototype-based} 상속^inheritance을 지원합니다.

모든 생성자는 연관된 프로토타입을 가집니다. 그리고 생성자에 의해 생성되어진 모든 오브젝트는 생성자와 연관된 프로토타입(Object’s prototype 이라 불리우는)에 절대적인 레퍼런스를 갖습니다.

더욱이 프로토타입^prototype은 null이 아닌 원형^prototype에 절대적인 레퍼런스를 갖습니다. 그래서 이것을 프로토타입 체인^{prototype chain} 이라고 부릅니다.

오브젝트에서 레퍼런스^reference가 프로퍼티^property에 만들어 질 때 저 이름의 프로퍼티를 포함하는 프로토타입 체인^chain의 첫번째 오브젝트에 저 이름으로 프로퍼티를 갖는다.

바꿔 말하면,  

첫번째는 오브젝트가 직접 언급했던 프로퍼티가 있는지 없는지 조사(검토)하는 것입니다.  만약 오브젝트가 정해진 프로퍼티를 포함한다면 그 레퍼런스가 참조하는 프로퍼티입니다.  만약 그렇지 않다면 오브젝트는 찾기 위해서 다음 프로토타입^prototype으로 넘어간다. 

즉 위의 예제 소스를 예로 설명하자면 마지막에  childObject.name.toString(); 를 호출했습니다.
최초 childObject가 가지고 있는 name을 참조합니다. childObject에는 name 프로퍼티를 가지고 있기 때문에  toString()을 수행하게 됩니다. 만약 name 프로퍼티가 존재하지 않는다면 fatherObject -> grandFather -> Object 까지 찾아가게 되겠죠.

아무튼 name 프로퍼티가 존재하므로 childObject에는 toString()이라는 메서드를 수행하게 됩니다. 하지만 childObject 에는 toString() 이라는 메서드가 존재하지 않기 때문에 Object.prototype.toString()을 수행하게 됩니다. 만약 Object.prototype.toString 메서드가 존재하지 않는다면 당연히 (fireBug)toString is not a function 이라는 메세지를 보게되겠죠.

그래서 클래스 기반^class-based 객체 지향 언어는 일반적으로 인스턴스^instance에 의해 이동된 상태, 클래스에 의해서 이동된 메서드 그리고 상속은 구조와 습성의 유일함이다.

ECMAScript에서 상태와 메서드들은 오브젝트에 의해서 이동되어 집니다.  그리고 구조, 습성, 상태는 모두 상속되어 집니다.

직접 그것들의 프로토타입^prototype이 포함하는 특별한 프로퍼티^property를 포함하지 않는 모든 오브젝트들은 저 프로퍼티와 그 값^value을 공유한다.

아래 다이어그램을 참조

CF는 생성자 입니다(그리고 또한 오브젝트 입니다.).

다섯개의 오브젝트는 new 연산자를 통해 생성 : CF1, CF2, CF3, CF4, CF5

각각의 오브젝트는 q1, q2의 프로퍼티를 포함합니다. 점선 라인은 절대적인^implicit 프로토타입^prototype 관계; 예를 들어 CF3의 프로토타입은 CFp입니다.

그 생성자 CF는 자체적으로 CFp, CF1, CF2, CF3, CF4, CF5에 보이지 않는 2개의 프로퍼티를 갖습니다.

CFp 안에 CFp1 프로퍼티는 q1, q2 혹은 CFp1라 지정되지 않는 CFp의 절대적인 프로토타입 체인에서 발견되어지는 어떤 프로퍼티들 처럼 CF1, CF2, CF3, CF4, CF5에 의해서 공유되어 집니다.

CFp와 CF 사이에 절대적인 프로토타입 링크가 없다는 것을 알아야 합니다.

클래스 기반 언어들과는 달라 프로퍼티들은 값을 할당하는 것으로 오브젝트에 동적으로 추가될 수 있습니다.

즉 생성자는 생성되어진 오브젝트의 프로퍼티 일부분 혹은 전체에 이름과 값의 할당하는 것을 요구하지 않습니다.

위의 다이어그램에서, 한가지 CFp에 프로퍼티에 새로운 값을 할당하는 것에 의해 CF1, CF2, CF3, CF4, CF5를 위한 새로운 공유된 프로퍼티를 추가할 수 있다.

모두 ECMAScript 262-2 Spec 자료입니다.
중간에 번역의 이해를 돕고자 이미지화 하였습니다.  혹 이미지화 한 것이 혼동을 잃으킬 수도 있습니다. ^-^;
오역이 있을 수 있지만 최대한 번역에 대한 점검을 하였습니다. (외국에 살다온 직장 동료에게 검증을 받았습니다. ^^;;)

몇 일전 가비지 컬랙션에 대해서 포스팅할때 함께 기재할 메모리 테스트 부분에 대한 결과입니다.
이미지 첨부할게 너무 많아 PDF로 만들어서 첨부합니다.

도움이 될련지는 모르겠습니다.

테스트 코드 역시 첨부합니다.
테스트 코드는 IE 8의 순환참조에 대한 메모리 누수 마이그레이션 팁에 대한 내용을 실제로 구현 테스트 해 본것입니다.  실제로 테스트 코드와 같은 패턴의 사용은 메모리 IE에서 메모리 누수의 심각성을 보여줍니다.


도움이 얼마나 될른지는 모르겠습니다. ^^
순환참조에 대한 경각심 정도는 불러 일으킬 수 있지 않을까 싶기도 하네요.

Apress 에서 간만에(?) 좋은 책을 출간한듯 합니다.
조금 되긴했지만요.. ^^

요즘 출퇴근 시간에 어디 오갈때 보고 있는 책입니다. 
사실 구매는 하지 않았고 에디나양이 재본을 해줘서 잘 보고 있습니다.

javascript에 대한 기술적인 소개와 DOM 과의 연동에 있어서 이슈가 될만한 사항들
jQuery 창시자이니 만큼 그에 관련된 기술적인 노하우도 조금씩 섞여있는 듯 합니다.

또한 내용들은 Ajax 어플리케이션 개발에 많은 도움을 주는 듯합니다.
또한 Framework에 대한 이해도도 좀더 빨라지지 않을까 라는 생각을 해봅니다.

아직 읽기 시작한지 얼마 되지 않았지만 상당히 좋은 내용이 많았습니다.
Javascript를 통한 DOM 처리 부분, Javascript의 특징, OOP가 가능하게되는 것들 다양한 기술적으로
접하지 못하는 부분들까지 조목조목 잘 집어주는 듯 합니다.

또한 국내에서는 그다지 javascript에 대한 프로그래밍 언어로서의 교재는 턱없이 부족한데 이 책의
번역서가 나온다면 참 좋은 레퍼런스가 되지 않을까 생각해봅니다.


Pro javascript technical 에 더불어 Design patterns 책인데요.  다른 디자인 패턴 책들과 내용은 유사합니다.
다만 Javascript의 디자인 패턴이라는 것!!

기회가 된다면 이 책도 함께 읽어보면 좋을 것같습니다.
Java나 다른 객체지향을 했던 분들이 javascript의 패턴 책을 본다면 몹시도 혼돈스럽지 않을까도 생각이 듭니다. 그 흐름은 같지만 예제가 그다지 와닫지 않을 수 있다라는 생각을 했었습니다.

과연 자바스크립트 OOP에 대한 이해도를 조금 높히는데 도움이 될까 번역해 보았습니다.  경우에 따라 오역이 있을 수도 있습니다.  또한 완벽하지 않다는 말이 될 수도 있습니다.

원글은 아래 링크를 기재해 두었습니다.  이번 글을 개념적인 부분을 설명하고 있어 글로만 표현하였습니다.  이미지를 첨부해 좀더 이해도를 높이려고 했으나.. 힘들어서 포기 ^-^;

우리가 흔히 알고 있는 객체 지향 언어인 Java 와 C++ 의 간단한 비교가 아래부분의 표로 기재되어있습니다.   하지만 기재된 것이 차이점의 전부라고 할 수는 없습니다.

언어와 다른 언어를 비교해가며 OOP가 된다 안된다를 거론하지는 않았으면 합니다.
또한 어느 언어나 객체지향이 가능하다라고 말하고 싶습니다.  마지막으로 OOP에 대한 비교 우위를 따지는 것은 단지 수치화 해보고 싶은 마음에서만 하는것이 좋다고 생각합니다.

Java와 C++과 같은 클래스 기반 객체지향 언어는 두 가지의 뚜렷한 본질적인 개념을 갖는다.

클래스

인스턴스


클래스 정의

자바스크립트 같은 프로토타입 기반prototype-based 언어는 이렇게까지 구분하지 않습니다. : 단순히 오브젝트Object를 같습니다.

프로토타입 기반 언어는 prototype 오브젝트의 개념을 갖습니다.  개체를 사용하는 템플릿으로써 새로운 오브젝트를 위한 초기 프로퍼티를 얻기 위해 사용됩니다.

모든 오브젝트는 생성할 때나 런타임 때 자신의 속성을 지정할 수 있습니다. 또한 모든 오브젝트는 prototype 통해서 다른 오브젝트에 연결 될 수 있고 두 번째 오브젝트에 첫 번째 오브젝트의 프로퍼티를 공유하도록 허락합니다.

클래스 기반 언어, 별도의 클래스로 정의합니다.
이 정의는 여러분이 클래스의 인스턴스를 생성하기 위해서 특별한 메서드를 지정하고 생성자를 호출합니다.  생성자 메서드는 초기값을 지정할 수 있고 생성 주기에 다른 처리를 할 수 있습니다.

여러분은 클래스의 인스턴스를 생성하기 위해 생성자 함수와 관련된 new 오퍼레이터를 사용합니다.

자바스크립트 또한 같은 모델이지만 생성자로부터 별도의 클래스 정의를 갖지 않습니다.  대신에 사용자는 오브젝트를 생성하기 위해서 특정한 초기 프로퍼티와 값의 구성을 정의합니다.  모든 자바스크립트 함수는 생성자처럼 사용될 수 있습니다.  새로운 오브젝트를 만들기 위해서 new 오퍼레이터로 생성자 함수를 사용하면 됩니다.


서브클래스subclass와 상속inheritance

클래스 기반 언어는 클래스의 정의를 통해 클래스 계층hierarchy 구조를 만듭니다.  클래스의 정의에 이미 존재하는 클래스의 하위 클래스로 새로운 클래스를 지정할 수 있습니다.  서브 클래스는 슈퍼 클래스의 모든 속성을 상속 받습니다.  또한 추가적으로 새로운 속성을 부여하거나 상속 받은 것들 것 수정할 수도 있습니다.

예를 들어 직원 클래스는 이름과 부서의 속성만 갖고 하위 클래스인 관리자는 보고 속성을 추가합니다.  이 경우 관리자 클래스의 인스턴스는 세가지 모든(이름, 부서, 보고) 속성을 갖게 됩니다.

자바스크립트는 prototypical 오브젝트를 어떤 생성자 함수와 연결시키는 것을 통해서 상속을 구현한다.

그래서 직원-관리자 예제를 정확하게 만들 수 있습니다.  하지만 약간의 다른 용어를 사용합니다.  직원 생성자 함수를 정의하고 이름과 부서 속성을 지정합니다.  그런 다음 관리자 생성자 함수를 정의하고 보고서 속성을 지정합니다.  마지막으로 관리자 생성자 함수를 위해 prototype에 새로운 직원 오브젝트를 할당합니다.  여러분이 새로운 관리자를 생성할 때 직원 오브젝트로부터 이름과 부서의 속성을 상속 받습니다.


속성 추가addding 및 제거removing

클래스 기반 언어는 전형적으로 컴파일 될 때 클래스가 생성됩니다.  그렇지 않으면 클래스의 인스턴스는 컴파일 시간 또는 런타임 시에 인스턴스화 됩니다.  클래스의 정의된 후에는 클래스의 속성 타입이나 숫자를 변경할 수 없습니다.  그러나 자바스크립트에서는 런타임 시에 어떤 오브젝트의 속성을 추가하거나 삭제할 수 있습니다.
한 구성의 오브젝트를 위해 prototype으로 사용되는 오브젝트에 프로퍼티를 추가하면 그것이 프로토타입인 오브젝트들 또한 새로운 프로퍼티를 얻는다.

클래스 기반 (자바)	프로토 타입 – 기반 (자바 스크립트)
클래스와 인스턴스는 별개의 엔티티이다.	모든 오브젝트는 인스턴스이다.
인스턴스는 생성자 메서드와 갖는	생성자 함수를 갖는 일련의 오브젝트를 정의하고 생성
new 연산자로 단일 개체 생성	동일
기존 클래스들의 하위 클래스를 정의하기 위해 클래스 정의에 의한 오브젝트 계층 생성	생성자 함수와 관련되어 프로토타입으로 오브젝트를 할당하므로써 오브젝트의 계층구조를 생성
클래스 체인으로 프로퍼티 상속	프로토타입 체인에 따라 프로퍼티를 상속
클래스 정의는 클래스의 모든 인스턴스의 모든 속성을 지정합니다.  동적 런타임 시에는 속성을 추가할 수 없다.	생성자 함수 혹은 prototype은 일련의 속성을 지정합니다. 단일 오브젝트 혹은 일련의 오브젝트들에 동적인 메서드 추가 및 삭제할 수 있습니다.

참조 자료 : http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages

Jacob Seidelin 씨가 매우 재미있는 실험을 했네요.
14KB라는 작은 용량의 자바스크립트 단일 파일로 슈퍼 마리오를 구현했습니다.

재미있는 사실은 외부 이미지를 하나도 사용하지 않고 오로지 Canvas를 사용하고 거기에 자바스크립트로 직접 랜더링하는 기법을 사용하였습니다.

스프라이트(sprite)는 지정된 사용자 정의 문자열만 일정 형식으로 저장되어있고 오직 4가지 색상만 지원되며 그외의 스프라이트는 약 40~60byte 정도 소비하게 될것입니다.

스프라이트 : 화면을 구성하기 위해서 미리 지정해놓은 데이터

aSpriteData = [
    "}\"??"??"??"??"엘?~C_ +?"??"??"?P7콿K%?퐑_\"?죂죂죃M@??,    //  0 ground
    "a ' ![?7개b?mt<N?z]~쭽R?f_7l},tl},+}%XN쾄b[bl??Y_?!@ $",        //  1 qbox
    "!A % @,[] ??;탇?X?<$ ℓ 8}}@Prc'U#Z'H'@??"is ?08@?",            //  2 mario
    "  ?A.@H#q8말e-퐊?켹W:&X줭<&bbX~# }LWP41}k?3쮙#1f RQ@@:4@$",            //  3 mario jump
    "   40 q$!hWa-퐊?_Y}a?0#aaPw@=cmY<mq쯋Bagaq&@q#0?t0?$",            //  4 mario run
    "+hP_@",                                    //  5 pipe left
]


특이한 점은 파이어폭스에서 보게 되면 64base로 인코딩 된 데이터를 소리를 바로 출력해준다는 것입니다.
64Base 인코딩 데이터는 IE에서는 현재 지원하지 않아 no Music 버젼도 따로 있습니다.

<embed id="sound_0"
src="data:audio/mid;base64,TVRoZAAAAAYAAQAEAMBNVHJrAAAAGQD/UQMFe3EA/1gEBAIYCAD/
WQIAAAD/LwBNVHJrAAABqwD/AwRCYXNzAP8gAQAAsAdhAMAjhgCQJGGCHoAkQAeQK1qCB5AwX
AeAK0CBUZApVQSAMECCJJAwWQmAKUCCD5ApVwGAMECBRJAkXQyAKUCCC5AoWQSAJECCC5Ar
XA+AKEBGgCtAB5AwU4UjgDBAAZArXIFMgCtAAZAkWYIjkCtYBIAkQIIYkDBXDYArQIEsgDBACZApXIITg
ClABJAwWYILgDBAA5ApVoFJkCRcAoApQIFPkCxsBIAkQIISgCxABpAubIIEkDBiBIAuQII7kCtiA4AwQDmA
K0AgkCtWgUKQJGUQgCtAgQ6AJEAqkCRZgiKQK1gJgCRAgg6AK0AAkDBZgUmAMEADkClOghiQMFEBg
ClAggiAMEAFkClTgUmQJFwGgClAgiSQKFYLgCRAggiQK1oOgChAT5AwVQOAK0CFFIAwQASQK1aBOJ
AkXAWAK0CCMJArXASAJECCF4ArQAKQMFeBRpApUwKAMECCHYApQAKQMFaCFoAwQAiQKUGBN5
AkWg2AKUCBN5AsbBCAJECCFoAsQAOQLnGCCpAwZAKALkCFEoAwQAD/LwBNVHJrAAACSAD/Aw
ZNZWxvZHkA/yABAQCxB38AwRmHTJFPXyuBT0AskU5mKYFOQDaRTWU3gU1ALpFLdU6BS0BtkUxiaYF
MQFeRRFlJgURAEpFFalqBRUALkUhxgUqRRVwIgUhAUZFIbg6BRUBAgUhAB5FKZ3uBSkCBM5FPZDWB
T0AhkU5nLYFOQDGRTWUzgU1AKZFLX4EzgUtAE5FMZ36BTEAnkVRugR2BVEAvkVRkRYFUQBmRVGSC
fYFUQIFPkU9nMIFPQCqRTmcmgU5AN5FNZjeBTUArkUtlMoFLQIEikUxhQoFMQHiRRFRYkUVhAYFEQFm
BRUAJkUhqgUCRRWECgUhAWZFIbAiBRUBDgUhACpFKc4FigUpASJFLdoIFgUtAHZFKc4IEgUpADZFIaY
McgUhAhCuRT2Q4gU9AJJFOZi+BTkAukU1fMoFNQC6RS2qBV4FLQAWRTF6BTpFETx6BTEAxkUVnB4FE
QF+RSGANgUVAgSqRRV4IgUhAV5FIYhqBRUAugUhACJFKX4E4gUpAd5FPZS2BT0ArkU5qLIFOQDSRTW
BTgU1AEpFLaoFGkUxXBIFLQIEEgUxAMpFUX4ENgVRAKpFUXjqBVEAckVRkgxCBVECBO5FPV1eRTlwW
gU9APYFOQBKRTVYugU1ALZFLbIE3kUxUAoFLQIFwkUROCYFMQFSBREAMkUU6U5FIXAGBRUCBLIFIQ
AmRRVNRgUVACJFIXEyBSEAIkUpBghqBSkALkUtzgguBS0AFkUpnghuBSkAHkUNmhjaBQ0AA/y8ATVRy
awAAACwA/wMYU2VxdWVuY2VkIGJ5IE1pa2UgTWFydGVsAP8gAQcAtwdkAMcAAP8vAA"
loop="true" autostart="true" style="position: absolute; left: -1000px;" type="audio/mid"/>

브라우저마다의 테스트 또한 해보았나 봅니다.  모든 브라우저에서 잘 동작하고 유독 최신 사파리에서는 가장 좋은 퍼포먼스를 보인다고 합니다.

간단히 테스트 해봤지만 조금 불안하기는 합니다.  그런데  외부 요소 없이 오로지 Javascript 로만 이정도로
구현했다는 것에 박수를 보냅니다. ^^

Jacob Seidelin 씨도 이 것을 테스트라고 표현했고 만들어 놓은 마리오가 어떤 다른것들을 만들기 위한 수단으로는 완벽하지는 않고 레퍼런스 정도로 본다고 했네요.

원글 : http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html
게임 : http://www.nihilogic.dk/labs/mario/mario_large_music.htm

John Resig 가 벌써 관련 글을 올렸네요.
참고 : http://ejohn.org/blog/embedding-and-encoding-in-javascript/

부제 : garbage collection in javascript
자바스크립트 어플리케이션 메모리 관리라기 보다 가비지 컬랙션(Gabege Collection)과 클로져(closure)와 순환참조(circular reference) 의 관계에 대한 글에 가깝습니다.

중간 중간 정리하면서 가비지 컬랙션에 대한 참조한 블로그가 있었는데 까묵었습니다. ^-^;


간단 명료하게 결론부터 정리합니다.
Javascript RIA 개발 시 간과해서는 안되는 중요한 부분중에 한가지 입니다. 
바로 메모리 관리 Memory Management입니다.

  이미 여러 javascript로 RIA 개발 경험이 있는 개발자라면 뼈저리게 느끼고 있을 것입니다.
못느꼇다면 꼭 한번 브라우저를 띄우고 개발해 놓은 요소들을 메모리 테스트를 해보시기 바랍니다.

  그리고 윈도우 어플리케이션 개발자라면 이 메모리 관리에 대해서 매우 예민한 부분이 아닐 수 없습니다.  윈도우 어플리케이션도 아닌데 메모리 관리를 해줘야 한다니 그냥 웃고 넘어갈 분들도 계시겠지만 RIA 개발하려는 모든 분들께 메모리 관리에 대한 중요성을 전달해 주고 싶습니다.


가비지 컬랙션(Garbage Collection) ?
 힙heap영역에 할당된 더 이상 사용되지 않는 메모리인 가비지garbage를 가비지 컬랙터garbage collector가 다른 객체가 사용할 수 있도록 정리하는 것을 말합니다.

객체가 가리키는 참조 변수가 null이 지정되거나 객체가 더 이상 참조하지 않게 되었을 때 가비지 컬랙터의 후보가 되며 이러한 객체들은 가비지 컬랙터에 의해 메모리를 반환하게 됩니다.


가비지 컬랙션의 대상
1. 객체에 null 값이 대입되었을 때
    e.g.   var dat = new Date();
                  dat = null;
2. 참조변수에 다른 객체가 대입될 때
    e.g.   var dat = document.getElementById(‘rhio’);
                  dat = 29;
3. 메소드의 수행이 끝났을 때
    e.g.   function func() {
            var dat = document.getElementById(‘rhio’);
            //do something
          }

가비지 컬랙션과 순환참조에 대한 좋은 글  옷장수님 블로그#가비지 컬렉션의 이해

자바의 가비지 컬렉션은 자바가상머신Java Vitural Machine에서 알아서 처리하지만 개발자에 의해 직접 가비지 컬랙션을 수행 요청을 할 수 있습니다.  하지만 javascript의 경우에는 따로 개발자에 의해 가비지 컬랙션의 작업 수행 요청할 수 있는 매커니즘이 존재하지 않습니다.

Javascript는 주기적으로 가비지 컬랙션의 대상에 대한 리소스 반환 작업을 수행하게 됩니다.

IE 브라우저의 경우 순환참조Circular Reference 발생과  클로져 형성으로 메모리 누수에 대한 심각한 문제가 시작됩니다.   Javascript에서의 순환참조(Circular Reference)라 함은 Javascript 객체가 DOM 객체에 대한 레퍼런스를 포함하고 그 DOM 객체가 javascript 객체의 레퍼런스를 포함할 때를 말합니다.

위의 문단이 자바스크립트에만 순환참조가 있다라는 글로 오해될 수 있을 것 같아 살짝 수정 및 아래 내용을 추가합니다.  일반적인 순환참조(circular refrenece)에 대한 설명이 더욱 필요할 것 같네요.  (옷장수님이 의견 주셨습니다.)

일반적인 순환참조(Circular Reference)란?
참고 :
    http://en.wikipedia.org/wiki/Circular_reference
    http://en.wikipedia.org/wiki/Reference_counting

위의 예제는 흔히 우리가 알고 있는 javascript의 순환참조가 발생되면서 메모리 누수현상을 단편적으로 설명할 수 있는 예시가 됩니다.

div는 DOM 객체의 레퍼런스를 담고 있습니다. 이 DOM 객체를 outerFn 가 첫번째 인자로 취하여 DOM 객체에 func라는 프로퍼티^property  에 javascript의 익명함수^{anonymous function} 를 참조^reference하게 합니다.

이 자체가 메모리 누수라 할 수는 없지만, 위와 같은 패턴은 경우에 따라(위와 같은 작업이 반복 적으로 수행될 때) 심각한 누수 현상을 발생할 수 있습니다.  이 말은 곧 가비지 컬랙션에 의해서 메모리 반환을 하지 못하는 상황에 빠지게 됩니다.

  Javascript의 가비지 컬랙터의 경우 클로져가 형성된 것들을 관리하며 혼돈하지 않아 가비지 컬랙션에 대해 메모리 반환을 하지만 불행히 IE의 경우 DOM을 JScript가 관리하지 않아 위의 예시와 같은 순환참조와 클로져에 대해 몹시 둔감합니다.  그만큼 메모리 누수 현상이 매우 심각합니다.

 
이번 IE8이 릴리즈 되면서 그에 대한 마이그레이션 팁이 나왔습니다. 그 역시 DOM과 Javascript의 순환참조에 대한 이슈를 대부분 언급하고 있습니다.  그에 대한 테스트와 테스트 결과에 대해서 다음에  간단한 포스팅을 하도록 하겠습니다.

참고
http://www.crockford.com/javascript/memory/leak.html
http://www-128.ibm.com/developerworks/web/library/wa-memleak/

1. 엘리먼트^element

어떤 면에서 보면 단지 HTML 태그에 불과합니다.

하지만 좀더 XML 관점에서 바라본다면 위의 단위를 "엘리먼트^element"라 부릅니다.
하나의 엘리먼트는 DOM spec의 IDL(Interface Definition Language) 에 정의된 attributes를 취하게 됩니다.


2. 인터페이스^interface

  우리는 DOM의 내부(core) 구현은 알 필요가 없이 다양한 언어(java, javascript, ect)로 오브젝트와 인터페이스를 통해 document object 에 접근을 하게 됩니다.  여기서 인터페이스라는 간단히 말해

    개발자 언어(java, javascript)와 Document Objec와의 의사소통을 담당하는 중간 매개체
    <#참고 : 위키백과 - 인터페이스>   <#참고 : Web Kit DOM>

입니다.

이 인터페이스는 FireFox에서 아래와 같은 수행을 했을 때 쉽게 볼 수 있습니다. 또한 Web Kit DOM 사이트에서도 찾아 볼 수 있습니다.
위 예제처럼 알 수 있듯이 [type interface]를 취하는 것을 알 수 있습니다.  단편적인 createElement 메서드의 수행 결과이나 모든 javascript 에서 object 화 하여 취하게 되는 모든 document object 에는 고유의 interface를 제공받게 됩니다.


3.자바스크립트^javascript의  엘리먼트^element 와 인터페이스^interface의 관계

여기서 javascript를 이용하였을 때의 interface에 대한 관계를 설명하고자 합니다.


  우리는 HTML Document에서 엘리먼트의 고유한 id 프로퍼티가 'element' 인 엘리먼트 오브젝트를 넘겨줍니다.  간단하게 본 el에는 object type의 엘리먼트를 취한다고 봅니다.  또한 el을 통해서 위에 명시했던 엘리먼트의 속성을 접근하거나 이벤트 핸들링을 하거나 style을 변경하거나 할 수 있다 라고 봅니다.

  이러한 하나의 엘리먼트에 어떤 프로퍼티의 속성에 값을 지정하거나 삭제를 하거나 하는 다양한 처리를 통하여 엘리먼트에 원하는 결과로 설정합니다.

  여기서 el을 얻기 위해서 사용하는 document는 자바스크립트 엔진 런타임 시에 도입되는 window의 하위 오브젝트로 window.document 입니다.   이는 또한 DOM(Document Object Model)에 접근하기 위한 가장 상위 인터페이스(DOM 관점에서 볼때) 혹은 오브젝트(자바스크립트 관점에서 볼때)입니다.


좀더 자세한 예제를 통해서 DOM HTML Spec에서의 interface에 접근해 보도록 하겠습니다.

우리는 HTML document에 표현되지 않고 랜더링 되지 않는 엘리먼트 오브젝트를 생성할 수 있습니다.


이렇게 createElement 메서드를 통해서 image 엘리먼트를 생성하였습니다.

이때도 알 수 있지만 el에는 image object가 담겨져 있고 이것은 image가 갖는 attribute를 제공받습니다.
createElement 수행 시 생성된 엘리먼트에는  아래의 interface를 제공 받습니다.


간단한 예제 코드로 interface HTMLImageElement가 취하게 되는 attributes를 보겠습니다.

more..