Wednesday, June 13th, 2007
A JavaScript Module Pattern
Category: Articles, JavaScript
Eric discusses the steps:
- Create a namespace object: If you’re using YUI, you can use the YAHOO.namespace() method
- Assign the return value of an anonymous function to your namespace object
- Add “private†methods and variables in the anonymous function prior to the return statement
- Do something useful with the pattern
JAVASCRIPT:
-
-
YAHOO.myProject.myModule = function () {
-
-
//"private" variables:
-
var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule."
-
-
//"private" method:
-
var myPrivateMethod = function () {
-
YAHOO.log("I can be accessed only from within YAHOO.myProject.myModule");
-
}
-
-
return {
-
myPublicProperty: "I'm accessible as YAHOO.myProject.myModule.myPublicProperty."
-
myPublicMethod: function () {
-
YAHOO.log("I'm accessible as YAHOO.myProject.myModule.myPublicMethod.");
-
-
//Within myProject, I can access "private" vars and methods:
-
YAHOO.log(myPrivateVar);
-
YAHOO.log(myPrivateMethod());
-
-
//The native scope of myPublicMethod is myProject; we can
-
//access public members using "this":
-
YAHOO.log(this.myPublicProperty);
-
}
-
};
-
-
}(); // the parens here cause the anonymous function to execute and return
-
Note that this technique is very generic, and you can do the same thing with other frameworks, or without any frameworks!
Related Content:
- Developing secure enterprise Java applications
Java applications are not immune to web atacks; but there are steps you can take now to ensure your applications' security -- before attackers set... - JavaOne2006 - Day1
Sun discusses how proud they are at Java's adoption by software developers and announced new open source licensing-related agreements for... - Can I use standard design patterns in LotusScript?
4.1 rating from 46 votes
Why are the public methods set directly on the object instead of on the object’s prototype? That means if I have multiple instances of that object, they can’t share the same methods (through the prototype) and each object must carry it’s own method! That is memory intensive!
@Jordan
This is meant to be a singleton pattern.
I really hope this takes off. I’ve been doing very similar for a while now, but I definitely feel like a lone man in the sea of functions only JS programming.
Can anybody explain the advantages over simple stuff like
[code]
YAHOO.myProject.myModule =
{
myNotSoPrivateVar: "",
myPublicProperty: "",
myPublicMethod: function(){}
};
[/code]
why do i want private variables?
Might as well as why you even need objects.
@Matthew: Yes. Yes it is. They may have just had an oversight of the post. But to their own benefit, they put the name of “module pattern” to it. It was in fact a pattern that I learned when I was at Y! so it’s all good.
@Ivan: I don’t see how that follows. I think Teun’s question is valid, especially considering one can create private variables within Teun’s myPublicMethod() the same way one could create them within YAHOO.myProject.myModule();
@Jordan
Exactly.
An untyped object with an anonymous constructor.
YUI loves anonymous functions and I don’t know why. It is a real pain in the neck to debug “anonymous” or “no name” in the debugger.
Now please look at the code and notice that the object’s public interface is returned. All the “public” members are at the very bottom. Is this not completely backwards?
This is Doug’s “power constructor” renamed. Doug is a nice man and I don’t hate him. It is not a good practice.
The way to enforce an entryPoint is with Function.prototype.caller. This is not very hard to do and makes a private constructor, lazy-load singleton possible.
Opera chooses to support wacky css instead of critical properties like Function.prototype.caller. Opera should fix this bug. Ian, Anne…
Function.prototype.caller can also be used to debug errors, and even build-your-own error stack by looking up the call chain. (Error.stack is natively supported in FireFox and Webkit)
Yes, Dustin, a lot of people at Yahoo do in fact use that approach and I am sure that it came from Doug. I have tried to explain my best why it is not good. I hope it makes sense to others.
I love it how JavaScript developers are always coming up with weird patterns and conventions pretending to try and make it behave like an enterprise capable language. Actually they seem to be openly participating in a form of elitism, a close-knit club if you like.
JavaScript is a very capable OOP language, and encapsulation is one of the three tenants of OOP. Some people here say this is a singleton pattern. To me this whole construct should just be a function. I mean seriously… if you think you need private members in JavaScript you are on the wrong track. JavaScript is just a glue language for a presentation tier, no business logic.
Your “private method†is actually an anonymous function assigned to a variable inside another function i.e. a closure which should be avoided anyway. This “method†probably won’t even be called from the scope of the object instance.
And this module returns an object literal with another anonymous function?!
Excuse me but in middleware the biggest priority should be maintainability and this would seem to be a failure in that respect.
Tim, I think you’ve missed the point of Design Patterns in general. Any language will have certain features built-in that will be Design Patterns in another language. For example, C++ has class-based inheritance built-in but prototype-based inheritance is a design pattern (see gang of four). In JavaScript the prototype-based inheritance is built-in and class-based inheritance is a design pattern. To the JavaScripter the prototype-based inheritance design pattern in “an enterprise capable language” will look like a weird pattern pretending to look like Self or JavaScript. So if someone wants to use a module in JavaScript, at least until JavaScript 2, they use a design pattern.
Peter,
Actually I am an advocate of design patterns. However patterns are not designed to conceptualise missing features of a language, rather allow developers to communicate using well-known, well understood constructs for software interactions.
I realise I am being ambigious and perhaps what I have just said would back up the pattern used above.
My issue with this pattern is that it’s gratuitous. Patterns for the sake of patterns are bad because they add an unnessecary level of abstraction which only reduces maintainability further.
I guess this is pretty subjective so don’t take this as a statement, rather my opinion on the matter.
Tim
Tim,
I think that in many cases design patterns are exactly to add in “missing” features of a language. For example, Smalltalk classes all inherit from a class with Subject and Observer interfaces. Perl has modules and exporting like the pattern described here. C++ has template classes. Java has interfaces. JavaScript has prototype-based inheritance. All of these concepts could be useful at some point in another language where it is missing. People were using classes and inheritance in C before any object-oriented language had sugar for class definition.
I agree that this module pattern in JavaScript can be gratuitous at times. It doesn’t create indestructible objects with truly private/protected anything. It can keep the global name space less cluttered. It also teaches the idea of closure and automatically evaluated functions which is very useful. I use it relatively frequently when working around browser issues to produce efficient functions that don’t determine the browser-appropriate algorithm each time a function is called.
It is all subjective.
> It also teaches the idea of closure and automatically evaluated functions which is very useful.
Closures are powerful, useful, yes. Necessary here? hardly.
Knowing when not to use one is as important as knowing what a closure is.
>It can keep the global name space less cluttered.
Singleton (and this bastardized version) does little to keep the global namespace clean, though this is not really relevant to the javascript/web-paradigm, where there is library code and implementation code.
In fact, if your main goal is to keep the global nameppace clean, use a just
create one approach (hardly necessary for most JS).
There is a much better way to write a Singleton using lazy-load approach and enforcing an entryPoint to the constructor.
One more problem with the “power constructor”: There is extra memory allocation and worse performance due to closed scope. References to inner function objects are assigned to to the public properties of a constructed object.
Closures should be used where they are needed and ONLY where they are needed. For example: event registry/broadcast adapter/change manager/notification system, or adding advice (not generally recommended). Closure is hardly necessary here.
I made a syntactically nice version of this with support for instances as well. Check it out: http://blog.quimble.com/?p=114 (is the writeup).
http://wiki.s2807.gridserver.com/JavascriptTechnique is the code.
I can’t stand looking at my old code that doesn’t use any of these principles. This has completely changed the way I write JavaScript.
On mine page there is other concept of getting private members… Just check it and tell me what you think.
http://wilq32.googlepages.com/wilq32.class
How does private methods can call public members?
I find it better and more useful than what was discussed at the YUI blog. Thanks
This pattern is one of the most useful patterns I’ve ever learnt. I truly respect Douglas Crockford as a good teacher, and thanks Aajxian for this great post.