hackajob Insider

All You Need to Know About JavaScript Design Patterns

Written by hackajob Staff | Aug 28, 2021 11:00:00 PM

Whether you're new or advanced in JavaScript, you'll have heard of Design Patterns – and if you haven't, that's what we're here for. It can come in handy during system design questions or during a technical interview. And as many (many!) tech companies are hiring for JavaScript Developers via hackajob currently, you could put yourself ahead of the curve by getting to grips with these design patterns.

So what are they? Design patterns are solutions to common problems that arise in software engineering. ‘The Gang of Four’ design patterns published over 20 years ago still remains relevant, still being a bestseller on Amazon. Today, we'll look at some common design patterns in JavaScript. Let's get started.

Why Design Patterns?

  • Highly reusable and proven – Design patterns are reusable solutions to problems that have already been solved. This makes them less vulnerable to errors since a countless number of developers are already using it.
  • Reduces code debt and size of the codebase – Design patterns are efficient solutions; therefore, they reduce the need for refactoring. Since they are efficient solutions, the number of lines of code is also considerably lesser, which reduces the size of the codebase.
  • Easy to explain to peers, vast documentation – Design patterns have been in use for quite a while. Due to this, if there's ever a need to explain a solution to a peer, there is an ample number of resources available. Not just that, due to the number of resources available, it makes it easier to get started with design patterns as well.

Singleton Pattern

When you need just a single instance of a class, we use the singleton design pattern. This is extremely useful when you need to configure something in your application because it doesn’t require multiple instances of the class. Below is a simple representation of the singleton pattern in JavaScript.

Try this code

If you see in the code snippet above, we have two instances of Singleton. It spawns off instances every time it is called, but each time it is called, we check if the instance already exists, and only if it doesn’t, do we create it. Okay that's all well and good we hear you say, but how do you actually express this? To express this, we are assigning a random ID to every instance that is created. If you check the output, you'll be able to see that both instance 1 and instance 2 have the same IDs. No matter how many instances you create, it'll be the same as the first one.

Constructor Pattern

Another popular pattern in JavaScript is the Constructor pattern. This is somewhat opposite to the singleton pattern and allows you to create different instances of the same thing. The example below shows a simple Animal type, with a type and a sound. We then use the new keyword to create two instances of the Animal, one being a dog and the other a parrot. Each time you create a new instance, you pass in the necessary parameters. If no parameter is given, the new object will have undefined values.

Factory Pattern

So we've seen how we can create a single instance of a type as well as multiple instances of a type based on a constructor, how about a factory? The factory pattern has a constructor for different types and takes care of object creation based on the requirement. If you relate it with the above example, imagine sending the name of the animal and the object being created for you and returned.

The factory pattern is widely used for things like notification services where there can be different notification channels being used by an application that has different object properties. Based on the selection by the user in their preferences, or the application itself, the object is created and returned for use.

Publish-Subscribe (or Observer) Pattern

The observer pattern or the publish-subscribe pattern is a widely-used messaging model as well as a design pattern. It has a publisher or the subject, which notifies the subscribers (or dependents) of any state changes through the invocation of a function. This is a vital pattern when it comes to event-driven programming. Imagine you want to update some information on a lot of objects in your application. For this, we can make all of the dependents subscribe to the subject and then make the necessary change in the subject which will then relay back to all the subscribers.

Conclusion

Whether an application will make or break ultimately depends on the quality of design patterns used and the coding standards followed. We hope you had a good time reading about some of the common design patterns in JavaScript. Do note that these design patterns are not just for a specific programming language but for any language that is object-oriented in nature. Even non-object-oriented languages have implementations of these patterns. That’s all for now. We know, we know, these articles go so quickly. See you in the next one.

Like what you've read or want more like this? Let us know! Email us here or DM us: Twitter, LinkedIn, Facebook, we'd love to hear from you.