Filter by category, search real-world analogies, or inspect multi-language implementations in C++, Python, and Java.
Browse the complete encyclopedia or click on any category card above to inspect its specific patterns.
One unified interface, multiple underlying forms — the foundational bedrock of all software design patterns.
A module or class should have one, and only one, reason to change.
Software entities should be open for extension, but closed for modification.
Subtypes must be substitutable for their base types without altering program correctness.
Clients should not be forced to depend upon interfaces that they do not use.
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Code lives in pure functions; data lives in passive, transparent data structures without encapsulated methods.
Treat data as immutable values that can never change once created. Transformations produce new data.
Separate data schema from data representation. Validate data dynamically via explicit contracts.
Organize data in memory to match CPU cache lines and SIMD hardware for orders-of-magnitude faster batch processing.
Decouple game and domain architecture into Entities (IDs), Components (raw data), and Systems (pure logic).
Define an interface for creating an object, but let subclasses decide which class to instantiate.
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Attach additional responsibilities to an object dynamically without modifying its structure.
Decouple an abstraction from its implementation so that the two can vary independently.
Fit more objects into the available amount of RAM by sharing common parts of state between multiple objects.
Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
Access the elements of an aggregate object sequentially without exposing its underlying representation.
Reduce chaotic dependencies between objects by restricting direct communications between the objects and forcing them to collaborate only via a mediator object.
Capture and externalize an object’s internal state without violating encapsulation, so that the object can be restored to this state later.
Try adjusting your search query or reset the category filter.