Design patterns are solutions to common problems seen in software development. They are a foundational concept that both novice and advanced developers must continuously study and practice. In this Refcard, we will dive into the concepts that underpin design patterns and look at the 23 Gang of Four (GoF) patterns that brought about the proliferation of design patterns.

We will then look at some common patterns that have evolved over the years since the GoF patterns were published in 1994, as well as some resources that will help us understand the GoF patterns — and design patterns in general — more intuitively.

Before we dive into the GoF patterns, we must first understand the fundamental concepts of object-oriented (OO) design and look at two important considerations that provide a groundwork for all OO software patterns. Understanding the GoF design patterns requires a foundational understanding of OO design. Three of the fundamental concepts shared by all OO design patterns — and the GoF design patterns, in particular — are abstraction, interfaces, and polymorphism.

Abstraction is the removal of unnecessary details and the focus on pertinent details for a given context. For example, when we look at a car, we see doors, body panels, windows, wheels, and the like. If we focus on the wheels, we may go into a deeper level of abstraction and see rubber tires, metal rims, and air. Another level deeper, and we may focus on composites in the rubber compound or the nitrogen and oxygen particles bouncing within the tire that constitute tire pressure. The level of abstraction we select will depend on the particular problem and the problem's context.

Interfaces are the highest form of abstraction in OO design. Interfaces represent what an object can do — through methods — while hiding the details of how it does it. For example, the interface for a car, Car, may be limited to a start() and driveTo(Location) method, neither of which provide any details about how a particular car is started or can be driven to a particular location.

Implementations of this interface (called concrete classes) are then created, which provide these details, but clients interacting with the Car interface are unconcerned with these details. This encapsulates the details and allows clients to focus on the inputs and outputs of the methods rather than the particular details of how they are performed.

Polymorphism is the ability of an object to be treated as multiple types at the same time. There is static polymorphism, which uses method overloading, and dynamic polymorphism, which uses method overriding. Most design patterns focus on dynamic polymorphism, where a client calls the methods of an interface while unaware of the actual implementation being used. For example:

Vehicle vehicleA = new Sedan();
Vehicle vehicleB = new Truck();

vehicleA.drive();
vehicleB.drive();

In this case, when drive() is called on vehcileA, it will use the Sedan, and when drive() is called on vehicleB, it will use the Truck implementation.

Considerations 

In addition to OO design principles, there are two additional points we must consider before we can understand different design patterns: delegation and inheritance vs. aggregation.

• Delegation – In some cases, it is better for a class to make a decision for itself, such as what type of object to instantiate and return from a method or how to perform a given task. In other cases, it may be better for an object to delegate that responsibility to another object.
  • By introducing delegation, we can also allow other objects to change the behavior of our object in useful ways since the particular logic executed will vary at runtime.
• Inheritance vs. aggregation – Delegated logic can be implemented by either inheriting from a base class and overriding a method, or by introducing an attribute and calling that object to do work. In both cases, the particular logic executed can vary since the class does not know what subclass is inheriting it, and the object does not know the runtime type of the particular attribute.
  • In most cases, aggregation is preferred, because it allows for easier runtime variation of behavior (an attribute can be injected or replaced at runtime) and reduces the number of subclasses that must be created to vary behavior.

The GoF design patterns are divided into three categories: creational, structural, and behavioral.

Creational Patterns 

This type of pattern abstracts the instantiation process of an object.

Abstract Factory 

The abstract factory pattern creates families or groups of objects without knowing their implementation.

Figure 1: Abstract factory pattern

Table 1

Example: An abstract factory can be used when interacting with file systems, where one family of objects pertains to Windows, while another family of objects pertains to Linux. When a client requests the objects used to interact with the file system on a Windows system, the Windows factory is provided; likewise, the Linux factory is provided when interacting with a Linux system.

Builder 

The builder pattern abstracts the logic for creating an object into a set of steps.

Figure 2: Builder pattern

Table 2

Example: The Apache HttpClient library provides the URIBuilder class, which allows clients to instantiate a builder object, configure the URI components (e.g., protocol, host, port, and query parameters), and then generate a URI object using the build() method.

Factory Method 

The factory method abstracts the creation logic for an object in the superclass, allowing subclasses to define the concrete object that will be created.

Figure 3: Factory method pattern

Table 3

Example: Factory methods can be used when creating task objects, where a Scheduler used to schedule and execute the logic of the task can be abstracted into a factory method. Subclasses can then be created, such as SingleThreadedTask, where the factory method returns a SingleThreadedScheduler that is used to execute the task logic.

Prototype 

The prototype pattern clones an existing object without requiring a client to know the concrete type.

Figure 4: Prototype pattern

Table 4

Example: The Java Object class includes a clone() method, which allows a client to clone any object that implements the Cloneable interface. There is nuance to the implementation of the clone() method that deviates from a strict prototype pattern implementation, but conceptually, any class that implements Cloneable can be cloned.

Singleton 

The singleton pattern ensures that a class has only one object created, which is accessed through a single entry point.

Figure 5: Singleton pattern

Table 5

Example: The Spring Inversion of Control (IoC) container allows clients to create singleton beans. If a bean is declared as a singleton, then only one instance of the bean will be created per IoC container, and the same object will be used when auto-wiring the bean into dependent objects. Note that Spring does not implement this bean creation using a static method, but it conceptually enforces the singleton pattern.

Structural Patterns 

Structural patterns compose classes and objects to form larger structures.

Adapter 

The adapter pattern allows an object with one interface to be used where another interface is expected.

Figure 6: Adapter pattern

Table 6

Example: The Java InputStreamReader adapter class contains constructors that accept an InputStream and implements the Reader interface. By creating an InputStreamReader using this constructor, an InputStream can be adapted to a Reader and used wherever a Reader is required. Likewise, an OutputStream can be adapted to a Writer using the OutputStreamWriter class.

Bridge 

The bridge pattern splits orthogonal concepts in a single class hierarchy into multiple hierarchies. 

Figure 7: Bridge pattern

Table 7

Example: There may be multiple properties that define a vehicle, such as its type (sedan, truck, etc.), its color, and its trim (sport, premium, etc.). Creating a new class for each of these hierarchies, such as RedSportSedan, would introduce a combinatorial explosion as the number of possibilities for each hierarchy grows. Instead, we can create a Sedan implementation for a Vehicle interface that has two properties, Color and Trim, where Red implements the Color interface and Sport implements the Trim interface.

Composite 

The composite pattern creates a hierarchy of nested objects, where the client does not know if it is performing an operation on a single leaf object or an object representing a collection of sub-objects. 

Figure 8: Composite pattern

Table 8

Example: If we want to move files on a file system, we can create a File interface with a moveTo(Path) method, and have two concrete implementations: a composite called Directory and a leaf called TextFile. When a client calls the moveTo(Path) method on an arbitrary File object, a TextFile object will move itself, while a Directory object will move itself as well as all its children (either TextFile or other Directory objects).

Decorator 

The decorator pattern wraps an existing object to add additional responsibility.

Figure 9: Decorator pattern

Table 9

Example: In order to debug issues and track the operation of an application, it is important to log critical events, but logging statements can add clutter to a method definition. Instead of adding logging directly to the method, we can create a decorator that logs the start and completion of the method call, allowing us to supplement the logic contained in the wrapped object without changing the wrapped object itself.

Façade 

The façade pattern defines a unified interface for a more complex set of sub-interfaces and classes.

Figure 10: Façade pattern

Table 10

Example: The Spring IoC container allows clients to programmatically create beans through the ApplicationContext class. While the Spring IoC container is a complex and intricate system, the ApplicationContext class provides a single entry point that allows clients to focus on bean creation and retrieval, rather than the details of the IoC container.

Flyweight

The flyweight pattern reuses shared components rather than instantiating new objects each time a component is needed.

Figure 11: Flyweight pattern

Table 11

Example: The boxed types in Java each contain a valueOf method that creates a boxed object from its primitive counterpart — for example, Integer.valueOf(1). The Integer#valueOf(int) method will always return the same Integer object for values between -128 and 127, while other values may also be cached (e.g., Integer.valueOf(1) == Integer.valueOf(1) will always be true, while Integer.valueOf(1000) == Integer.valueOf(1000) is not guaranteed to be true). Note: the implementation used by Interger#valueOf(int) may not exactly match the flyweight pattern, but it conceptually implements the pattern.

Proxy 

The proxy pattern wraps an existing object in order to control access to the wrapped object.

Figure 12: Proxy pattern

Table 12

Example: A cache that reduces the number of calls made to a database. If we are trying to access books in a database, we can create a BookRepository interface with a findById(long) method, and we can create a MongoDbBookRepository to find Book objects in our MongoDB database. We can then create a CachedBookRepository that caches Book objects in memory and has a reference to the MongoDbBookRepository to find Book objects that are not already in the cache. When a client calls findById(long), if the Book object is already in the cache, it is immediately returned without querying the MongoDB database, thus limiting the number of queries to the MongoDB instance.

Behavioral Patterns 

This category assigns responsibility and defines communication among groups of objects.

Chain of Responsibility 

The chain of responsibility pattern passes a request to a chain of handlers, where each handler is responsible for handling the request or passing it to the next handler.

Figure 13: Chain of responsibility pattern

Table 13

Example: Although the code is opaque to the application, the Java exception handling uses the chain of responsibility concept. When an exception is thrown, the Java Virtual Machine (JVM) looks to see if the current context on the stack can handle the exception. If it can, the exception handler — defined using a catch block — is called; otherwise, the stack is popped, and the next context is checked to see if it can handle the exception. This process continues until a suitable exception handler is found or the entire stack is popped.

Command 

The command pattern stores a request, along with all the information necessary to handle the request, in a single object that can be executed by any client or queued for execution at a later time.

Figure 14: Command pattern

Table 14

Example: Undo operations can be implemented through the command pattern. Each time an action is taken, a command object can be created — with the logic and parameters necessary to undo the action — and pushed onto a stack. If the user presses the undo button, the command objects can be popped from the stack and executed, thus undoing the previous action.

Interpreter 

The interpreter creates an object-based representation of a grammar and interprets that representation.

Figure 15: Interpreter pattern

Table 15

Example: Many times, interpreters are used for resolving trees of expressions — mathematical expressions, regular expressions, simple natural language expressions, Boolean expressions, and programming language expressions — into an interpreted result. These sets of expressions are represented as ASTs and then iteratively interpreted until a result is resolved.

Iterator 

The iterator pattern abstracts the traversal of collections without exposing the details of the collection.

Figure 16: Iterator pattern

Table 16

Example: The Java Collection interface includes an iterator() method that returns a concrete implementation of the Iterator interface. This method is specified by the Iterable interface that the Collection interface extends. In Java, any class that implements the Iterable interface can be used in a for-each loop (enhanced for loop), which is made possible by the iterator returned by each implementing class (see the Java Language Specification, JLS, 14.14.2).

Mediator 

The mediator pattern encapsulates the communication between numerous objects into a single object.

Figure 17: Mediator pattern

Table 17

Example: The mediator pattern can be used to create an event or message broker, where each component that sends and receives messages can register with the broker. And as messages are sent to the broker, the broker passes the message onto one or more receivers based on some attribute (e.g., the to field) of the message.

Memento

The memento pattern stores a snapshot of the state of an object that can be used to restore that state at a later time.

Figure 18: Memento pattern

Table 18

Example: Similar to the command pattern, a memento can also be used to undo an operation. When an action is taken, a memento is stored in a caretaker and can be used later to undo the action. To undo the operation, a reference to both the originator and the memento is required. The command pattern can be used to create a command object with a reference to both, thus creating a single, self-contained object that can perform the undo operation.

Observer 

The observer pattern allows clients to subscribe to events that are published when an observed object is changed.

Figure 19: Observer pattern

Table 19

Example: The Java Event Listener framework is an application of the observer pattern, where the listener takes the role of the subscriber, and the object generating the event assumes the role of the subject. Note that there are many publish-subscribe (pub/sub) frameworks — not just in Java, but all languages — but pub/sub is not synonymous with the observer pattern. In some cases, a message broker is used as a mediator to completely decouple the publisher from the subscriber. 

State 

The state pattern alters the behavior of an object when its internal state changes.

Figure 20: State pattern

Table 20

Example: The state pattern can be used to lock the internal state of an object without checking a conditional statement, such as isLocked(), before each method call. Instead, the object can delegate its methods to a state object. When the lock() method is called on the context object, it can replace the state object with one that does nothing when the methods are called. When unlock() is called, the state object can be replaced with the original state object that performs the desired logic. 

Strategy

The strategy pattern encapsulates a set of algorithms as objects with a common interface. 

Figure 21: Strategy pattern

Table 21

Example: The Java Comparator interface represents a strategy interface, where a Comparator object can be passed to a method, such as Collections#sort(List, Comparator), to compare one object to another. In the case of Collections#sort, the order that a List is sorted depends on the Comparator strategy that is passed to the method.

Template Method 

The template method pattern provides a structure for an algorithm, while allowing subclasses to define the specific implementation for each step of the algorithm.

Figure 22: Template method pattern

Table 22

Example: The Jakarta EE HttpServlet abstract class implements default behavior for the doGet, doPost, and other basic HTTP methods by returning an HTTP 405 Method Not Allowed response. Clients are expected to override at least one of these methods to change how the servlet handles a request.

Visitor 

The visitor pattern separates an algorithm from the objects on which the algorithm is applied.

Figure 23: Visitor pattern

Table 23

Example: The Java FileVisitor class is an interface that clients can implement to perform a desired action each time a file is visited. The FileVisitor class can be used in conjunction with the Files#walkFileTree to iterate through the files under a desired path and perform the action defined in a concrete FileVisitor object when each file is visited.

While the 23 GoF patterns still stand as the cornerstone of software development design patterns, many patterns have been formalized since 1994. This section describes a few of these patterns commonly seen in our age of web applications and microservices.

Publish-Subscribe 

In many distributed and cloud systems, events and messages flow from one microservice to another without each microservice knowing who triggered the event or who is listening for its own events. This is possible because these services implement the pub/sub pattern, where publishers generate messages without knowing who is listening for them, and subscribers listen for messages without knowing who is generating them.

The pub/sub pattern is different from the observer pattern because, in many cases, the pub/sub pattern implementations use a message or event broker (e.g., RabbitMQ, Java Messaging Service [JMS]) to handle the forwarding of events. In this case, subscribers do not register directly with a publisher, but instead, both the publishers and subscribers register with a broker that acts like a mediator.

Filter 

As data flows from a data source to a data sink, it is commonly filtered out. To filter out data, a chain of filters is created, where data that flows out of one filter flows into the next. The Jakarta EE Filter and FilterChain classes implement the filter pattern, where filters are applied to incoming servlet requests. Likewise, the Spring Security Filter Chain is an implementation of the filter pattern. 

Model-View-Controller 

The model-view-controller (MVC) pattern designates a controller, which is responsible for managing a data model that is then displayed using a desired view. The model acts as a view-agnostic representation of the data being processed, and the controller is responsible for processing the data and designating the view or views that should be used to encode or display the data to the user. The MVC pattern is common among many web frameworks, including Spring Web MVC.

Thread Pool 

In many concurrent applications, threads are created and then released based on the workload being serviced at any given time. There is non-trivial overhead in creating new threads, which can cause a significant degradation in performance if workloads fluctuate. Instead of creating a new thread object each time a thread is needed, a pool can be created where released threads are returned back to the pool, and subsequent requests for threads can be serviced with threads already created in the pool. The Java ThreadPoolExecutor is an implementation of the thread pool pattern.

Reactor 

The reactor pattern defines a handler service that accepts multiple concurrent incoming requests and dispatches them to request handlers, which each handle a single request. This pattern is common for handling a large number of concurrent requests because the request handlers are usually small and agile enough to work in parallel to numerous service requests. The Spring Reactive framework is an implementation of the reactor pattern.

Design patterns are an essential part of software development, and knowledge of the most effective patterns is a prerequisite for becoming an experienced developer. The GoF patterns are the foundational patterns that have shaped the way software is written for many decades and are still relevant today. In the years since these patterns were enumerated, software engineering has grown and numerous patterns — such as the MVC and reactor patterns — have become ubiquitous.

Regardless of the software being developed, it is important to study a wide range of patterns and continuously practice them in order to gain the experience necessary to apply the right pattern to effectively solve the common problems seen in software development.

Further Reading 

Understanding and applying design patterns requires diligent practice. The following resources contain excellent descriptions and examples of design patterns that can help even the most seasoned developer internalize design patterns and instill the experience necessary to apply patterns at the right time and place:

• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
• Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software by Eric Freeman and Elisabeth Robson
• Patterns of Enterprise Application Architecture by Martin Fowler
• Refactoring Guru's Design Patterns