Structuring code using modules
The idea behind using modules is that when building a website or application you want to keep different bits of functionality separate from each other. This is so one piece of functionality does not interfere with another and changes to one part of the system do not affect another part thereby improving the maintainability of the system. This is known as “separation of concerns” and has an added benefit of making it simpler to test different components of your application.
myApp if it has already been declared somewhere else. If it’s already been declared we just use that existing object otherwise we simply declare a new object.
if...else statement is to make sure we don’t overwrite
slideShow property if it already exists.
Addy Osmani has a good post explaining more about namespacing patterns.
The first of our module examples is the object literal method. With this approach we can attach each of our module’s variables and methods as properties to an object literal. For example:
This is a very simple way of encapsulating and organising a module. It is also fairly straightforward to unit test your module’s behaviour since all of its properties are exposed.
init method with
myApp.slideShow.init = null which would break the module entirely. With ES5 you could mitigate this problem by using
Object.seal which would prevent any of the module’s properties from being changed and stop new properties from being added to the module.
Another downside is that it is cumbersome when trying to refer to the module’s variables and methods. You’ll notice in the code above any time I want to use one of these properties I have to preface it with
this.[NAME OF PROPERTY]. In addition, you always have to be careful of the context in which a property is referenced (i.e. what the
this value is bound to). Often you will need to store the
this value in another variable so that it can still be referred to if a function’s context is different (e.g. the
init function above).
In this example rather than using an object literal we simply declare a function which encapsulates the behaviour of our module. We can use closures to refer to private variables and methods and ensure that our module cannot be tampered with. Here is the code:
If we want to expose some of our module’s methods or variables we can use an immediately-invoked function expression (IIFE) instead and then return an object which contains these methods. For example:
Unlike object literals this pattern guarantees privacy for all of the functions and variables we want to keep hidden from other modules. This approach also makes it convenient to refer to these variables (we don’t have to worry about the
Since so much of our module’s behaviour is hidden it can be difficult to unit test.
Revealing module pattern
This approach is very similar to the module pattern except that we reveal a module’s private methods and variables by returning an object which has pointers to them. For example:
You’ll notice in this example we have a
newSlidePublic function that calls a private function. We then add this
newSlidePublic function to our returned object which reveals the private function when we make a call to
This pattern has many of the same advantages as the module pattern, however, since we reveal private functions and variables we can more easily unit test the behaviour of this module.
With this approach we create functions whose sole purpose is to point to private functions which results in some code bloat.
In this post we’ve looked at different approaches for organising and maintaining our jQuery code: object literals, the module pattern and the revealing module pattern. It is quite simple to add some structure to your application using one of these methods and will result in more maintainable and robust code.