[Translation] Design patterns in modern JavaScript-development

[Translation] Design patterns in modern JavaScript-development

The author of the material, the translation of which we publish, says that in the world of software development, "architectural design" can be called an application design process, during which it is sought to be qualitative, reliable and well-supported. At the same time, design patterns (templates) allow you to operate with concepts that represent approaches to solving common problems. These solutions can range from abstract, conceptual, to very specific. Their knowledge allows developers to communicate effectively with each other.

If at least two developers in a team understand patterns, the conversation about solving problems facing a team becomes very productive. If only one member of the team knows about the patterns, it is usually just to explain what he knows to the other members of the team.


The purpose of this article is to interest readers in something like a formal presentation of knowledge in the field of software development, demonstrating to them the idea of ​​design patterns and describing several patterns that are interesting because they have found application in modern JavaScript Development.

Singleton Pattern

General information

The singleton design pattern, which is also called the “loner”, cannot be called one of the most widely used patterns, but we start the conversation with it, since it is relatively easy to understand.

This pattern arises from the mathematical concept of a singleton - a one-element set, that is, a set containing only one element. For example, the set {null} is a singleton.

In the field of software development, the meaning of the “singleton” pattern is that we limit the number of possible instances of a certain class to one object. When you first try to create an object based on the class that implements this pattern, such an object is actually created. All subsequent attempts to create an instance of the class result in the return of the object created during the first attempt to obtain an instance of the class.

Why another superhero when we have Batman?

Above is an example of a class that implements the singleton pattern.

Why do you need it?

It is clear that this pattern allows us to restrict ourselves to only one “superhero” (this is obviously Batman). But why else would he need it?

Although this pattern is not devoid of its own problems (it used to be called evil, given that what singletons were called pathological liars ), it may, in some situations, be very helpful. One of these situations is to initialize configuration objects. In a typical application, it makes sense to keep only one instance of such an object, unless, in accordance with the features of the project, it does not use several such objects.

▍Where is it used?

The main example of using the “singleton” pattern in large popular frameworks is Angular services. The Angular documentation has a separate page that explains how to make a service a singleton.

Making services in the form of singletons has a deep meaning, as services are used as state storage, configuration, and allow you to organize the interaction between components. All this leads to the fact that the developer needs that in his application there would not be several instances of the same service.

Consider an example. Suppose we have a simple application that is used to calculate the number of button presses.

Each click on any of the buttons updates the counter

The number of clicks on the buttons must be stored in one object, which realizes the following features:

  • It allows you to count clicks on buttons.
  • It allows you to read the current value of the click counter.

If such an object would not be a singleton (and each button would have its own instance of such an object associated), then the program would incorrectly count the number of button presses. In addition, with this approach it is necessary to solve the following problem: “From which object, which is responsible for counting clicks, will the data displayed on the screen be taken?”.

Observer Pattern

General information

The observer pattern is a design pattern in which an object called a “subject” (subject) maintains a list of dependent objects called observers and automatically notifies them when their state changes, usually by calling one of their methods. .

Understanding this pattern is not difficult if you find its analogy in the real world. Namely, we are talking about newspaper subscriptions.

Suppose you usually buy newspapers at a kiosk. You go there, ask if there is a fresh issue of your favorite newspaper. If you don’t have what you need in the kiosk, then you go home, having wasted time, and then again go to the kiosk. If we consider this situation as applied to JavaScript, it would be similar to a cyclical interrogation of a certain entity, performed until the necessary data is obtained from it.

After you finally get the newspaper you need, you can proceed to what you have been striving for all this time - take a cup of coffee and unwrap the newspaper. In JavaScript, this would be equivalent to calling a callback, which we were going to call after getting the desired result.

Finally you can read the newspaper

It would be much more reasonable to do this: subscribe to a newspaper and receive a fresh issue every day. With this approach, the publisher will let you know that the latest issue of the newspaper has been published, and will deliver it to you. You do not have to go to the kiosk anymore. No more wasting time.

If you go back to JavaScript again, this means that you will no longer have to wait in the loop for some result, and, having received it, call some function. Instead, you tell the subject that you are interested in certain events (messages), and you give him a callback function, which should be called when the data you are interested in is ready. You then become an observer.

Now you never miss your favorite morning newspaper

The pattern in question has one nice feature: you do not have to be the only observer.If you can't get your favorite newspaper, it will upset you. But the same thing will happen with other people who can not buy it. That is why several observers can subscribe to one subject.

Why do you need it?

The “observer” pattern is used in many situations, but usually it should be used when you want to create a one-to-many relationship between objects, and at the same time such objects should not be tightly coupled. In addition, the created system should be able to notify an unlimited number of objects about some changes.

JavaScript applications are a great place to apply the “observer” pattern, since everything here is controlled by events, and instead of constantly turning to an entity, knowing whether an event of interest has occurred, it would be much better to give it the opportunity to notify you when the occurrence of this event (it looks like the old saying: "We don’t need to call. When we need to, we will call you ourselves").

It is likely that you have already used structures that resemble the "observer" pattern. An example is addEventListener . Adding an event listener to an item has all the hallmarks of using an observer pattern:

  • You can subscribe to an object.
  • You can unsubscribe from the object.
  • The object can inform the event of all its subscribers.

Knowing about the existence of the “observer” pattern is useful in that this knowledge allows you to realize your own subject, or much faster than before, to deal with an existing solution using this pattern.

▍Where is it used?

The basic implementation of this pattern does not have to be particularly difficult, but there are excellent libraries that implement it and are used in many projects. This is a project ReactiveX , and its JavaScript variant RxJS .

The RxJS library allows you not only to subscribe to subjects, but also gives the programmer the ability to transform data in a variety of ways, allows you to combine multiple subscriptions, and improves the ability to manage asynchronous operations. In addition, its capabilities are not limited to this. If you ever wanted to raise the capabilities of your programs for processing and converting data to a higher level, then you can recommend to explore the RxJS library.

In addition to the “observer” pattern, the ReactiveX project can be proud of the implementation of the “iterator” pattern (iterator), which enables the subject to inform subscribers about the completion of the subscription, in fact, allowing the subject to be canceled at the initiative of the subject. In this article, I'm not going to talk about the “iterator” pattern, but I can say that if you are just starting to learn design patterns, studying this pattern and thinking about how it is combined with the “observer” pattern can be good exercises.

Pattern "facade"

General information

The facade pattern got its name from architecture. In architecture, the facade is usually one of the outer sides of the building, as a rule - the front side. English borrowed the word "facade" from French. This is the word "façade", which, among other things, translates as "the front side of the building."

The facade of a building in architecture is the outer part of the building that hides what is inside. Similar properties can be noted in the “facade” pattern, as it aims to hide complex internal mechanisms behind some external interface.Its use allows the developer to work with an external API that is simple enough, and, at the same time, provides the ability to change the internal mechanisms hidden behind the facade, without disturbing the performance of the system.

Why do you need it?

The “facade” pattern can be used in a huge number of situations, among which it is possible to highlight those of them when they try to make the code simpler to understand (that is, they hide complex mechanisms behind simple APIs), and those when fragments of systems tend to make weaker related to each other.

>/> These objects need something from the dragon's lair

It is easy to see that an object facade (or a layer with several objects) is a very useful abstraction. Hardly anyone wants to face the dragon in the event that this can be avoided. The façade object is needed in order to provide other objects with a convenient API, and with all the dragon tricks this object will manage on its own.

Another useful feature of the “facade” pattern is that you can “redo” the dragon as you like, but this will not affect other parts of the application. Suppose you want to replace the dragon with a kitten. A kitten, like a dragon, has claws, but it is easier to feed him. Changing the dragon for a kitten - this means - rewrite the code of the facade object without making changes to the dependent objects.

▍Where is it used?

Pattern "facade" can often be found in Angular. There, services are used as tools to simplify some kind of basic logic. But this pattern is applicable not only in Angular, below you can see this.

Suppose we need to add a state management system to the application. To solve this problem, you can use different tools, among them - Redux, NgRx, Akita, MobX, Apollo, as well as constantly emerging new tools. Why not try them all?
What is the main functionality that a state library should provide? These are probably the following options:

  • A mechanism to alert the state management system that we need to change the state.
  • A mechanism for getting the current state or its fragment.

It looks all not so bad.

Now, armed with the “facade” pattern, you can write facades for working with different parts of the state, providing convenient APIs that can be used in the program. For example, something like facade.startSpinner () , facade.stopSpinner () and facade.getSpinnerState () . Such methods are easy to understand, you can easily refer to them in a conversation about the program.

After that, you can work with objects that implement the “facade” pattern and write code that will transform your code so that it can work with Apollo (state management using GraphQL is a hot topic). It is possible that during the tests you will find that Apollo is not suitable for you, or that it is inconvenient for you to write unit tests for this state management system. No problem — write a new façade designed for MobX support and test the system again.

Different application state management systems that are accessed through a single facade can also be dragons ...


You probably noticed that when talking about design patterns, we didn’t look at code samples.The fact is that a deep analysis of each pattern draws at least a separate chapter in a book that is far from being the thinnest. By the way, since we started talking about books, here and here - interesting publications that you can look at who wants to delve into the study of patterns.

In the end, I want to say that in mastering patterns, nothing compares to searching on the Internet, reading and independent testing of various ideas. Even if it turns out that you will never use the patterns, you will learn something new and grow into areas unexpected for yourself.
Dear readers! What design patterns do you use?

<< a>

Source text: [Translation] Design patterns in modern JavaScript-development