Javascript Design Patterns

tag and in the last one, we passed in an element. The result of all three were the same: we were returned a jQuery object referencing a DOM node.

It is worth noting that the $ variable adopts the Builder Pattern in jQuery. In each example, the jQuery DOM object has access to all the methods provided by the jQuery library (like .hide()and .show()), but at no point was document.createElement called because the JS library handled all of that under the hood.

Creating each DOM element and inserting content into it would have been tedious and time consuming. For example, to create the myDiv in plain JavaScript:

const myDiv     = document.createElement('div');
myDiv.id        = 'myDiv';
myDiv.innerText = 'This is a div.';

By making use of the builder pattern, we’re able to focus on the type and the content of the object, rather than explicit creation of it.

Structural Patterns

Facade

The aim of the facade pattern is to simply conceal a larger piece of logic into one simple function call. Internal subroutines and layers are well hidden and invoked through a facade which makes this pattern secure as it never exposes anything to the developers working with it. You might have probably used a facade without knowing. Check out the example below:

$(document).ready(function() {

// all your code goes here...

});

Whenever we use jQuery’s ready() method, we are actually implementing a facade. Let’s check out what actually goes on each time ready() is called. Here is the code in the jQuery library for how .ready() is implemented:

ready: (function() {

...

// Mozilla, Opera, and Webkit
  if (document.addEventListener) {
    document.addEventListener("DOMContentLoaded", idempotent_fn, false);
    ...
  }

// IE event model
  else if (document.attachEvent) {

// ensure firing before onload; maybe late but safe also for iframes
    document.attachEvent("onreadystatechange", idempotent_fn);

// A fallback to window.onload, that will always work
    window.attachEvent("onload", idempotent_fn);

...    
  }

})

To ensure that ready() is fired at the appropriate time, jQuery regulates all browser inconsistencies and presents developers with a simple interface. Mozilla, Opera, and Webkit will use the DOMContentLoaded event while IE has a different implementation. The end-user doesn't have to know the differences in browsers. They can just call .ready()!

Composites

Composites are objects composed of multiple parts that create a single entity. This single entity serves as the access point for all the parts, which, while simplifying things greatly, can also be deceiving because there’s no implicit way to tell just how many parts the composite contains.

Check out this jQuery example of a composite pattern:

$('.myList').addClass('selected');
$('#myItem').addClass('selected');

// dont do this on large tables, it's just an example.
$('#dataTable tbody tr').on('click', function(event) {
  alert($(this).text());
});

$('#myButton').on('click', function(event) {
  alert("Clicked.");
});

As we can see, jQuery uses the composite pattern to provide us with a simple application user interface. When using the composite pattern in JavaScript, it’s important to watch out for whether we are dealing with a single element or multiple elements because since the composite pattern uses the same interface for both, we can mistake one for the other and end up with unexpected bugs.

Behavioral patterns

Observer

The observer design pattern implements a single object which maintains a reference to a collection of objects and broadcasts notifications when a change of state occurs. When we don’t want to observe an object, we remove it from the collection of objects being observed.

Aside from being good at decoupling objects which promote smaller, reusable components, the observer pattern helps us pinpoint dependencies and requires a deeper level of thinking about the relationship between the various components of an application.

In the following illustration, we shall implement the observer pattern and we shall make use of three methods:

• publish(data): Called by the subject when it has a notification to make

• subscribe(observer): Called by the subject to add an observer to its list of observers

• unsubscribe(observer): Called by the subject to remove an observer from its list of observers

Most modern JavaScript libraries support these three methods as part of their custom events infrastructure. There’s usually the following methods:

• on()

• attach()

• trigger()

• fire()

• off()

• detach()

  var a = $({}); $.subscribe = a.on.bind(a); $.unsubscribe = a.off.bind(a); $.publish = a.trigger.bind(a);

  // Usage document.on('recordsReceived', function(records) { // perform some actions, then fire an event

  $.publish('recordsShow', records); });

  // We can subscribe to this event and then fire our own event. $.subscribe('recordsShow', function() { // display the records somehow ..

  // publish an action after they are shown. $.publish('recordsDisplayed); });

  $.subscribe('recordsDisplayed, function() { ... });

As can be seen above, the observer pattern is very simple to implement and very powerful. Due to the fact that it is naturally event based, JavaScript is well suited to use this pattern. Users should be cautious as this pattern can create problems if many subjects and observers are involved.

Constructor Pattern

This is a class-based creational design pattern. Constructors are special functions that can be used to instantiate new objects with methods and properties defined by that function. It is not one of the classic design patterns. In fact, it is more of a basic language construct than a pattern in most object-oriented languages. But in JavaScript, objects can be created on the fly without any constructor functions or “class” definition. Therefore, I think it is important to lay down the foundation for other patterns to come with this simple one. Constructor pattern is one of the most commonly used patterns in JavaScript for creating new objects of a given kind.

In this example, we define a Hero class with attributes like name and specialAbility and methods like getDetails. Then, we instantiate an object IronMan by invoking the constructor method with the new keyword passing in the values for the respective attributes as arguments.

Code

function Hero(name, specialAbility) {
  // setting property values
  this.name = name;
  this.specialAbility = specialAbility;

  // declaring a method on the object
  this.getDetails = function() {
    return this.name + ' can ' + this.specialAbility;
  };
}

// ES6 Class syntax
class Hero {
  constructor(name, specialAbility) {
    // setting property values
    this._name = name;
    this._specialAbility = specialAbility;

    // declaring a method on the object
    this.getDetails = function() {
      return `${this._name} can ${this._specialAbility}`;
    };
  }
}

// creating new instances of Hero
const IronMan = new Hero('Iron Man', 'fly');

console.log(IronMan.getDetails()); // Iron Man can fly

Factory Pattern

Factory pattern is another class-based creational pattern. In this, we provide a generic interface that delegates the responsibility of object instantiation to its subclasses. This pattern is frequently used when we need to manage or manipulate collections of objects that are different yet have many similar characteristics.

In this example, we create a factory class named BallFactory that has a method that takes in parameters, and, depending on the parameters, it delegates the object instantiation responsibility to the respective class. If the type parameter is "football" or "soccer" object instantiation is handled by Football class, but if it is "basketball" object instantiation is handled by Basketball class.

class BallFactory {
  constructor() {
    
  }
  createBall(type) {
      let ball;
      if (type === 'football' || type === 'soccer') ball = new Football();
      else if (type === 'basketball') ball = new Basketball();
      ball.roll = function() {
        return `The ${this._type} is rolling.`;
      };

      return ball;
  };
}

class Football {
  constructor() {
    this._type = 'football';
    this.kick = function() {
      return 'You kicked the football.';
    };
  }
}

class Basketball {
  constructor() {
    this._type = 'basketball';
    this.bounce = function() {
      return 'You bounced the basketball.';
    };
  }
}

// creating objects
const factory = new BallFactory();

const myFootball = factory.createBall('football');
const myBasketball = factory.createBall('basketball');

console.log(myFootball.roll()); // The football is rolling.
console.log(myBasketball.roll()); // The basketball is rolling.
console.log(myFootball.kick()); // You kicked the football.
console.log(myBasketball.bounce()); // You bounced the basketball.

Singelton Pattern

Singleton is a special creational design pattern in which only one instance of a class can exist. It works like this — if no instance of the singleton class exists then a new instance is created and returned, but if an instance already exists, then the reference to the existing instance is returned.

A perfect real-life example would be that of mongoose (the famous Node.js ODM library for MongoDB). It utilizes the singleton pattern.

In this example, we have a Database class that is a singleton. First, we create an object mongo by using the new operator to invoke the Database class constructor. This time an object is instantiated because none already exists. The second time, when we create the mysql object, no new object is instantiated but instead, the reference to the object that was instantiated earlier, i.e. the mongo object, is returned.

var Singleton = (function () {
    var instance;
 
    function createInstance() {
        var object = new Object("I am the instance");
        return object;
    }
    return {
        getInstance: function () {
            if (!instance) {
                instance = createInstance();
            }
            return instance;
        }
    };
})();
function run() {
    var instance1 = Singleton.getInstance();
    var instance2 = Singleton.getInstance();
    alert("Same instance? " + (instance1 === instance2));  
}