Geek Answers Handbook

Would this be a good way to do private functions?

Just saw an interesting code, making a typo in a coffee script. I got the following code

var Mamal, mam; Mamal = (function() { var __priv_func; function Mamal() {} Mamal.prototype.simple_var = 5; Mamal.prototype.test = function() { return __priv_func(this); }; __priv_func = function(instance) { return alert(instance.simple_var); }; return Mamal; })(); mam = new Mamal(); mam.simple_var = 10; mam.test();

Now I read a lot about the module template in javascript and why it is bad (takes more memory, more time to create ...), but of course the up has really private functions / variables. Wouldn't this code be a good way to create private functions (this will not work for variables if you don't want static private variables), since a function is created only once in closure?

One of the advantages of the module template is also the speed of execution of functions, since the code should not look for a chain of prototypes. Does this theoretically give the same speed improvements?

+7
source share
2 answers

To highlight the points that I did, because clearly there was more to the question than just the name:

  • Yes, a module template is a good and commonly used way to create private (er, local) data (functions or something else) and export some interface. Since a function is the only way to create a variable region, it is the only way to create private functions.

  • Since functions will be shared by all objects created from Mamal , they are not useful for the functional inheritance template (references to functional inheritance have been removed from the question).

  • There is no performance improvement in the prototype chain compared to searches, because the prototype chain must be passed anyway in order to get to your private functions.

To ask specific questions in an updated post:

"Would this be a good way to do private functions?"

Of course, but this is because having a function nested in another is the only way to cover the function.

"Now I read a lot about the module template in javascript and why its bad ..."

For single use, I do not see any problems. In addition, any data referenced by variables that are no longer needed after the module function exits is free for garbage collection. That would not be true if they were global, if you had not canceled them.

"... of course, up has really private functions / variables ..."

Yes, although some will prefer to use the word "private". Probably "local" is the best word.

"... this will not work for variables unless you want static private variables ..."

Yes, although some may make an exception for the use of the word “static”.

"Wouldn't this code be a good way to create private functions ... since a function is created only once in closure?"

Again, nested functions are the only way to make them "private" or, rather, local.

But yes, as long as the function only ever needs access to the public properties of the objects (which are accessible to any code that can access the object), and not to the local variables of the constructor, then you should only create those functions once , regardless of whether you use a module template.

“One of the advantages of the module template is also the speed of execution of functions, since the code should not look for a chain of prototypes. Theoretically, this will give the same speed improvements?

No, you did not export your private functions directly, but, on the contrary, the only way to call them is to go through the prototype chain.

But if you drop the prototype chain and add functions as properties directly to the created objects, then you will have some improvement.

Here is an example:

 Mamal = (function() { var __priv_func; function Mamal() { this.test = __priv_func; } Mamal.prototype.simple_var = 5; __priv_func = function() { return alert( this.simple_var ); }; return Mamal; })();

Now you have excluded the prototype chain in the search for the test function, as well as calling the completed function, and you are still reusing __priv_func .

The only thing left to prototype is simple_var , and you can also transfer it directly to the object, but this will happen when you try to change its value so that you can leave it.

Original answer:

If you are talking about a module template where you set up a bunch of code in (usually) IIFE, then export methods that have access to variables in an anonymous function, then yes, this is a good approach, and quite common.

 var MyNamespace = (function () { // do a bunch of stuff to set up functionality // without pollution global namespace var _exports = {}; _exports.aFunction = function() { ... }; _exports.anotherFunction = function() { ... }; return _exports; })(); MyNamespace.aFunction();

But in your example, I do not see and do not use a typical constructor if you do not decide to use the module template as described above.

How this happens now, identical functionality can be performed without this more global pollution and without a wrapped function:

 var Mamal, mam; Mamal = function() {}; Mamal.prototype.test = function() { return console.log(this.simple_var); }; Mamal.prototype.simple_var = 5; mam = new Mamal(); mam.simple_var = 10; mam.test();

"Wouldn't this code be a good way to create private functions (this will not work for variables unless you want static private variables), since a function is created only once in closure?"

Given the rewritten code above, the function is still only created once. The prototype object is shared between objects created from the constructor, so it is also created only once.

“One of the advantages of functional inheritance is also the speed of execution of functions, since the code should not look for a chain of prototypes. Theoretically, this will give the same speed improvements?”

In your code, a function is called by a function in the prototype chain, so it has the same overhead as well as the overhead of locating a local function in the variable area and calling that function.

So, two searches and two function calls instead of one search and one call.

+1
source 
 var Mamal, mam1, mam2; Mamal = (function() { //private static method var __priv_func = function() { return 1; }; function Mamal() { } Mamal.prototype.get = function() { return __priv_func(); }; Mamal.prototype.set = function(i) { __priv_func = function(){ return i; }; }; return Mamal; })(); mam1 = new Mamal(); mam2 = new Mamal(); console.log(mam1.get()); //output 1 mam2.set(2); console.log(mam1.get()); //output 2

The __priv_func function is not only private, but also static. I think this is a good way to get a private function if “static” doesn't matter.

Below is a way to get a private but not static method. It may take more memory, longer to create .......

 var Mamal, mam1, mam2; function Mamal() { //private attributes var __priv_func = function() { return 1; }; //privileged methods this.get = function() { return __priv_func(); }; this.set = function(i) { __priv_func = function(){ return i; }; }; } mam1 = new Mamal(); mam2 = new Mamal(); console.log(mam1.get()); // output 1 console.log(mam2.get()); // output 1 mam2.set(2); console.log(mam1.get()); // output 1 console.log(mam2.get()); // output 2
0
source

More articles:


All Articles