Summary

In this chapter, we’ve been gently introduced to a set of traditional design patterns concerning the creation of objects. Some of those patterns are so basic, and yet essential at the same time, that we’ve probably already used them in one way or another.

Conventional design patterns in JavaScript

Patterns such as Factory and Singleton are, for example, two of the most ubiquitous in object-oriented programming in general. However, in JavaScript, their implementation and significance are very different from what was thought up by the Gang of Four book. For example, Factory becomes a very versatile pattern that works in perfect harmony with the hybrid nature of the JavaScript language, that is, half object-oriented and half functional. On the other hand, Singleton becomes so trivial to implement that it’s almost a non-pattern, but it carries a set of caveats that we should have learned to take into account.

Among the patterns we’ve learned in this chapter, the Builder pattern may seem the one that has retained most of its traditional object-oriented form. However, we’ve seen that it can also be used to invoke complex functions and not just to build objects.

The Revealing Constructor pattern, on the other hand, deserves a category of its own. Born from necessities arising from the JavaScript language itself, it provides an elegant solution to the problem of “revealing” certain private object properties at construction time only. It provides strong guarantees in a language that’s relaxed by nature.

Finally, we learned about the two main techniques for wiring components together: Singleton and Dependency Injection. We’ve seen how the first is the simplest and most practical approach, while the second is more powerful but also potentially more complex to implement.

Balancing creativity and rigor in creating design patterns

As we’ve already mentioned, this was just the first of a series of three chapters entirely dedicated to traditional design patterns. In these chapters, we’ll try to teach the right balance between creativity and rigor. We want to show that there are patterns that can be reused to improve our code and that their implementation isn’t the most important detail; in fact, it can vary a lot, or even overlap with other patterns. What really matters, however, is the blueprint, the guidelines, and the idea at the base of each pattern. This is the real reusable piece of information that we can exploit to design better Node.js applications in a fun way.