Learning JavaScript Design Patterns

When I first learned javascript, I mainly used the jQuery library for small interactions (select something/do something) and adding very basic behavior to the websites I worked on. At the time, it was no big deal to just throw all of my simple jQuery methods and functions in a .js file and be done with it. Today, most of the web projects I work on tend to have significantly more complex behavior than just “select something/do something”, utilizing multiple libraries (Angular, Kendo, Backbone, etc.) with multiple developers involved. As I write more and more JavaScript, I’m finding it increasingly important to have some structure in your code for a couple of reasons:

• Structure makes your code easier to read and understand
• Properly structured code encourages best practices and maintainability

Recently I’ve been learning about design patterns to help structure my code and provide some guidance for certain types of complex solutions. If you’re not familiar with the concept, design patterns are reusable solutions to commonly occurring problems in software design. Most design patterns follow a predefined form and structure, taking advantage of the combined knowledge and experience of many developers that came before us.

Addy Osmani, a Google Engineer working on the Chrome team, has written an excellent book on the subject called Learning Javascript Design Patterns available free online. The book contains much about the history of Javascript Design patterns with code examples and pros/cons of using each in different types of projects. The most basic and essential pattern for anyone new to to the subject is the Module pattern, which I’ve been using on most of my projects recently.

The Module Pattern

The basic concept behind the Module pattern is to help keep individual units of code organized and separated. The pattern is based on using an IIFE, a self-contained function (providing encapsulation for your code), that returns an object exposing specific methods (providing a public API). This is a really important design pattern, since one of the “bad parts” about JavaScript is that all objects & variables not encapsulated are placed in the global namespace, making them vulnerable to other parts of your code. The module pattern encapsulates variables, functions, and states using closures, shielding your module logic from the outside world. This keeps everything in the closure private, while returning public variables and functions for interacting with the module from other parts of your code. Below is an example template of the basic module pattern:

var myNamespace = (function() {
  var myPrivateVar, myPrivateMethod;
  // A private counter variable
  myPrivateVar = 0;
  // A private function which logs any arguments
  myPrivateMethod = function( foo ) {
      console.log( foo );
  };
  return {
    // A public variable
    myPublicVar: "foo",
    // A public function utilizing privates
    myPublicFunction: function( bar ) {
      // Increment our private counter
      myPrivateVar++;
      // Call our private method using bar
      myPrivateMethod( bar );
    }
  };
})();

In the example above, we define a namespace for the module, private variables and methods (created via function-level scoping, ie. closure) as well as public variables and methods being returned as an object. The private variables and methods are completely shielded from the global scope, while still accessible through the public methods. Public methods are namespaced and can be called using dot notation as follows:

myNamespace.myPublicFunction('yo');

Thhis pattern is the basis for other module design patterns, including a variant that I use in production today called the revealing module pattern.

The Revealing Module Pattern

This pattern is essentially the same as the module pattern above, except all of the functions and variables are defined in the private scope, and we return an object with pointers to the private functionality that we wish to make public.

var myRevealingModule = (function() {
        var privateCounter = 0;
        function privateFunction() {
            privateCounter++;
        }
        function publicFunction() {
            publicIncrement();
        }
        function publicIncrement() {
            privateFunction();
        }
        function publicGetCount(){
          return privateCounter;
        }
        // Reveal public pointers to 
        // private functions and properties        
       return {
            start: publicFunction,
            increment: publicIncrement,
            count: publicGetCount
        };
    })();

The main advantage to this approach is organization and readability. With this approach, we can also define a more specific naming scheme for the module for public methods.

myRevealingModule.start();

Learning these design patterns has helped significantly in my understanding and implementation of coding standards and best practices. It has also made writing JavaScript a lot more fun, because it allows me to think about problem solving more creatively and promotes code re-use.

If you have any experience with learning about design patterns, specifically related to JavaScript, I’d love to hear about it.

Resources:

• Learning JavaScript Design Patterns by Addy Osmani
• JavaScript: The Good Parts by Douglas Crockford