The nice thing is — you don’t have to be the only subscriber. As you would be disappointed by missing your newspaper, so would other people, too. That’s why multiple observers can subscribe to the subject.

The why

The observer pattern has many use cases but generally, it should be used when you want to create a one-to-many dependency between objects which isn’t tightly coupled and have the possibility to let an open-ended number of objects know when a state has changed.

JavaScript is a great place for the observable pattern because everything is event-driven and, rather than always asking if an event happened, you should let the event inform you (like the old adage “Don’t call us we’ll call you”). Chances are you already did something which looks like the observer pattern — addEventListener . Adding an event listener to an element has all the markings of the observer pattern:

you can subscribe to the object,

you can unsubscribe from the object,

and the object can broadcast an event to all its subscribers.

The big payoff from learning about the observer pattern is that you can implement your own subject or grasp an already existing solution much faster.

The where

Implementing a basic observable shouldn’t be too hard, but there is a great library being used by many projects and that’s ReactiveX of which RxJS is its JavaScript counterpart.

RxJS allows you not only to subscribe to subjects, but also gives you the possibility of transforming the data in any way you can imagine, combining multiple subscriptions, making asynchronous work more manageable and much much more. If you ever wanted to bring your data processing and transformation level to a higher level, RxJS would be a great library to learn.

Apart from the observer pattern, ReactiveX also prides itself with implementing the iterator pattern which gives subjects the possibility of letting its subscribers know when a subscription ended, effectively ending the subscription from the subject’s side. I am not going to be explaining the iterator pattern in this article, but it would be a great exercise for you to learn more about it and see how it fits in with the observable pattern.

Facade pattern

The what

The facade pattern is a pattern which takes its name from architecture. In architecture:

A facade is generally one exterior side of a building, usually the front. It is a foreign loan word from the French façade, which means “frontage” or “face”.

As the facade in architecture is an exterior of the building, hiding its inner workings, the facade pattern in software development tries to hide the underlying complexity behind a front, effectively allowing you to work with an API which is easier to grasp while providing the possibility to change the underlying code however you want.

The why

You can use the facade pattern in a myriad of situations but the most notable ones would be to make your code easier to understand (hide complexity) and to make dependencies as loosely coupled as possible.