The Module Pattern, A Little More Detail
thiskeyword, and the associated problem of rebinding functions to another
- You can keep truly internal ‘states’ of your code private while exposing minimal APIs that you know will stay stable.
- You can avoid the sneaky problems of users forgetting the
newkeyword, and the workarounds people use to dodge them
- Once you understand scopes, you understand this pattern.
- Impress your friends.
To be clear, I adopted the style of the module pattern used by Mike Bostock, who presumably got it from earlier figures, and so on. Usually the variable-containing and scope-control bits of this pattern get the most attention - this sheds some light on other benefits that touch browser and async code as well.
this to refer to ‘this instantiated object’.
Car(). Notice that, unlike the
prototype method, there’s no
A Quick Summary
What are the essential bits?
1. No More This
The most common annoyance with
this is in event handlers, because they turn this into the element that’s the source of the event.
So let’s say that you’re creating a simple counter, that attaches to a DOM element being clicked. The classical version might look like
This looks valid, but isn’t. Clicking on
increment repeatedly and then on ‘tell’ will tell you that Counter’s value is still 0. Why? Because
Counter.prototype.increment runs, but the value of
this in that context is the DOM element of the
increment button, not counter.
A typical fix to this is to change the line to include
bind, a function that changes the value of
this in a function for any time that it runs in the future. Since this isn’t IE-safe, it’s more popular to use
_.bind from underscore.js or
bindAll that let you rebind a whole bunch of functions at one time, so you can totally forget about the
this problem. But it’s still there, and when your code leaves that land, it’s a valid annoyance.
Here’s the other way to do this functionality:
2. Internal And External States
This is a mixed bag, but there are some good examples of why it’s awesome. Let’s say you have a library that manages a set of markers on a map.
Of course, this will require the functionality of adding a marker to the map. With a classical object, in most cases an uninformed or adventurous user could see that
.markers is exposed and just
.markers.push(newmarker) it into the object.
The literal pattern lets you be much more paranoid, with a setup like
For instance, the code
internalFunctionTwo to single-letter names - there’s no way that you’ll be able to access them, so the names can change. By contrast, after minifying the code:
The long function names
internalFunctionTwo will remain in their entirety.
This method is slower for certain cases
- The power to have private methods and variables can be abused
- Extending objects is unclear
- Object identities is unclear -
This may have higher memory usage, because creating new objects can create new copies of their members.
As far as speed. Creating object literals is faster than instantiating objects with constructors in most browsers, as this jsperf test from Mike Bostock shows.
But dispatching method calls on those objects is slower.
In V8, small, prototype-based objects tend to out-perform literal objects created with the module pattern - good insights can be found in [this bit of Lars Bak's talk on the subject](https://www.youtube.com/watch?v=hWhMKalEicY&feature=youtu.be&t=48s) and the aha moment for objects versus arrays came from reading this bit of pre3d.js.
As far as the abusable power to do private members. There can be the feeling that you start off with an object like
And end up exposing a, b, and c, after realizing that private things couldn’t be private. So, if nothing else, this method requires an extra thought process to consider the level of encapsulation needed.
I rarely encounter the problem of really extending classes. Ben Cherry’s linked article has one possibility, and you can also just use an object that uses another object internally - like how Wax’s
As far as the
instanceof problem - with classical objects, when you call
var x = new baseballbat(), then
x instanceof baseballbat returns
x instanceof foo returns
false. Every once in a blue moon this is handy, but it often runs into the same problems as strongly-typed languages, in which direct class-equivalence isn’t all that importance and it’s more likely you want to ask whether the object has methods or properties you need in your code, not its origin.
For instance, in a large-scale project like Carto, which required object identities, a chain of inheritance meant that the only sensible way to do identity was to add a
.is member with a flag telling what the value should be interpreted as. Except in the most extreme cases, I don’t see much
instanceof use in the wild.
For objects that you’ll want thousands of, it might be a better option to either go with literal objects - for instance, the data types in Modest Maps would probably become simple arrays and their methods could easily become part of a singleton object. John Firebaugh confirmed this with a test that shows that for objects with many functionst that are initialized many times, there’s a serious (5x) difference in memory usage, due to more heap closures. So, it makes sense to use the module pattern for smaller objects, like UI widgets, map objects, and so on, while other techniques work well for atomic data, like pixel measures or nodes in a tree.
- Towards Reusable Charts by Mike Bostock
- Vish Uma switched to the module pattern and from it back to classical objects. His writing reminded me of the possible memory issue, so that section was added.
Have more ideas on this subject? Let me know over email or by tweeting at