As a good JavaScript developer, you strive to write clean, healthy, and maintainable code.

You solve interesting challenges that, while unique, dont necessarily require unique solutions.

You may not know it, but youve used a JavaScriptdesign pattern.

A comprehensive guide to JavaScript design patterns

Design patterns are reusable solutions to commonly occurring problems in software design.

It’s free, every week, in your inbox.

Read: [Should designers learn how to code?]

The Comprehensive Guide to JavaScript Design Patterns

Called Netscape Navigator, it could only display static HTML at the time.

What they came up with is calledECMAScript.

The most popular one is the topic of this article, JavaScript.

Article image

What is JavaScript?

If someone were to ask you What is JavaScript?

It is a scripting language, which means that its code is interpreted instead of compiled.

Graphic depiction of the JavaScript event loop

This is usually used for subscribing to events such as a mouse click or a keyboard button press.

This is called theevent loop.

Each of the messages on the queue has a function associated with it.

Once a message is dequeued, the runtime executes the function completely before processing any other message.

This is called run-to-completion.

Thequeue.waitForMessage()synchronously waits for new messages.

Each of the messages being processed has its own stack and is processed until the stack is empty.

Once it finishes, a new message is processed from the queue, if there is one.

What are design patterns?

As I said before, design patterns are reusable solutions to commonly occurring problems in software design.

Lets take a look at some of the categories of design patterns.

Proto-patterns

How does one create a pattern?

Does it immediately become a pattern?

How can you know when what you think you recognize is actually a design pattern?

Anti-patterns

As a design pattern represents good practice, an anti-pattern represents bad practice.

An example of an anti-pattern would be modifying theObjectclass prototype.

Changes to theObjectprototype would be seen in all of the objects that inherit from this prototypewhich would bemostJavaScript objects.

This is a disaster waiting to happen.

Another example, similar to one mentioned above, is modifying objects that you dont own.

An example of this would be overriding a function from an object used in many scenarios throughout the system.

This way, you could recognize them and avoid making the mistake upfront.

The basic form of object creation could result in design problems or in added complexity to the design.

Creational design patterns solve this problem by somehow controlling object creation.

They help ensure that disparate parts of a system have synchronized information.

There is no universal set of patterns that is always the best fit.

We need to learn when a particular pattern will prove useful and whether it will provide actual value.

These are all important things to consider when thinking about applying a design pattern to our code.

Anyone with any experience with JavaScript has used them.

However, there is still room for improvement here.

If youll remember, I mentioned previously that JavaScript uses prototype-based inheritance.

The problem with the previous approach is that the methodwritesCodegets redefined for each of the instances of thePersonconstructor.

Module pattern

As far as peculiarities go, JavaScript never ceases to amaze.

In a classical OOP language, a user defines a class and determines access rights for its members.

Before we go into the module pattern specifics, lets talk about the concept of closure.

Aclosureis a function with access to the parent scope, even after the parent function has closed.

They help us mimic the behavior of access modifiers through scoping.

Using the closures, we can create objects with private and public parts.

However, not everything is so perfect.

Also, methods added to the object after their creation cannot reach the private members of the object.

Revealing module pattern

This pattern is an improvement made to the module pattern as illustrated above.

We can also change the naming of private members when mapping private members to their corresponding public members.

The revealing module pattern is one of at least three ways in which we can implement a module pattern.

For example, we need to have an object which contains some configuration for something.

A downside to using this pattern is that it is rather difficult to test.

It promotes loose coupling between objects.

The first is a subject and the second is observers.

The publisher fires an event and simply executes the callback function sent for that event.

A downside to using this pattern is difficult testing of various parts of our system.

Now, it is important to stress out that it handles workflow.

Why is this important?

A nice example of a mediator is a wizard jot down of interface.

Lets say you have a large registration process for a system you have worked on.

Inheritance between objects is implemented using prototype-based programming.

It enables us to create objects which can serve as a prototype for other objects being created.

The prototype object is used as a blueprint for each object the constructor creates.

For example, imagine a scenario where our system is using a large number of API service calls.

Then, lets say that the API services change.

We would have to modify the code wherever the APIs that changed are called.

It is used when an easier or simpler interface to an underlying object is desired.

We also need to be aware of the performance-simplicity tradeoff.

It is desirable to avoid extra complexity if it isnt beneficial enough.

Next steps

Design patterns are a very useful tool that anysenior JavaScript developershould be aware of.

so you can keep the article relatively brief, we will not be displaying any more examples.

I highly recommend both books.

Also tagged with