Closures are a very important feature of ECMAScript, but it is difficult to describe them in a suitable definition. Although closures are difficult to describe clearly, they are easily created, or inadvertently created. However, there are some potential problems in the closure of the package. To avoid "accidentally" creating closures and better leveraging the benefits of closures, it is necessary to understand the mechanism of closures.
definition of closures
With regard to closures, there are too many definitions, especially some that are very abstract, like this:
A "closure" is a expression (typically a function) which can have free variables together and an environment that binds T Hose variables.
Generally speaking, closures are an expression that has some free variables and the execution environment that binds them. This definition is too written, but difficult to understand.
There is also another definition:
All functions are closures. This definition gives me a lot of confusion, in other words, because JavaScript does not have block-level scope, closures generally refer to functions (there is no way to form a closure besides functions).
I don't want to talk too much about the relationship between the function and the closure, here's a definition I think is easier to understand.
First, the closure exists based on the scope chain. Because of the mechanism of the scope chain, all functions (even global functions) can refer to variables in the context execution environment (that is, free variables).
Second, there must be free variables inside the closures. By the way, two kinds of variable 1. Local variables (bound variables) 2. non-local variables (free variables)
Finally, it still exists after the context environment has ended. That is, an intrinsic function has a longer life cycle than its external function.
parsing the definition of closures
With regard to the closure of the definition of two points, has been considering whether must be met simultaneously.
First of all, if there is no free variables inside the closure, that means it does not have access to external variables, then it loses the meaning of the closure. (unless the behavior is changed by other closures) so I think free variables is a necessary condition.
Second, if there is a free variables inside a function, it is destroyed when its context is destroyed. You can imagine an intrinsic function that, while accessing its external function variables, is recycled when the external function is finished. In this case, there is no point in the discussion of closures.
Take a look at two examples:
Copy Code code as follows:
var objecta = (function () {
var Locala = "Locala";
INNERFN ();
Simple internal function call
function Innerfn () {
Locala = "InnerChange";
}
return {
Getlocala:function () {
Return "Empty";
}
};
})();
Objecta.getlocala ();
Objecta.getlocala = function () {
return Locala;
};
Console.log (Objecta.getlocala ()); Error:locala is not defined
var OBJECTB = (function () {
var localb = "Localb";
return {
Getlocalb:function () {
Return "Empty";
},
Updategetlocalb:function () {
This.getlocalb = function () {
return localb;
};
},
Updatelocalb:function () {
Localb = "Changelocalb";
}
};
})();
Console.log (Objectb.getlocalb ()); Empty
Change through other closures
Objectb.updategetlocalb ();
Console.log (Objectb.getlocalb ()); Localb
Objectb.updatelocalb ();
Console.log (Objectb.getlocalb ()); Changelocalb
Advantages and disadvantages of closures
The advantage of closures is that the closures have access to the parameters and variables of the external functions that define them (except this and arguments).
The main problem with closures is that it saves the scope of the functions that contain it, so it takes up more memory than the normal function, so it is not appropriate to overuse closures.
the application of closure package
The most basic application scenario for closures is to implement private, such as module mode, by protecting internal variables.