(function (window, document, undefined) {…}) (window, document)를 사용하면 어떤 이점이 있습니까?

(function (window, document, undefined) {…}) (window, document)를 사용하면 어떤 이점이 있습니까?

---

이 질문에 이미 답변이 있습니다.

• 이 JavaScript / jQuery 구문은 어떻게 작동합니까 : (function (window, undefined) {}) (window)? 5 답변

이 패턴을 사용하는 것이 새로운 매력이라고 생각하지만 장점이 무엇인지 이해하지 못하고 범위 지정 의미를 이해하지 못합니다.

패턴:

(function(window, document, undefined){
  window.MyObject = {
    methodA: function() { ... },
    methodB: function() { ... }
  };
})(window, document)

그래서 이것에 대해 몇 가지 질문이 있습니다.

이와 같은 객체를 캡슐화하는 데 특별한 이점이 있습니까?
왜 윈도우 와 문서를 대신 일반적으로 액세스되는에 공급되는?
도대체 왜 undefined전달되고 있습니까?
우리가 만들고있는 개체를 창에 직접 부착하는 것이 특히 좋은 생각입니까?

나는 Crockford 스타일의 자바 스크립트 캡슐화 (Douglas Crockford Javascript 비디오에서 가져 왔기 때문에)라고 부르는 것에 익숙합니다.

NameSpace.MyObject = function() {
  // Private methods
  // These methods are available in the closure
  // but are not exposed outside the object we'll be returning.
  var methodA = function() { ... };

  // Public methods
  // We return an object that uses our private functions,
  // but only exposes the interface we want to be available.
  return {

    methodB: function() {
      var a = methodA();
    },
    methodC: function() { ... }

  }
// Note that we're executing the function here.
}();

이 패턴 중 하나가 다른 것보다 기능적으로 더 낫습니까? 첫 번째는 다른 것의 진화입니까?

---

창과 문서가 정상적으로 액세스되지 않고 공급되는 이유는 무엇입니까?

일반적으로 식별자 확인 프로세스를 고정하기 위해 로컬 변수로 사용하면 도움이 될 수 있습니다 (IMO에도 성능 향상은 무시할 수 있음).

전역 개체를 전달하는 것은 또한 window전역 범위에 식별자 가없는 비 브라우저 환경에서 널리 사용되는 기술입니다 . 예 :

(function (global) {
  //..
})(this); // this on the global execution context is 
          // the global object itself

도대체 정의되지 않은 이유는 무엇입니까?

이는 undefinedECMAScript 3 의 전역 속성이 변경 가능 하기 때문에 만들어집니다 . 즉, 누군가가 코드에 영향을 미치는 값을 변경할 수 있습니다. 예를 들면 다음과 같습니다.

undefined = true; // mutable
(function (undefined) {
  alert(typeof undefined); // "undefined", the local identifier
})(); // <-- no value passed, undefined by default

주의 깊게 살펴보면 undefined실제로 전달되지 않는 경우 (함수 호출에 인수가 없음) undefined속성을 사용하지 않고 값 을 가져 오는 신뢰할 수있는 방법 중 하나입니다 window.undefined.

이름 undefined자바 스크립트가 아니라 평균 아무것도 특별하지 같은 키워드 아니다 true, false등 ..., 그냥 식별자입니다.

기록을 위해 ECMAScript 5에서이 속성은 쓰기 불가능으로 설정되었습니다.

우리가 만들고있는 개체를 창에 직접 부착하는 것이 특히 좋은 생각입니까?

다른 함수 범위에있을 때 전역 속성을 선언하는 데 사용되는 일반적인 방법입니다.

---

This particular style does bring some benefits over the "Crockford" style. Primarily, passing window and document allows the script to be more efficiently minified. A minifier can rename those parameters to single-character names, saving 5 and 7 bytes respectively per reference. This can add up: jQuery references window 33 times and document 91 times. Minifying each token down to one character saves 802 bytes.

Additionally, you do get an execution speed benefit. When I first read @joekarl's assertion that it provides a performance benefit, I thought, "that seems rather spurious." So I profiled the actual performance with a test page. Referencing window one hundred million times, the local variable reference provides a modest 20% speed increase (4200 ms to 3400ms) in Firefox 3.6 and a shocking 31,000% increase (13 sec to 400ms) in Chrome 9.

Of course, you're never going to reference window 100,000,000 times in practice, and even 10,000 direct references only take 1ms in Chrome, so the actual performance gain here is almost completely negligible.

Why the heck is undefined being passed in?

Because (as mentioned by @CMS) the token undefined is actually undefined. Unlike null, it has no special meaning, and you're free to assign to this identifier like any other variable name. (Note, however, that this is no longer true in ECMAScript 5.)

Is attaching the object we're creating directly to window a particularly good idea?

The window object is the global scope, so that's exactly what you're doing at some point, whether or not you explictly write "window." window.Namespace = {}; and Namespace = {}; are equivalent.

---

I'm with you in using Crockford's style.

To answer your questions

1.Is there a particular advantage to encapsulating an object like this?

The only advantage I can see is by making window and document local variables instead of global variables, you get some added safety by not being able to directly overwrite either one and also some performance gain by them both being local.

2.Why are window and document being fed in instead of just being accessed normally?

Addressed above. Local variables tend to be faster, but with jit compiling these days thats becoming nominal.

3.Why the heck is undefined being passed in?

No clue....

4.Is attaching the object we're creating directly to window a particularly good idea?

Probably not, but I would still stick with Crockford's pattern as attaching the function to the window object exposes it to the rest of the global stack through the window object as opposed to exposing it through a non-standard namespace.

---

I think this is mostly for code that needs to run in multiple window contexts. Say you have a complex application with lots of iframes and/or child windows. They all need to run the code in MyObject, but you only want to load it once. So you load it in whatever window/frame you choose, but you create a MyObject for each window/frame with references to the proper window and document.

Taking an undefined argument is trying to protect against the fact that undefined can be changed:

undefined = 3;
alert(undefined);

See CMS's answer about how this improves safety.

참고URL : https://stackoverflow.com/questions/5020479/what-advantages-does-using-functionwindow-document-undefined-windo