I was looking over the js source code for Scrabb.ly.
I've noticed that they would do something like so for each of their distinct "classes":
var Board = (function() {
var self = {};
// settings for board
self.options = {
debug: true,
addedPlayTiles: function() {},
clearedPlayTiles: function() {}
};
// set to true once the board has been setup
self.isSetup = false;
// quick access to square elements
self.squares = {};
self.squareCount = 0;
self.setup = function(options) {
self.log("Setting up board!");
// set options
_.each(options, function(val, key) {
self.options[key] = val;
});
return self;
})();
Some code from the middle has been omitted but this should give you the general idea.
What is the purpose of the the following: (function() { // code })(); Is this the module pattern that I've seen talked about? Is this meant to keep the global namespace clean?
What does this line mean?: var self = {} Is the self object used to exposed 'public' members? How would you define a private function or variable?
How would you instantiate multiple "Boards" if you wanted to?
It's called the Module Pattern.
The parentheses around the function mean it's being evaluated immediately after being defined -- so in essence it's a Singleton. Since it's an anonymous function, the definition is not stored - so you cannot readily create new instances of this object without a few modifications (which will be discussed later).
You are correct, self contains the "public" methods and properties, as it were. Any variables that aren't defined in self are not visible to the outside because of the closure properties. However, any functions defined in self still have access to the private variables because in Javascript, functions maintain access to the context (including variables) in which they were defined -- with a few exceptions.. mainly arguments and this.
If you want to define multiple instances of this object, you would remove the parentheses (var Board = function () { ... }) and then use var obj = Board() to create an object. Note that it does not use the new operator.
As mentioned in the other answer, that's the Module Pattern.
It is also known as the YUI Module Pattern or the Yahoo Module Pattern, mainly because it was made popular by this blog article:
YUI Blog: A JavaScript Module Pattern by Eric Miraglia
Regarding point 3, the Module Pattern is intended to be a singleton. However, the Module Pattern is easily transformed into a Constructor Pattern. You may want to check out the following presentation by Douglas Crockford for more information on this topic:
JavaScript: The Good Parts - Functional Inheritance [PPT] by Douglas Crockford
var self = {} should have the effect of initializing self as an empty object literal; if self already existed, it should delete the old values and reinitialize as an empty array.
Related
If a constructor and it's prototype are defined in the same module, say AMD module, is it acceptable to make class private fields global for the module to be accessible within prototype instead of defining them with underscore inside a constructor?
So is this better:
define(function (require) {
"use strict";
var steps = 0;
function Constructor(_steps) {
steps = _steps;
}
Constructor.prototype.go = function () {
steps += 1;
};
then this:
define(function (require) {
"use strict";
function Constructor(_steps) {
this._steps = _steps;
}
Constructor.prototype.go = function () {
this._steps += 1;
};
?
TL;DR: doesn't really matter (it's just a minor implementation detail)
Two different solutions. One isn't necessarily "better" than the other, they just have different use cases.
If you're using the constructor/prototype pattern, then it makes sense in an object-oriented sense to set the constructor parameters on the instance itself (using this.<whatever-prop>). When you instead decide to use the constructor only for the sake of its side effects (by setting someModuleVariable based on the parameter passed to the constructor), it can unnecessarily obfuscate the code.
Having a "private" variable that's accessible to the entire module, however, is an extremely common pattern... For example, when using singleton objects, because scoped variables are never destroyed when you leave the execution context of the function, the module can still query that "module-local" variable.
The only thing that rubs me the wrong way is using the constructor only for the sake of its side effects... why would I use a constructor then, when one of the main purposes of a constructor is the implicitly set properties on the instance?
To separate these two ideas, a common pattern is to use an init method inside of the prototype, because that's a good place to harbor all of your desired side effects. For example, one could suggest doing this:
var Module = (function() {
var somethingPrivate;
function SomeObject(someProp) {
// rely on the constructor to set instance properties
this.someProp = someProp;
}
SomeObject.prototype = {
init: function(_somethingPrivate) {
// all of your side effects in here, such as:
somethingPrivate = _somethingPrivate;
}
};
return SomeObject;
}());
var module = new Module('Hello world! I belong to the instance');
module.init('I am a module-specific variable!');
Of course, however, this isn't saying that there aren't circumstances where you might want to rely on a constructor for its side effects. But in the example you gave, it doesn't even look like a constructor is necessary (even though I understand the example is contrived just for the sake of demonstrating the problem).
Where and how you use _ underscores are mostly irrelevant, just as a side note. They're good in some cases, like to differentiate pseudo-private properties from "public" properties, but I think that's more of a convention than a pattern that's been set in stone.
I am already familiar with the module pattern where we define a module with private state with the funcitons closure and an exposed set of public methods. However this seems to be closer to a singleton than an object.
However what if i wanted a more object orientated pattern can I use the same structure as the module pattern but don't immediately execute, Something like this:
function MyPseudoClass(constructorArg0, constructorArg1... ) {
var privateVar = "private!!";
var privateComplexVar = constructorArg0;
var privateComplexVar1 = constructorArg1;
return {
publicVar: "public Varaible!",
publicMethod: function() {
//code
return privateVar + 1;
}
};
Now in my code i can create instances of my pseudo class like so:
var instance = MyPseudoClass({p : 2, q : 100},"x")
var anotherInstance = MyPseudoClass({p : 3, q : 230},"y")
As far as i can tell this seems to do what i want but i haven't seen anyone using this online, are there any downsides to this approach that i should be aware of?
You aren't using prototypical inheritance; that is the main difference. Your main drawbacks are:
You cannot use instanceof to ensure that a variable is of some type (so you cannot do myVar instanceof MyPseudoClass. You don't create an instance with this method; you just create an object.
A prototype-based approach might be faster as there is overhead associated with closures. Furthermore, in a prototyped approach, each instance will share can share the same instance of a function (that is assigned to the prototype). But in the closure approach, each "instance" will have its own copy of the function. However, the difference is small (especially in newer browsers).
If you aren't concerned about these drawbacks, you should be ok.
The problem with functional inheritance is that if you want to create many instances then it will be slow because the functions have to be declared every time.
The problem with prototypal inheritance is that there is no way to truly have private variables.
Is it possible to mix these two together and get the best of both worlds? Here is my attempt using both prototypes and the singleton pattern combined:
var Animal = (function () {
var secret = "My Secret";
var _Animal = function (type) {
this.type = type;
}
_Animal.prototype = {
some_property: 123,
getSecret: function () {
return secret;
}
};
return _Animal;
}());
var cat = new Animal("cat");
cat.some_property; // 123
cat.type; // "cat"
cat.getSecret(); // "My Secret"
Is there any drawbacks of using this pattern? Security? Efficiency? Is there a similar pattern out there that already exists?
Your pattern is totally fine.
There are a few things that you'd want to keep in mind, here.
Primarily, the functions and variables which are created in the outermost closure will behave like private static methods/members in other languages (except in how they're actually called, syntactically).
If you use the prototype paradigm, creating private-static methods/members is impossible, of course.
You could further create public-static members/methods by appending them to your inner constructor, before returning it to the outer scope:
var Class = (function () {
var private_static = function () {},
public_static = function () {},
Class = function () {
var private_method = function () { private_static(); };
this.method = function () { private_method(); };
};
Class.static = public_static;
return Class;
}());
Class.static(); // calls `public_static`
var instance = new Class();
instance.method();
// calls instance's `private_method()`, which in turn calls the shared `private_static();`
Keep in mind that if you're intending to use "static" functions this way, that they have absolutely no access to the internal state of an instance, and as such, if you do use them, you'll need to pass them anything they require, and you'll have to collect the return statement (or modify object properties/array elements from inside).
Also, from inside of any instance, given the code above, public_static and Class.static(); are both totally valid ways of calling the public function, because it's not actually a static, but simply a function within a closure, which also happens to have been added as a property of another object which is also within the instance's scope-chain.
As an added bonus:
Even if malicious code DID start attacking your public static methods (Class.static) in hopes of hijacking your internals, any changes to the Class.static property would not affect the enclosed public_static function, so by calling the internal version, your instances would still be hack-safe as far as keeping people out of the private stuff...
If another module was depending on an instance, and that instance's public methods had been tampered with, and the other module just trusted everything it was given... ...well, shame on that module's creator -- but at least your stuff is secure.
Hooray for replicating the functionality of other languages, using little more than closure.
Is it possible to mix functional and prototypical inheritance together and get the best of both worlds?
Yes. And you should do it. Instead of initializing that as {}, you'd use Object.create to inherit from some proto object where all the non-priviliged methods are placed. However, inheriting from such a "class" won't be simple, and you soon end up with code that looks more like the pseudo-classical approach - even if using a factory.
My attempt using both prototypes and the singleton pattern combined. Is there a similar pattern out there that already exists?
OK, but that's something different from the above? Actually, this is known as the "Revealing Prototype Pattern", a combination of the Module Pattern and the Prototype Pattern.
Any drawbacks of using this pattern?
No, it's fine. Only for your example it is a bit unnecessary, and since your secret is kind of a static variable it doesn't make much sense to me accessing it from an instance method. Shorter:
function Animal(type) {
this.type = type;
}
Animal.prototype.some_property = 123;
Animal.getSecret = function() {
return "My Secret";
};
Just saw some interesting code while doing a typo in 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've read alot about the module pattern in javascript and why its a bad thing (takes more memory, longer to create...) but of course the upside is having truly private functions/variables. Wouldn't the above code be a good way to create private functions (this wouldn't work for variables, unless you wanted static private variables) as the function is only created once in the closure?
One of the upsides of the module pattern is also the execution speed of functions as the code doesn't have to look up the prototype chain. Would this theoretically give the same speed improvements?
To highlight the points I was making, because clearly there was more to the question than just the title:
Yes a module pattern is a good and commonly used way to create private (er, local) data (functions or whatever), and export some sort of interface. Since a function is the only way to create variable scope, it's the only way to create private functions.
Because the functions will be shared by all objects created from Mamal, they're not useful for a functional inheritance pattern (references to functional inheritance have been removed from the question).
There's no performance improvement over lookups in the prototype chain, because the prototype chain needs to be traversed anyway just to get to your private functions.
To address specific questions points in the updated post:
"Would this be a good way to do private functions?"
Sure, but that's because having a function nested in another is the only way to scope a function.
"Now I've read alot about the module pattern in javascript and why its a bad thing..."
For a one-time use module, I don't see any issue. Also, any data referenced by variables that are no longer needed after the module function exits is free for garbage collection. This wouldn't be the case if they were global, unless you nullified them.
"...of course the upside is having truly private functions/variables..."
Yes, though some would take exception to the use of the word "private". Probably "local" is a better word.
"...this wouldn't work for variables, unless you wanted static private variables..."
Yes, though again some may take exception to the use of the word "static".
"Wouldn't the above code be a good way to create private functions...as the function is only created once in the closure?"
Yes again, nested functions are the only way to make them "private" or rather local.
But yes, as long as the function only ever needs to access the public properties of the objects (which are accessible to any code that can access the object) and not local variables of the constructor, then you should only create those functions once, whether or not you use a module pattern.
"One of the upsides of the module pattern is also the execution speed of functions as the code doesn't have to look up the prototype chain. Would this theoretically give the same speed improvements?"
No, you haven't exported your private functions directly, but rather the only way to call them is by traversing the prototype chain.
But if you ditched the prototype chain, and added functions as properties directly on the objects created, then you'd have some improvement there.
Here's 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've eliminated the prototype chain in the lookup of the test function, and also the wrapped function call, and you're still reusing the __priv_func.
The only thing left that is prototyped is the simple_var, and you could bring that directly onto the object too, but that'll happen anyway when you try to modify its value, so you might as well leave it there.
Original answer:
If you're talking about a module pattern, where you set up a bunch of code in (typically) an IIFE, then export methods that have access to the variables in the anonymous function, then yes, it's a good approach, and is pretty 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 don't see and advantage over a typical constructor, unless you decide to use the module pattern as above.
The way it stands right now, the identical functionality can be accomplished like this without any more global pollution, and without the 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 the above code be a good way to create private functions (this wouldn't work for variables, unless you wanted static private variables) as the function is only created once in the 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 too is only created once.
"One of the upsides of functional inheritance is also the execution speed of functions as the code doesn't have to look up the prototype chain. Would this theoretically give the same speed improvements?"
In your code, the function is called via a function in the prototype chain, so it has that same overhead, plus the overhead of finding the local function in the variable scope and invoking that function as well.
So two lookups and two function invocation instead of one lookup and one invocation.
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 function __priv_func is not only private, but also static. I think it's a good way to get private function if 'static' does not matter.
Below is a way to get 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
Looking at some JavaScript libraries and other people's code I've seen two common patterns, I don't know if there is a difference or advantage in using one of them. The patterns look sort of like this:
1.
var app = (function () {
// Private vars
// Module
var obj = {
prop: "",
method: function () {}
};
return obj;
})();
2.
(function () {
// Private vars
// Module
var obj = {
prop: "",
method: function () {}
};
window.app = obj;
})();
Are this patterns the same or do one of them has an advantage or different use than the other?
Thanks in advance.
The second assumes the existence of an object called window in the parent scope and assigns a property there.
The first one leaves it up to the caller to make the assignment, and does not depend on a window being defined (which it probably is only inside of a web browser).
So, I'd say the first one is definitely better (more self-contained, less environment-dependent).
tl;dr: pick one method and be consistent.
In my opinion, the first method has a slight advantage for readability. In my head, when I read it, I see that, "module app is being defined," and that everything inside of this closure belongs to that module. This is a natural decomposition for me and imposes the object oriented nature of the module about to be defined.
Another reason I favor the first method is that it is cleaner to change the scope into which a module is defined. Every module you define wont need to be part of the global scope. Using the second method, if the scope isn't injected by passing in a parent object as Jared Farrish illustrates with his jQuery example, then you run the risk of breaking your code if you decide to change the name of that parent object. This example illustrates the point:
var namespace = {
subns: { ... }
};
(function() {
var module = { ... };
namespace.subns.someModule = module;
}());
Anytime the identifiers namespace or subns change, you also have to update this module and any other module that follows this pattern and adds itself to the same object.
All in all, neither method one nor method two (with dependency inject) is "better" than the other, it is simply a matter of preference. The only benefit that can come from this discussion is that you should pick one method and be consistent.
They are both accomplishing the same thing, to create an object in the global namespace at the time the code is run.
One isn't more "hardcoded" than the other, since neither is doing any kind of function prototyping in which you could create clones of the object with the new keyword. It's just a matter of preference, in my opinion.
For instance, jquery does something akin to the latter:
(function( window, undefined ) {
// Use the correct document accordingly with window argument (sandbox)
var document = window.document;
var jQuery = (function() {
// Define a local copy of jQuery
var jQuery = function( selector, context ) {
// The jQuery object is actually just the init constructor 'enhanced'
return new jQuery.fn.init( selector, context, rootjQuery );
},
// Map over jQuery in case of overwrite
_jQuery = window.jQuery,
// Map over the $ in case of overwrite
_$ = window.$,
...
But Prototype JS Library does the former:
var Prototype = {
Version: '1.6.1',
Browser: (function(){
var ua = navigator.userAgent;
var isOpera = Object.prototype.toString.call(window.opera) == '[object Opera]';
return {
IE: !!window.attachEvent && !isOpera,
Opera: isOpera,
WebKit: ua.indexOf('AppleWebKit/') > -1,
Gecko: ua.indexOf('Gecko') > -1 && ua.indexOf('KHTML') === -1,
MobileSafari: /Apple.*Mobile.*Safari/.test(ua)
}
})(),
...
I don't know of any reason why one is better than the other, or that they accomplish their task differently (to create the app object in the window namespace).
In the first example, if app defined within another function, app will only be available in that local scope, whereas in the second example the app variable is explicitly assigned to the global scope.
In the second example, the app will only be assigned to the global scope if defined in the global scope outside of functions.
The second form has a slight advantage in that you have a completely self contained function; for example you could then have a standard header and footer for your JS files.
The part I'm not completely sold on is the local variable inside the block. I tend to prefer this:
(function () {
// Private vars
// Module
window.app = {
prop: "",
method: function () {}
};
})();
although that breaks down a bit when you're doing more than one thing, such as building up an object with multiple methods rather than a single object as in this example.