Design Patterns: An index of GoF and POSA Patterns

Knowing where to look for a design pattern or set of patterns that solve a particular problem can be time-consuming and frustrating. Here I compile all of the design patterns from the GoF book and the first two volumes of the POSA books to help you discover where to go for a deeper look.

 

Design Patterns: Elements of Reusable Object-Oriented Software

Pattern NameCategoryShort Description
Abstract FactoryCreationalProvide an interface for creating families of related or dependent objects without specifying their concrete classes.
BuilderCreationalSeparate the construction of a complex object from its representation so that the same construction process can create different representations.
Factory MethodCreationalDefine an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
PrototypeCreationalSpecify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
SingletonCreationalEnsure a class only has one instance, and provide a global point of access to it.
AdapterStructuralConvert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
BridgeStructuralDecouple an abstraction from its implementation so that the two can vary independently.
CompositeStructuralCompose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
DecoratorStructuralAttach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
FacadeStructuralProvide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
FlyweightStructuralUse sharing to support large numbers of fine-grained objects efficiently.
ProxyStructuralProvide a surrogate or placeholder for another object to control access to it.
Chain of ResponsibilityBehavioralAvoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
CommandBehavioralEncapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
InterpreterBehavioralGiven a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
IteratorBehavioralProvide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
MediatorBehavioralDefine an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
MementoBehavioralWithout violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.
ObserverBehavioralDefine a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
StateBehavioralAllow an object to alter its behavior when its internal state changes. The object will appear to change its class.
StrategyBehavioralDefine a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Template MethodBehavioralDefine the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
VisitorBehavioralRepresent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Pattern-Oriented Software Architecture Volume 1

Pattern NameCategoryShort Description
LayersArchitectural: From Mud to StructureHelps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particularlevel of abstraction.
Pipes and FiltersArchitectural: From Mud to StructureProvides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems.
BlackboardArchitectural: From Mud to StructureUseful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.
BrokerArchitectural: Distributed SystemsCan be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.
Model-View-ControllerArchitectural: Interactive SystemsDivides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.
Presentation-Abstraction-ControlArchitectural: Interactive SystemsDefines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.
MicrokernelArchitectural: Adaptable SystemsApplies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.
ReflectionArchitectural: Adaptable SystemsProvides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.
Whole-PartDesign: Structural DecompositionHelps with the aggregation of components that together form a semantic unit. An aggregate component, the Whole, encapsulates its constituent components, the Parts, organizes their collaboration, and provides a common interface to its functionality. Direct access to the Parts is not possible.
Master-SlaveDesign: Organization of WorkSupports fault tolerance, parallel computation and computational accuracy. A master component distributes work to identical slave components and computes a final result from the results these slaves return.
ProxyDesign: Access ControlMakes the clients of a component communicate with a representative rather than to the component itself. Introducing such a placeholder can serve many purposes, including enhanced efficiency, easier access and protection from unauthorized access.
Command ProcessorDesign: ManagementSeparates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as the storing of request objects for later undo.
View HandlerDesign: ManagementHelps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update.
Forwarder-ReceiverDesign: CommunicationProvides transparent inter-process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms.
Client-Dispatcher-ServerDesign: CommunicationIntroduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers.
Publisher-SubscriberDesign: CommunicationHelps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.
Counted PointerMemory Mangement: C++ IdiomMakes memory management of dynamically- allocated shared objects in C++ easier. It introduces a reference counter to a body class that is updated by handle objects. Clients access body class objects only through handles via the overloaded operator->().

Pattern-Oriented Software Architecture Volume 2

Pattern NameCategoryShort Description
Wrapper FacadeService Access and ConfigurationEncapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces.
Component ConfiguratorService Access and ConfigurationAllows an application to link and unlink its component implementations at run-time without having to modify, recompile, or statically relink the application. Component Configurator further supports the reconfiguration of components into different application processes without having to shut down and re-start running processes.
InterceptorService Access and ConfigurationAllows services to be added transparently to a framework and triggered automatically when certain events occur.
Extension InterfaceService Access and ConfigurationAllows multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of the component.
ReactorEvent HandlingAllows event-driven applications to demultiplex and dispatch service requests that are delivered to an application from one or more clients.
ProactorEvent HandlingAllows event-driven applications to efficiently demultiplex and dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities.
Asynchronous Completion TokenEvent HandlingAllows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services.
Acceptor-ConnectorEvent HandlingDecouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized.
Scoped LockingSynchronizationEnsures that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path from the scope. C++ idiom.
Strategized LockingSynchronizationParameterizes synchronization mechanisms that protect a component's critical sections from concurrent access.
Thread-Safe InterfaceSynchronizationMinimizes locking overhead and ensures that intra-component method calls do not incur `self-deadlock' by trying to reacquire a lock that is held by the component already.
Double-Checked Locking OptimizationSynchronizationReduces contention and synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution.
Active ObjectConcurrencyDecouples method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control.
Monitor ObjectConcurrencySynchronizes concurrent method execution to ensure that only one method at a time runs within an object. It also allows an object's methods to cooperatively schedule their execution sequences.
Half-Sync/Half-AsyncConcurrencyDecouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing.
Leader/FollowersConcurrencyProvides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, and process service requests that occur on the event sources.
Thread-Specific StorageConcurrencyAllows multiple threads to use one `logically global' access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.

Other Design Pattern Resources