basic-design-patterns: a JavaScript catalogue with a decision table

The table that comes before the patterns

Most design pattern collections are a list. This one starts with a question and a table.

The quick start guide asks the question directly: not sure which pattern to use? And then gives ten rows, each with a problem, a pattern, and a use when column.

The rows are the ones a working developer actually asks about. Needing exactly one instance maps to the singleton, with a shared resource such as a logger, a configuration, or a database as the use case. Creating many similar objects maps to the factory method, for when there are several types and you want to hide the new keyword. Building complex objects step by step maps to the builder, for objects with many optional parameters or a complicated setup.

Then the ones about behaviour rather than creation. Multiple ways to do something is the strategy, used when the choice of algorithm varies and you want to avoid a large conditional chain. Adding features to objects is the decorator, for wrapping an object with logging, caching, or authorisation. Simplifying complex systems is the facade, hiding a set of subsystems behind one simple interface. Working with a tree or a hierarchy is the composite, with folders and files, user interface components, and organisation trees as the examples. Existing code that does not match is the adapter, for integrating legacy code or a third party library.

The last two rows are the ones a beginner finds hardest. Tracking changes to objects is the observer, for event listeners, publish and subscribe systems, and state changes. Different behaviour per state is the state pattern, for objects that behave differently depending on their internal state.

That table is the reason the repository is worth more than a list of links. A pattern name is only useful once you can turn a symptom into a name, and the table is a symptom to name mapping that a reader can apply without opening anything.

A learning path, with the order argued for

The guide also gives a recommended order, and the order is not alphabetical, which is the point.

The first step is the singleton, described as the simplest, one instance only. The second is the factory method, described as essential for object creation. The third is the observer, called critical for event driven code. The fourth is the strategy, offered as a powerful alternative to conditionals. The fifth is the decorator, for advanced object enhancement. The sixth is the builder, for complex object construction. And the seventh is everything else, on the grounds that the rest builds on these fundamentals.

The reasoning is easy to reconstruct from the descriptions, and it is a sensible one for JavaScript. The singleton comes first because it is the smallest idea in the set. The factory method comes second because it is the one that answers the question every object oriented program asks about creation. The observer comes third because event handling is the thing JavaScript applications do most, and once you have the vocabulary of a subject and a listener, a lot of application code has a name.

The strategy comes fourth, and it pairs with the observer, because both replace a conditional with a structure. The decorator comes fifth because it needs the object notion to be comfortable, and the builder comes last of the named ones because it deals with the most parameters and the most cases.

Placing the remaining patterns after the fundamentals is the right call for a reader who is new to the subject, and it is also the right call for a reader who knows one language well and has never read the Gang of Four, because the order is a difficulty order rather than a historical one.

The creational five, and what they have in common

The catalogue is divided into the three groups the original set used, and the descriptions are one sentence each, which is the format the original descriptions are usually reduced to.

The creational group has five. The abstract factory provides an interface for creating families of related or dependent objects without specifying their concrete classes. The builder separates the construction of a complex object from its representation, so the same construction process can create different representations. The factory method creates objects without specifying the exact class that will be created. The prototype creates new objects by copying an existing one, which is the prototype. The singleton ensures a class has only one instance and provides a global point of access to it.

Read as a set, the creational patterns are all about one question: where does this object come from. The abstract factory and the factory method are the two answers to it, one for a family of related things and one for a single decision. The prototype answers it by copying rather than constructing, which in JavaScript is a natural fit because the language has object literals to copy. The builder answers it for objects that are too big to pass to a constructor, and the singleton answers it by refusing to make more than one.

The singleton is the one most people meet first and the one most often misapply, so it is worth being clear that a global point of access is the pattern's stated purpose and that the difficulty usually comes from the global part rather than the single instance part. The catalogue lists it as the first pattern to learn, which is a reasonable way to meet the idea and not a recommendation to use it everywhere.

The structural seven: wrapping, simplifying, and varying

The structural group has seven patterns, and the common thread is the relationship between a thing and the things it is made of.

The adapter allows incompatible interfaces to work together by converting one interface into another. The bridge decouples an abstraction from its implementation so the two can vary independently. The composite composes objects into tree structures to represent part whole hierarchies, and lets clients treat individual objects and compositions uniformly. The decorator adds behaviour or responsibilities to an object dynamically without altering its structure. The facade provides a simplified interface to a larger body of code. The flyweight reduces memory usage by sharing common parts of the state between multiple objects. The proxy provides a surrogate or placeholder for another object in order to control access to it.

Three of those are variations on wrapping, and the differences between them are the interesting part. The decorator wraps and adds behaviour, the proxy wraps and controls access, and the adapter wraps and converts an interface. The descriptions in the catalogue say exactly that, and a reader who learns to tell those three apart has learned most of what the structural group is for.

The bridge and the flyweight are the two that solve a scaling problem rather than an interface problem. The bridge keeps two dimensions of variation apart, and the flyweight trades a small amount of shared indirection for a large saving in memory when there are many similar objects. Those are the two patterns in the group that tend to be used in applications where nobody has a name for the problem yet.

The behavioural eleven, and the licence

The behavioural group is the largest, with eleven patterns, and it is the group about what happens when a request moves through a system.

The chain of responsibility passes a request along a chain of handlers until one handles it or the chain ends. The command encapsulates a request as an object, which allows requests to be parameterised and queued. The interpreter defines a representation for a language's grammar and provides an interpreter to process sentences in it. The iterator gives sequential access to the elements of a collection without exposing its representation. The mediator defines an object that encapsulates how a set of objects interact, which promotes loose coupling. The memento captures and restores an object's internal state without violating encapsulation. The observer defines a one to many dependency so that when one object changes state, all its dependents are notified. The state pattern lets an object alter its behaviour when its internal state changes. The strategy defines a family of algorithms, encapsulates each one, and makes them interchangeable. The template method defines the skeleton of an algorithm in a method and defers some steps to subclasses. The visitor separates an algorithm from the objects it operates on, so new operations can be added without modifying those objects.

The command and the visitor are the two that pay off hardest in a codebase that has grown, because both exist to add behaviour to objects you do not own or cannot change, and both do it at the cost of a new class per operation.

The repository itself is small: a readme, a contributing guide, a code of conduct, a licence, and the patterns directory. There is no build, no test suite, and no package manifest, because the artefact is the prose and the examples.

And the licence is worth reading before you copy anything. It is a Creative Commons zero waiver, which is a public domain dedication rather than a software licence. That is a deliberate choice for a teaching repository, and it is the reason the examples can be pasted into a project without attribution obligations.

Editorial conclusion

basic-design-patterns fits a developer who has heard the pattern names and cannot map a problem to one, because the table in the readme is the part that turns a name into a decision, and it fits a learner who wants the creational, structural, and behavioural groups in a consistent one line form. It does not fit a team that needs production code rather than examples, and it does not fit a reader who wants the trade offs of each pattern, because the descriptions are definitions rather than judgements. Verify first that the pattern you are about to use is in the catalogue with the JavaScript example you need, that the learning path suits your level rather than starting you at Singleton, and that the licence suits what you intend to do with the examples, since the repository is released into the public domain with a Creative Commons zero waiver rather than under a software licence.

Frequently asked questions

Official sources

1. AllThingsSmitty/basic-design-patterns on GitHub
2. Issues
3. License: CC0-1.0
4. README