Rhio.Kim's Blog - drawing Laputa Web -

다음의 코드를 JavaScript의 맨 앞쪽에서 수행하면 됩니다.

/* @ cc_on _d = document; eval(‘var document = _d’) @*/

위의 코드를 IE에서 수행을 하면 document 접근이 약 5배 정도 빨라집니다.

//before
var date = new Date;
for(var i = 0; i < 100000; i++) document;
alert( new Date – date);
//547

/* @ cc_on _d = document; eval(‘var document = _d’) @*/

//after
date = new Date;
for(var i = 0; i < 100000; i++) document;
alert( new Date – date);
//47

IE에서는 document에 그냥 접근하게 되면 window 객체의 내부 메서드가 실행됩니다. IE에서는 이 부분이 아주 무거운 부분인데요.

var _d = document;

이렇게 하고 _d 라는 document의 레퍼런스를 통해서 접근하면 매우 빨라집니다.
위의 코드를 몇 가지의 형태로 더 테스트 해봤습니다.
 대부분의 브라우저에서 속도가 10배 혹은 20배 이상 나타나는 경우도 있었습니다.

// Before
var date = new Date; 
for (var i = 0; i <100000; i++) document.getElementById; 
			
alert ('before '+ (new Date - date)); // 100
			
/*@cc_on _d=document; eval('var document=_d; var getEl=_d.getElementById;')@*/
			
var _d = document;
var getEl= _d.getElementById;

// After
date = new Date; 
for (var i = 0; i <100000; i ++) getEl;  

alert ('after '+ (new Date - date)); // 4 

Chrome 에 document.getElementById 의 DOM 메서드에 대한 테스트에서는 Before : 100s,  After : 4s 정도가 평균적으로 나타났습니다.

위의 내용은
일본의 amachang 씨가 블로그에 소개한 내용입니다.

원글 :
http://d.hatena.ne.jp/amachang/20071010/1192012056
추가글 :
http://d.hatena.ne.jp/uupaa/20081230/1230604575

이 글에 대한 자세한 테스트 자료가 있어서 함께 소개합니다.

JavaScript Injection Attack - 자바스크립트 인젝션 공격

JavaScript 보안 관련 자료가 있어 번역하여 올립니다.
웹 기술의 변화와 관심이 달라지는 만큼 함께 신경써야 할 부분도 많아지고 그만큼 복잡해지나 봅니다.


최근 JavaScript 인젝션 공격이 유행하고 있습니다.  Malware 감염을 전파하는 효과적인 수단으로 이러한 종류의 공격을 활용하는 악성웨어들이 늘고 있다.

불과 1 년 전만해도 악의적인 공격자가 의지하고 있던 것은 공격용 Web 사이트를 가리키는 이메일, 검색 링크 또는 인스턴트 메시징 웜 등의 연결로 사람들을 유도하는 방식이었다.

지금은 JavaScript 인젝션 공격을 이용하여 Web 사이트의 방문자를 "납치"하고 만다. 이 공격은, 이른바 어둠 세계의 해커들이 악성웨어가 만연하도록 하는데 사용하는 맥가이버 칼과도 같다.




우리는 다수의 높은 트래픽을 보았고, 합법적인 웹 사이트들은 이 기술을 이용해 공격을 받았다.  최근  알렉사 랭크 3172의 미국의 매우 유명한 게임 포털인 MegaGame도 하나의 예이다. 자바스크립트 인젝션 공격은 MegaGame 서버 중 하나의 서버에 몇 줄의 코드를 성공적으로 추가하였고 이 추가는 아무것도 모른체 웹 사이트를 접속한 방문자들을 악의적인 유럽 사이트로 이동시키고 악성웨어에 감염시키려 시도되었다.

그 악의적인 사이트는 두 가지 다른 방법을 통해 방문자들에게 공격을 시도하였다.  첫 번째는 Microsoft MDAC RDS.Dataspace ActiveX Control Remote Code Execution Vulnerability (MS06-014).
를 시도했다.

 

이 공격은 Microsoft's Internet Explorer (IE) 브라우저를 사용하는 방문자에게만 성공할 수 있었다.
왜냐하면 이 Web 사이트는 기본적으로 ActiveX 컨트롤의 사용을 요구하고 ActiveX 컨트롤 및 IE 간의 상호 작용에 존재하는 허점 (루프 홀)을 통해 원격으로 컴퓨터를 공중 납치하기 때문이다.

두 번째 공격은 다운로드 시 실행되고 IE뿐만 아니라 "Firefox"버전 1.0이 2.0이 대상이다. 이 공격에서는 JavaScript를 사용하여 Web 브라우저 종류를 확인하고 그 후에 미국 어도비 시스템의 Flash의 악용을 통해 공격에 대한 바이너리 파일을 PC에 다운로드하고 실행한다.

 

MegaGames의 Web 사이트는 여전히 감염된 상태. 불행히도 이것이 바로 현재의 상황을 말해 준다

인터넷 이용자의 대부분은 "pr0n"(포르노) 나 "warez"(와레즈 : 불법 복제 소프트웨어) 와 같은 계시의 위험이 높다.  (dodgy: 자못 의심스러운) Web 사이트를 방문한 경우 감염도 없다고 생각하고 듯하지만,  불행이도 그것은 잘못된 생각이다.

Malware 수법은 이전보다 성공화되고 있으며, 현재는 제대로 된 뉴스 사이트 및 비즈니스 관련 사이트도 감염되어있을 가능성이 있다.

"안전한 Web 사이트는 존재하지 않는다"는 것을 보여주는 또 경우가 BusinessWeek.com이다.  아주 정통으로 접근할 수가 많은 이 사이트가 SQL 주입 공격 타겟이 됐다.  이 같은 SQL 인젝션 공격이  JavaScript 인젝션 공격으로 연결 된다.

출처 : http://www.f-secure.com/weblog/archives/00001502.html


포스팅하려고 준비해 둔 JavaScript Injection 공격에 대한 자료를 첨부합니다.
상세한 자료는 아니고 아웃라인(흐름)에 대한 내용입니다.

올해 Ajax Experience 에서 Oliver Steele 의 JavaScript 발표 자료입니다.
JavaScript의 예제 중심의 키 포인트를 집어주고 있네요.

JavaScript의 언어적 특징을 이해하는데 도움이 되겠네요.

블로그 : http://osteele.com/
페이지 : http://osteele.com/talks/ajaxian-2008/samples/
프리젠테이션 : http://www.slideshare.net/osteele/oliver-steele-functional-javascript-presentation
PDF : http://osteele.com/talks/Oliver_Steele_Functional_JavaScript_v2.pdf

일반적으로 Flyweight pattern은 효율적으로 유사한 오브젝트들의 공유를 제공하여 메모리 사용을 최소화하고 고성능을 위한 소프트웨어 디자인 패턴입니다.

Ajax/Rich UI 개발의 경우 수 많은 DOM 오브젝트에 비슷한 기능을 부여하거나 수행하는 경우가 많다.  이런 경우 각 DOM 오브젝트에 메소드를 부여하거나 상속에 의한 혹은 prototype chain에 의한 레퍼런스를 통하여 기능을 수행하도록 처리합니다.
 
하지만 경우에 따라서는 매우 복잡한 DOM 오브젝트 제어가 필요하게 됩니다.  그럴 경우에 위의 패턴을 적용하면 성능 향상에 뛰어남을 보입니다.

실제로 jQuery와 ExtJS에서는 이 패턴을 적용하고 있습니다.  반대로 prototype.js 의 Element의 경우에는 $함수를 통하여 얻어온 DOM 오브젝트에 Element가 갖는 메소드 즉 down() up(), next(), previous() 등등 수 많은 메소드를 prototype에 의해서 DOM 오브젝트가 Element.down(), Element.up() 등의 메소드를 레퍼런스하게 됩니다.

IE, Safari의 경우에는 __proto__ chain메카니즘이 존재하지 않기 때문에 해당 엘리먼트에 Element 객체가 갖는 모든 메소드를 부여하는 과정을 한번 더 거치게 됩니다. <관련기사:옷장수님 블로그#Element-메소드-상속>

이 처럼 브라우저에 따라서는 수많은 오브젝트에 확장 메소드를 부여하여 수행하려고 한다면 메모리 사용과 성능면에서 뒤 떨어질 수밖에 없습니다.  

Flyweight 패턴의 경우에는 성능 향상과 메모리 사용면에서 탁월하다는 것을 느끼실 수 있을 것입니다.

간단한 그림을 통해서 Pattern을 이해해보도록 하겠습니다.



좌측은 코드의 주요 수행 과정이고 우측의 Element는 DOM 오브젝트의 기본적인 제어를 위한 공유 오브젝트입니다.  dom 프로퍼티는 Element객체 내에서 내부적으로 제어를 하게 됩니다.
예를 들어 hide 프로퍼티는 dom.style.display = ‘none’; 가 수행되는 기능을 가지고 있게 됩니다. 

좀더 섬세한 예제로 Prototype.js의 $ 함수를 예로 들어보겠습니다.
$(‘rhio’) 라는 명령문을 수행하였다면 document.getElementById(‘rhio’)를 내부적으로 수행하여 순수한 DOM 오브젝트가 반환되면 내부적으로 Element.extend가 수행되어 DOM 오브젝트에 $(‘rhio’).update(‘본 내용이 innerHTML됩니다.’); 라는 명령을 수행할 수 있게 됩니다.

즉 $ 함수를 수행할 때마다 얻어온 DOM 오브젝트에 extend하는 과정이 수행됩니다.  (Firefox의 경우 __proto__ chain에 의해서 extend 과정없이 레퍼런스가 가능하기는 합니다.)

prototype 1.6.0.2 기준으로 2543line 에 보면 $함수를 호출할 때 자동적으로 수행되는 Element.extend 수행 시

if (Prototype.BrowserFeatures.SpecificElementExtensions)
    return Prototype.K;

명령 구문의 Prototype.BrowserFeatures.SpecificElementExtensions 에 의해서 __proto__ 메카니즘을 제공하는 브라우저인지를 체크되며 Mozilla브라우저의 경우에는 Prototype.K를 반환하고 종료됩니다.

각설하고...

반면 위의 Flyweight Pattern의 경우에 순수한 DOM은 Element.dom 프로퍼티로 레퍼런스되고 그 레퍼런스는 Element의 공유 메소드들을 통해서 제어되게 됩니다.


Source Example

var Fn = function() { };
Fn.prototype = Element.prototype;
var _fly = new Fn();

Element.Flyweight = function(dom) {
   this.dom = dom;
};
Element.Flyweight.prototype = _fly;
Element.Flyeight.prototype.isFlyweight = true;
var _flyweights = { };

Element.fly = function(el) {
  el = document.getElementById(el);
  
  if(!el) { 
     return null;
  }
  
  if(! _flyweights[‘cache’]) {
      _flyweights[‘cache’] = new Element.Flyweight();
  }
  _flyweights[‘cache’].dom = el;
  return _flyweights[‘cache’];
}; 

위의 그림과 소스를 번갈아 가면서 보시면 좀더 이해가 빠를 수 있습니다.  설명은 중요한 부분만 정리해 설명드리고 소스는 ExtJS의 Element.fly 부분을 인용하여 변경한 소스입니다.
c.f) ExtJS > Element.js 2986 line ~ 3019 line

Element.Flyweight.prototype는 implicit prototype 이 Element.prototype을 향하고Element.prototype 이 갖는 메소드들(get, hide, show 등)은 Element에 의해서 공유되게 됩니다.
Element.Flyweight function은 new 키워드를 통해 인스턴스화 될 때 Element의 공유 프로퍼티에 접근할 수 있게 됩니다.  여기까지가 Flyweight Pattern의 기본 구조라 할 수 있고 ExtJS의 경우 경우에 따라 좀더 개선된 방식까지 제공하고 있습니다.

ExtJS의 Framework이 로드되면서 생성된 변수 _flyweights에 Element.prototype을 참조하는 function 오브젝트 즉 Element.fly( )를 최초 호출되면 Element.Flyweight( )는 인스턴스화 되어 이를 저장해두고 다음 호출부터는 _flyweights의 저장된 객체에 dom 메소드만 변경하여 반환하게 됩니다.

일반적으로 DOM 오브젝트를 JavaScript로 제어하려고 할 때 일관된 메소드를 제공하는게 프레임웍의 기본 방향인 것 같습니다.  하지만 경우에 따라서는(거의 없겠지만) Image, Script의 DOM 오브젝트에는 일관된 메소드보다 확장된 메소드를 제공하고 싶은 경우거나 반대로 불 필요한 메소드를 제공하지 하지 않아야 하는 경우라면 위와 같은 패턴은 비효율적일 수 있겠습니다.

참고 :
Pro JavaScript Design Patterns [ Ross Harmes and Dustin Diaz ] 179page ~ 195page
http://en.wikipedia.org/wiki/Flyweight_pattern
http://extjs.com/forum/showthread.php?p=140648

인사이트 출판사에서 Prototype and Script.aculo.us 라는 책을 출간하면서 던졌던 Unobtrusive JavaScript에 대한 질문!!

많은 분들이 고심했지만 모든 분들이 딱히 어색하지 않고 만족할 만한 번역어를 찾지 못했습니다.
굳이 번역을 해서 국어로 표현할 필요는 없지만 그 의미를 확실히 알면 더 좋지 않을까 해서 이곳 저곳의 자료를 모아서 정리해봅니다.



2008-03-06  Simon Willison
+ A set of principles for writing accessible, maintainable JavaScript
+ 쓰기 쉽도록 하고 계속 유지할 수 있는 자바스크립트를 위한 일련의 원리들
+ A library that supports unobstrusive scripting (jQuery)
+ unobstrusive 스크립팅을 지원하는 라이브러리

http://www.slideshare.net/simon/unobtrusive-javascript-with-jquery

2003 Steven Champeon and Nick Finck

Progressive enhancement (점진적인 향상)
Rather than hoping for graceful degradation PE builds documents for the least capable or differently capable devices first, then moves on to enhance those documents with separate logic for presentation, in ways that don't place an undue burden on baseline devices but which allow a richer experience for those users with modern graphical browser software…

요약> 위의 slideshare.net 에 있는 자료가 unobstrusive JavaScript에 대해서 가장 잘 설명하고 있는 것 같습니다.

2007-12 matt aimonetti - SDRuby
http://railsontherun.com
+ behavior oriented JS with (graceful degradation) progressive enhancement
+ 점진적인 향상(우아한 성능 저하)을 갖는 습성 지향적인 JavaScript

Wiki
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

  "Unobtrusive JavaScript" is an emerging technique in the JavaScript programming language, as used on the World Wide Web.
  "Unobtrusive JavaScript"는 JavaScript 프로그래밍 언어에서의 기술을 말하는 것이다.

  Though the term is not formally defined, its basic principles are generally understood to include
  일반적으로 정의되지 않았지만 그것의 기본 개념은 일반적으로 이해하는 다음의 것들을 포함한다.

  + Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation
  + 웹 페이지의 구조, 콘텐트 그리고 표현으로 부터 기능("습성 레이어")의 분리
 
  + Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)
  + 고전적인(예전의 방식) JavaScript 프로그래밍의 단점을 피하기 위한 가장 좋은 예제이다. (브라우저 호환성 불일치와 확장성의 더딤과 같은)

+ Graceful degradation in browsers where the advanced JavaScript functionality will not work as desired
+ 고급 자바스크립트 기능은 브라우저에서 우아한 성능 저하로 원하는 만큼의 동작하지 않을 것이다.
 
  Best Practices
    Though the essence of unobtrusive JavaScript is the concept of a separate behavior layer, advocates of the paradigm generally subscribe to a number of related principles, such as:
    
    Strict adherence to the W3C DOM and event model, and avoidance of browser-specific extensions.
    More generally, JavaScript best practices often parallel those in other programming languages, such as encapsulation and abstraction layers, avoidance of global variables, meaningful naming conventions, use of appropriate design patterns, and systematic testing. Such principles are essential to large-scale software development, but have not been widely observed in JavaScript programming in the past; their adoption is seen as an essential component of JavaScript's transition from a "toy" language to a tool for serious development.


JavaScript의 태생은 1995년 ‘웹 페이지에 생명을 불어넣기 위한’ 일환으로 넷스케이프 웹 브라우저에 공식 채택되었다. [Pro JavaScript Techniques인용 – 인사이트 출판사]

출시 당시만 해도 단지 웹 페이지의 좀더 강한 기능과 동적인 처리만을 위해서 쓰여졌기 때문에 HTML과도 섞이고 CSS와도 섞이는 단지 HTML의 <head> ~ </head>내에 존재하는 일부분으로 여겨져 왔습니다.

또한 HTML 태그안에서 잠재적인 인라인(inline) 스크립트로 기생해 왔습니다.

이렇듯 HTML 문서 내 다양한 곳에서 HTML과 CSS와 함께 뒤섞여 동작을 해오다 최근 다양한 프레임웍(Dojo, jQuery, Prototype, mootools, etc : 이것들은 unobstrusive의 가장 적합한 예제)이 나오면서 더 이상 HTML 문서 내에서는 JavaScript 소스를 찾아볼 수 없게 되었습니다.

단지 연관되어진 <script src=””></script> 하나를 제외하고는 말이죠.
이렇듯 이런 변화를 위에서 언급한 기사들처럼 국외 개발자들에 의해서는 "Unobtrusive JavaScript" 라는 합성어로 탄생하게 되었습니다.

이는 우리나라의 사전적 의미로는
un•ob•tru•sive〔              〕 a. 주제넘지 않은; 조심성 있는, 겸손한, 삼가는[naver 사전]
와 같은 의미를 갖습니다.

하지만 “주제넘지 않은 자바스크립트”, “조심성 있는 자바스크립트”, “겸손한 자바스크립트”, “삼가는 자바스크립트”  이 모두가 조금은 연관성이 있지만 완벽에 가까울 의미 전달은 어려워 보입니다.

Prototype and Script.aculo.us 라는 책의 역자이신 박영록님께서는 고심 끝에 “나대지 않는 자바스크립트”라는 표현을 사용하셨습니다.

 “나대지 않는” 이라는 단어가 함축하고 있는 의미를 살펴보면 여러가지 의미를 내포하고 있기도 합니다.   나대지 않는 다라는 것은 겸손하다라는 의미도 있고 주제 넘지 않는 이라는 의미도 지니는 것 같습니다.  

어떤 의미에서 JavaScript가 나대지 않는 다고 표현할 수 있을까요?  바로 상호 의존할 수 밖에 없는 HTML문서와 JavaScript의 역할에 있어서 비춰보면 될 것 같네요.  이에 HTML 문서는 JavaScript가 활동할 수 있는 Field 역할을 해줍니다.  그럼에도 불구하고 JavaScript가 웹 페이지의 동작에 관여를 하고 웹 페이지 소스 내에서 무자비하게 프로그래밍 되어있다라고 한다면 “HTML 입장에서는 JavaScript가 너무 나댄다” 라고 말할 수 있겠습니다.

짧은 소견으로는 나대지 않는 이라는 표현을 잠깐 사용했지만 프로그래밍적인 해석과는 어색하게 느껴집니다.  
여기에 사전적으로 남의 것에 참견하지 않고 방해하지 않으며 JavaScript의 주요 기능만 수행을 하는, 기술적으로 Behavior layer(습성 레이어) 를 완벽하게 분리하려는 목적을 충족하는 함축할 수 있는 의미가 무엇이 있을까 생각했습니다.

일단 의미 중 “JavaScript의 주요 기능만 수행”이라는 것은 무의미 하다고 가정합니다. 어떤 언어나 자신의 주요 기능만을 수행하는 것이 당연하며 JavaScript에서 이런 의미가 출현한 것은 고전적인 스크립팅 방식에서 탈피하는 과정에 있어서 나타난 의미일 수 있다고 생각을 하며 현재에는 ECMAS4가 발표되었고 완벽한 객체 지향 언어로서의 모습을 갖췄다 라고 볼 수 있기 때문입니다.

이에 주요 기능을 수행하는 의미는 퇴색되며 웹 페이지(HTML)과 JavaScript간에 동작하면서 간섭하지 않는 다라는 의미 즉 HTML과는 습성이 틀린 JavaScript가 상호 참견하지 않고 완벽히 분리되어 동작하는 것이 가장 강하게 표현되어야 한다고 생각해봅니다.

최근 발표된 프레임웍들 또한 이런 의미와 목표를 두고 개발되어진 것이 아닌가 생각해봅니다.  나대지 않거나 겸손하다는 것은 어떤 대상에 대해서 그러한 상태를 나타내는 것이기에 프레임웍이나 자바스크립트를 이용한 Rich UI를 개발하는 개발자들에게는 Behavior Layer의 분리에 좀더 중점을 두지 않았을까 생각해 봅니다.

그래서 저는 생각끝에 “Unobtrusive”를 “비간섭 혹은 비간섭적인” 즉 비간섭 자바스크립트 라고 정리해 봅니다. (발음 : 어넙트러시브 자바스크립트)

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에서 메모리 누수의 심각성을 보여줍니다.


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

과연 자바스크립트 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

Ajaxian.com 에 재미있는 포스팅이 있길레 퍼옵니다. ^-^;

스타게이트(stargate) 에피소드에서도 javascript를 사용한다는것!!!
대략 난감하지만 재미있네요..
콘솔에 외계어를 넣으니까 자바스크립트로 디코딩 되어서 보여주는 군요.


대단한 javascript!!!
미래를 선두할 자바스크립트의 세계!!

외계의 오염된 저그같은 녀석들이 지구를 침범하려 할때 분명 전세계에서는 자바스크립트 개발자를 절실히 필요하게 될 것입니다.. (-_-;; 막나가봅니다.)