JavaScript design patterns

Objective

This article will:

• Get you accustomed to Javascript patterns
• Explain why you should consider using design patterns in your next Javascript project

For some of the projects I built in the past, I only used Javascript patterns because I thought they looked fancy, not because they added anything meaningful to the experience.

I want to help you avoid the same mistake.

It might seem obvious, but there really should be a good reason for using a particular type of design pattern.

Why consider using a design pattern in Javascript?

A pattern is a reusable solution that can be applied to commonly occurring problems in software engineering.

Using a design pattern helps reduce the time spent on how the code should look.

Not only that, a good design pattern enforces the DRY (Do not Repeat Yourself) concept that helps to prevent your codebase from growing large and unwieldy.

Design patterns also help team members collaborate, especially in a situation where everyone on the team is familiar with the pattern in question. Every team member will definitely communicate better while handling a uniform style (pattern) in building up a project.

How can you recognize a good design pattern?

As funny as this may sound, a good pattern needs to have a name and a precise, detailed structure. This is not at all the same as mere habits.

Every developer has a way of solving a specific problem (file upload, for example). When a file needs to be handled in any of our projects, we gladly rush to implement this specific solution.

Can we call this a pattern? Definitely not. A good or accepted design pattern must be related with existing patterns. Not only that, it must be approved by other developers.

Examples of how the pattern can be used and a detailed documentation cannot be overemphasized.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

Design pattern categories

Let’s take a quick dive into some of the major Javascript design patterns. We will be considering just six (6) patterns in this article:

• Constructor pattern
• Prototype pattern
• Module pattern
• Singleton pattern
• Factory pattern
• Observer pattern

1. Constructor pattern

This is one way to create a constructor pattern:

function Animal (name) {

    this.name = name;

    this.properties = function() {
        console.log(`This ${this.name} can walk`);
    }
}


const animalOne = new Animal('Dog');
const animalTwo = new Animal('Cat');

console.log(animalOne.name); //Dog
console.log(animalTwo.name);
animalOne.properties(); //This Dog can walk
animalTwo.properties(); //This Cat can walk

For you to access the properties of a function in a constructor pattern, it needs to be initialized. This pattern is useful when thinking about Object Oriented Design.

const object = new ConstructorObject();

The keyword new tells Javascript that ConstructorObject should behave like a constructor. One of the drawbacks of this pattern is that it does not support inheritance. A property shared among different objects will always be repeated.

2. Prototype pattern

In constructor pattern, the method or property set in the object is always redefined when it’s called upon. A better way to resolve this is to create a function inside the prototype function.

With this in place, functions called on instantiation won’t redefine themselves. But a prototype pattern also has a downside. A property is easily shared among all functions even when it’s not needed. You don’t have control over your properties being private or public. It’s automatically public:

function Animal(name) {
    this.name = name;
}

Animal.prototype.properties = function() {
    console.log(`This ${this.name} can walk`);
};

const animalOne = new Animal('Dog');
const animalTwo = new Animal('Cat');

console.log(animalOne.name); //Dog
console.log(animalTwo.name);
animalOne.properties(); //This Dog can walk
animalTwo.properties(); //This Cat can walk

3. Module pattern

Module pattern is a bit of an improvement over prototype pattern. In module pattern, you can set different types of modifiers (both private and public). There is a huge chance one won’t run into conflict in creating the same functions or properties.

You also have the flexibility of re-naming the functions publicly just like we re-named addAnimal function to add. The downside here is the inability to override the created functions from an outside environment. removeAnimal function can’t be overridden from outside without depending on the private property container array:

function AnimalContainter () {

    const container = []; 

    function addAnimal (name) {
        container.push(name);
    }

    function getAllAnimals() {
        return container;
    }

    function removeAnimal(name) {
        const index = container.indexOf(name);
        if(index < 1) {
            throw new Error('Animal not found in container');
        }
        container.splice(index, 1)
    }

    return {
        add: addAnimal,
        get: getAllAnimals,
        remove: removeAnimal
    }
}

const container = AnimalContainter();
container.add('Hen');
container.add('Goat');
container.add('Sheep');

console.log(container.get()) //Array(3) ["Hen", "Goat", "Sheep"]
container.remove('Sheep')
console.log(container.get()); //Array(2) ["Hen", "Goat"]

4. Singleton pattern

As interesting as the above patterns are, they can’t be used in scenarios where only one instance is needed. Let’s take a look at database connection. You can’t keep on creating an instance of database when it’s already created. You either create a new instance when it’s closed or stop the ongoing instance to create a new one.

Singleton pattern ensures the instance of an object is only created once. It’s also known as the strict pattern. A downside to this pattern is that it is difficult to test. There are hidden dependencies objects, which are difficult to single out in order to test:

function DatabseConnection () {

    let databaseInstance = null; 

    // track number of times the instance is created 
    let count = 0; 

    function init() {
        console.log(`Opening databse #${count + 1}`);
        /**
         * perform operation 
         */
    }

    function createIntance() {
        if(databaseInstance == null) {
            databaseInstance = init();
        }
        return databaseInstance;
    }

    function closeIntance() {
        console.log('closing database');
        databaseInstance = null;
    }

    return {
        open: createIntance,
        close: closeIntance
    }
}

const database = DatabseConnection();
database.open(); //Opening databse #1
database.open(); //Opening databse #1
database.open(); //Opening databse #1
database.close(); //closing database

database.open() from DatabaseConnection object will keep returning 1 because the instance was created only once.

5. Factory pattern

This pattern ensures objects are created with some sort of generic interface. We can specify the type of object we want to create from interface object. Let’s assume we want to handle users payment using multiple vendors(Vendor A, Vendor B … Vendor n). The goal of each vendor is to ensure payment is successfully carried out.

In this kind of scenario, the Factory pattern is our best bet. We won’t have to overthink how payment will be carried out irrespective of the vendor being used at a particular time.

Factory pattern provides an interface where we can specify the type of vendor we want to use in handling payment at each point in time:

/**
 * Vendor A
 */
VendorA = {};

VendorA.title = function title() {
  return "Vendor A";
};

VendorA.pay = function pay(amount) {
  console.log(
    `setting up configuration using username: ${this.username} and password: ${
      this.password
    }`
  );
  return `Payment for service $${amount} is successful using ${this.title()}`;
};

/**
 *Vendor B
 */
VendorB = {};
VendorB.title = function title() {
  return "Vendor B";
};

VendorB.pay = function pay(amount) {
  console.log(
    `setting up configuration using username: ${this.username} 
        and password: ${this.password}`
  );
  return `Payment for service $${amount} is successful using ${this.title()}`;
};

/**
 *
 * @param {*} vendorOption
 * @param {*} config
 */

function VendorFactory(vendorOption, config = {}) {
  const vendor = Object.create(vendorOption);
  Object.assign(vendor, config);
  return vendor;
}

const vendorFactory = VendorFactory(VendorA, {
  username: "test",
  password: "1234"
});
console.log(vendorFactory.title());
console.log(vendorFactory.pay(12));

const vendorFactory2 = VendorFactory(VendorB, {
  username: "testTwo",
  password: "4321"
});
console.log(vendorFactory2.title());
console.log(vendorFactory2.pay(50));

Vendor A
setting up configuration using username: test and password: 1234
Payment for service $12 is successful using Vendor A

............................................................
Vendor B
setting up configuration using username: testTwo and password: 4321
Payment for service $50 is successful using Vendor B

In the factory pattern snippet above, we have two vendors (A and B). The client interfacing with VendorFactory need not to worry about which method to call when switching between vendors.

There is no point in using factory pattern if we don’t really want to create multiple instances of the same object. It would rather make the whole solution more complex.

6. Observer pattern

Observer pattern is useful in cases where an object needs to communicate with some sets of other objects at the same time. Imagine you need to sync an update across many components due to some changes.

Observer pattern prevents unnecessary push and pull of events across states. It notifies the modules involved by modifying the current state of the data:

function Observer() {
    this.observerContainer = [];
}

Observer.prototype.subscribe = function (element) {
    this.observerContainer.push(element);
}

/**
 * removes an element from the container
 */
Observer.prototype.unsubscribe = function (element) {

    const elementIndex = this.observerContainer.indexOf(element);
    if (elementIndex > -1) {
        this.observerContainer.splice(elementIndex, 1);
    }
}

/**
 * notifies all the element added to the container by calling 
 * each subscribed components added to the container
 */
Observer.prototype.notifyAll = function (element) {
    this.observerContainer.forEach(function (observerElement) {
        observerElement(element);
    });
}

Let’s take a look at an example to demonstrate observer pattern:

A user types a random number in an input field and the number gets modified and is displayed on two different documents.

This can also be achieved in AngularJS using two-way binding, which makes use of Observer pattern under the hood:

    <body style="text-align: center; margin-top: 40px;">

        <input
            type="number"
            class="number-input"
        >
        <br>
        <br>

        <small>Number multiplied by 2</small>
        <p class="document-one">0</p>
        <button id="subscribe-one">Subscribe</button>
        <button id="unsubscribe-one">UnSubscribe</button>

        <br>
        <br>
        <small>Number multiplied by 4</small>
        <p class="document-two">0</p>
        <button id="subscribe-two">Subscribe</button>
        <button id="unsubscribe-two">UnSubscribe</button>
    </body>

observer view

Let’s interact with the elements we created to demonstrate observer pattern.

The observable container (observerContainer) handles how events are stored, retrieved and removed.

A view where the user gets to add a random number which is displayed ondocumentOne(number displayed is multiplied by two) and documentTwo (number displayed is multiplied by four).

Also, there are subscribe and unsubscribe buttons to modify the state of each document to display the modified random number.

The first set of two buttons (subscribe and unsubscribe) updates the display on the documents (<p></p>), the displayed is altered by removing the update operation from the observerContainer by clicking the unsubscribe button.

The same operation is applicable to the next two buttons (subscribe and unsubscribe):

http://observers.js

     /**
         * get the reference of the views (input, display One and display Two using class name)
         * */
        const input = document.querySelector('number-input');
        const documentOne = document.querySelector('.document-one'); 
        const documentTwo = document.querySelector('.document-two');


        /**
         * operation to manipulate user input for document one 
         * */
        const updateDocumentOne = function(text) {
            documentOne.textContent = parseInt(text) * 2;
        }

        /**
         * operation to manipulate user input for document two
         * */
        const updateDocumentTwo = function(text) {
            documentTwo.textContent = parseInt(text) * 4;
        }

        const observable = new Observer();
        observable.subscribe(updateDocumentOne);
        observable.subscribe(updateDocumentTwo);

        document.querySelector('.number-input').addEventListener('keyup', function(event){
            observable.notifyAll(event.target.value);
        });

        /**
         * modify subscriptions upon a click of a button
         * */
        document.getElementById('subscribe-one').addEventListener('click', function() {
           observable.subscribe(updateDocumentOne);
        });
        document.getElementById('unsubscribe-one').addEventListener('click', function() {
           observable.unsubscribe(updateDocumentOne);
        });
        document.getElementById('subscribe-two').addEventListener('click', function() {
           observable.subscribe(updateDocumentTwo);
        });
        document.getElementById('unsubscribe-two').addEventListener('click', function() {
           observable.unsubscribe(updateDocumentTwo);
        });

This is a demo on how we demonstrated the use of observer pattern. The source code can also be found here.

If you need to update your view on a simple project, you may want to consider using an observer pattern rather than using a framework.

One of the downsides in observer pattern is difficulty in testing for different scenarios.

Conclusion

Design patterns are highly recommended for Javascript developers. They ensure projects are easily maintained and prevent unnecessary work.

For further reading, I highly recommend Learning Javascript Design Patterns by Addy Osmani.

LogRocket: Debug JavaScript errors more easily by understanding the context

Debugging code is always a tedious task. But the more you understand your errors, the easier it is to fix them.

LogRocket allows you to understand these errors in new and unique ways. Our frontend monitoring solution tracks user engagement with your JavaScript frontends to give you the ability to see exactly what the user did that led to an error.

LogRocket records console logs, page load times, stack traces, slow network requests/responses with headers + bodies, browser metadata, and custom logs. Understanding the impact of your JavaScript code will never be easier!

Try it for free.