Command pattern is a very frequent js pattern designed to help you decouple your method calls from the underlying logic.

The idea is very simple, your object should have an execute method, that will take the function name and it’s parameters as arguments. Then, based on those parameters, it executes the underlying logic.

The final result gives a very clean API towards the user, as well as some security regarding redefinition of your methods. Again and again, as beers are piling throughout this tutorial, will see another approach to making our bar work.

Somewhat similar to interpreter, command pattern serves a different purpose. The example above is simple, so it does not look like we need something like this, but abstracting the method invocation from implementation can provide additional security. Most of jquery plugins operate on this pattern, as well as native “.on()” method for example.


As the official definition states

“Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.”

Iterator pattern enables as to traverse different collections, by implementing the same interface on each of them. An object is an iterator when it knows how to access its members while retaining the index of the current  position inside collection. ES6 even brought us a new syntax for iterators, stating that an iterator is an object that provides a next() method which returns the next item in the sequence. This method returns an object with two properties: done and value.

In order to be iterable, an object must implement the @@iterator method, meaning that the object must have a property with a Symbol.iterator key. In Javascript, strings, arrays, typed arrays, maps and sets are iterable by default, meaning that they have the iterator property defined.

To define your own iterator, simply add a Symbol.iterator as a object property, and define the function that handles it.

Generators provide a built in alternative to custom handling of iterators implementation as they offer all internal implementation by simply defining the function with an asterisk, and returning values with yield.

I will not make an example, as i think the explanation of this one is enough. For more detail, please visit the official MDN documentation.


Mediator pattern is a pattern similar to facade. The only difference is that a facade does not add functionality, while Mediator does. The communication between objects becomes centralized, reducing complexity by preventing the objects to communicate between themselves. This lowers the coupling level, resulting in greatly increased maintainability and reusability of code. In the Observer pattern, the observable is basically a mediator as it notifies it’s subscribers when something has changed. The difference is that the Observer pattern introduces subject and observer object, while mediator encapsulates the communication between objects.

It is often easier to employ the observer pattern, but if the number of objects is not big, there is no need to introduce new object’s at runtime, and the interaction between them is complex, the Mediator pattern is perfect. Just be careful not to over do it by over complicating and creating a “God” object that takes care of everything.

For example, imagine  you have dozens or thousands of objects that need to be notified on change, or say a few modules that need to be communicating to our RESTful API to get data, but only one at a time by preventing the user to make a new request until the previous one has finished. This is a perfect example when you want to have centralized communication.

Next, we will look at Observer and Publish/Subscribe patterns.