Introduction

Design Pattern

A design pattern is a reusable solution to a recurring problem. The term is really broad in its definition and can span multiple domains of an application. However, the term is often associated with a well-known set of object-oriented patterns that were popularized in the 90s by the book, Design Patterns: Elements of Reusable Object-Oriented Software, Pearson Education, by the almost legendary Gang of Four (GoF): Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. We will often refer to these specific sets of patterns as traditional design patterns or GoF design patterns.

Applying this set of object-oriented design patterns in JavaScript is not as linear and formal as it would be in a classical object-oriented language. As we know, JavaScript is object-oriented, prototype-based, and has dynamic typing. It also treats functions as first-class citizens and allows functional programming styles. These characteristics make JavaScript a very versatile language, which gives tremendous power to the developer but at the same time, it causes fragmentation of programming styles, conventions, techniques, and ultimately the patterns of its ecosystem. With JavaScript, there are so many ways to achieve the same result that each developer has their own opinion on what’s the best way to approach a problem. A clear demonstration of this phenomenon is the abundance of frameworks and opinionated libraries in the JavaScript ecosystem; probably no other language has ever seen so many, especially now that Node.js has given new astonishing possibilities to JavaScript and has created so many new scenarios.

In this context, the nature of JavaScript affects traditional design patterns too. There are so many ways in which traditional design patterns can be implemented in JavaScript that the traditional, strongly object-oriented implementation stops being relevant.

In some cases, the traditional implementation of these design patterns is not even possible because JavaScript, as we know, doesn’t have real classes or abstract interfaces. What doesn’t change, though, is the original idea at the base of each pattern, the problem it solves, and the concepts at the heart of the solution.

In this chapter and in the two that follow, we’ll see how some of the most important GoF design patterns apply to Node.js and its philosophy, therefore rediscovering their importance from another perspective. Among these traditional patterns, we’ll also take a look at some “less traditional” design patterns born from within the JavaScript ecosystem itself.

In this chapter, in particular, we’ll take a look at a class of design patterns called creational. As the name suggests, these patterns address problems related to the creation of objects. For example, the Factory pattern allows us to encapsulate the creation of an object within a function. The Revealing Constructor pattern allows us to expose private object properties and methods only during the object’s creation, while the Builder pattern simplifies the creation of complex objects. Finally, the Singleton pattern and the Dependency Injection pattern help us with wiring the modules within our applications.