This chapter documents the three main categories of design patterns and the different patterns that fall under them. While every design pattern addresses a specific object-oriented design problem or issue, we can draw parallels between the solutions based on how they solve these issues. This forms the basis for the categorization of design patterns.
Gamma, Helm, Johnson, and Vlissides (1995), in their book, Design Patterns: Elements of Reusable Object-Oriented Software, describe a design pattern as:
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and their instances, their roles and collaborations, and the distribution of responsibilities.
Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether or not it can be applied in view of other design constraints, and the consequences and trade-offs of its use. Since we must eventually implement our designs, a design pattern also provides sample…code to illustrate an implementation.
Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages….
Design patterns can be categorized based on the type of problem they solve. The three principal categories of design patterns are:
Creational design patterns
Structural design patterns
Behavioral design patterns
In the following sections, we’ll review these three with a few examples of the patterns that fall into each category.
Creational design patterns focus on handling object-creation mechanisms where objects are created in a manner suitable for a given situation. The basic approach to object creation might otherwise lead to added complexity in a project, while these patterns aim to solve this problem by controlling the creation process.
Some patterns that fall under this category are Constructor, Factory, Abstract, Prototype, Singleton, and Builder.
Structural patterns are concerned with object composition and typically identify simple ways to realize relationships between different objects. They help ensure that when one part of a system changes, the entire structure of the system need not change. They also assist in recasting parts of the system that don’t fit a particular purpose into those that do.
Patterns that fall under this category include Decorator, Facade, Flyweight, Adapter, and Proxy.
Behavioral patterns focus on improving or streamlining the communication between disparate objects in a system. They identify common communication patterns among objects and provide solutions that distribute the responsibility of communication among different objects, thereby increasing communication flexibility. Essentially, behavioral patterns abstract actions from objects that take the action.
Some behavioral patterns include Iterator, Mediator, Observer, and Visitor.
Elyse Nielsen in 2004 created a “classes” table to summarize the 23 GoF design patterns. I found this table extremely useful in my early days of learning about design patterns. I’ve modified it where necessary to suit our discussion on design patterns.
I recommend using this table as a reference, but remember that we will discuss several other patterns not mentioned here later in the book.
We discussed JavaScript ES2015+ classes in Chapter 5. JavaScript classes and objects will be relevant when you review the following table.
Let us now proceed to review the table:
Creational |
Based on the concept of creating an object |
Class |
|
Factory method |
Makes an instance of several derived classes based on interfaced data or events |
Object |
|
Abstract Factory |
Creates an instance of several families of classes without detailing concrete classes |
Builder |
Separates object construction from its representation; always creates the same type of object |
Prototype |
A fully initialized instance used for copying or cloning |
Singleton |
A class with only a single instance with global access points |
Structural |
Based on the idea of building blocks of objects |
Class |
|
Adapter |
Matches interfaces of different classes so that classes can work together despite incompatible interfaces |
Object |
|
Bridge |
Separates an object’s interface from its implementation so that the two can vary independently |
Composite |
A structure of simple and composite objects that makes the total object more than just the sum of its parts |
Decorator |
Dynamically adds alternate processing to objects |
Facade |
A single class that hides the complexity of an entire subsystem |
Flyweight |
A fine-grained instance used for efficient sharing of information that is contained elsewhere |
Proxy |
A placeholder object representing the true object |
Behavioral |
Based on the way objects play and work together |
Class |
|
Interpreter |
A way to include language elements in an application to match the grammar of the intended language |
Template method |
Creates the shell of an algorithm in a method, then defers the exact steps to a subclass |
Object |
|
Chain of responsibility |
A way of passing a request between a chain of objects to find the object that can handle the request |
Command |
A way to separate the execution of a command from its invoker |
Iterator |
Sequentially accesses the elements of a collection without knowing the inner workings of the collection |
Mediator |
Defines simplified communication between classes to prevent a group of classes from referring explicitly to each other |
Memento |
Captures an object’s internal state to be able to restore it later |
Observer |
A way of notifying change to a number of classes to ensure consistency between the classes |
State |
Alters an object’s behavior when its state changes |
Strategy |
Encapsulates an algorithm inside a class, separating the selection from the implementation |
Visitor |
Adds a new operation to a class without changing the class |
This chapter introduced categories of design patterns and explained the distinction between creational, structural, and behavioral patterns. We discussed the differences between these three categories and GoF patterns in each category. We also reviewed the “classes” table that shows how the GoF patterns relate to the concepts of classes and objects.
These first few chapters have covered theoretical details about design patterns and some basics of JavaScript syntax. With this background, we are now in a position to jump into some practical examples of design patterns in JavaScript.