Design Patterns learning path: everything to study, topic by topic

Ensuring a class has only one instance and providing a global access point. Covers thread-safety concerns, lazy vs eager initialization, and testability tradeoffs.

Defining an interface for creating objects but letting subclasses decide which classes to instantiate. Promotes loose coupling and the Open/Closed principle.

Providing an interface for creating families of related objects without specifying their concrete classes. Useful for platform-independent UI components and product families.

Separating the construction of a complex object from its representation, allowing the same construction process to create different representations.

Creating new objects by copying an existing object (the prototype). Covers shallow vs deep copy semantics, clone registries, and performance implications.

Converting the interface of a class into another interface that clients expect. Covers class adapters (inheritance) vs object adapters (composition) and integration scenarios.

Decoupling an abstraction from its implementation so the two can vary independently. Avoids the Cartesian product explosion of subclasses.

Composing objects into tree structures to represent part-whole hierarchies. Lets clients treat individual objects and compositions uniformly.

Attaching additional responsibilities to an object dynamically. Provides a flexible alternative to subclassing for extending functionality.

Providing a simplified interface to a complex subsystem. Reduces dependencies on internal components and promotes the Law of Demeter.

Using sharing to efficiently support large numbers of fine-grained objects. Separates intrinsic (shared) state from extrinsic (context-specific) state.

Providing a surrogate or placeholder for another object. Covers virtual proxies (lazy loading), protection proxies (access control), and remote proxies (RPC).

Passing requests along a chain of handlers, where each handler decides whether to process the request or pass it to the next handler in the chain.

Encapsulating a request as an object, enabling parameterization, queuing, logging, and undo/redo operations.

Defining a one-to-many dependency so that when one object changes state, all its dependents are notified automatically. Foundation of event-driven systems.

Defining a family of algorithms, encapsulating each one, and making them interchangeable. Enables runtime algorithm selection without changing the context class.

Defining the skeleton of an algorithm in a base class, deferring some steps to subclasses without changing the algorithm's overall structure.

Allowing an object to alter its behavior when its internal state changes. The object appears to change its class.

Defining an object that encapsulates how a set of objects interact. Promotes loose coupling by preventing objects from referring to each other explicitly.

Providing a way to sequentially access elements of a collection without exposing its underlying representation.

SRP: a class should have only one reason to change. OCP: software entities should be open for extension but closed for modification. Underpins most pattern applications.

LSP: subtypes must be substitutable for their base types. ISP: clients should not be forced to depend on interfaces they do not use.

High-level modules should not depend on low-level modules — both should depend on abstractions. Directly enables Dependency Injection and testable architectures.

Knowing when NOT to use a pattern. Covers over-engineering, premature abstraction, pattern obsession, and common misapplications like Singleton abuse and inappropriate Visitor.