Defining Design Patterns

Design patterns capture proven solutions to recurring design problems. They provide a shared vocabulary and reusable design strategies that make object-oriented systems easier to understand, extend, and maintain.

A design pattern is a named, reusable description of how collaborating classes and objects solve a recurring problem in a particular context. Patterns are language-independent and focus on structure and collaboration, not specific APIs or syntax.

• Not a data structure or algorithm: Lists, hash tables, and sorting algorithms are concrete implementations, not patterns.
• Not a full application architecture: Patterns are smaller-scale building blocks that can be combined within larger designs.
• Not one fixed recipe: A pattern guides intent and trade-offs; the final class layout can vary by context and language.

1. Creational: control object creation to improve flexibility and reuse (e.g., abstract construction, deferred instantiation).
2. Structural: compose classes/objects to form larger structures while keeping coupling low (e.g., adaptation, composition, proxying).
3. Behavioral: define object interaction and responsibility distribution (e.g., message routing, state-dependent behavior, strategies).

• Name & Intent: The pattern’s shorthand and the problem it solves.
• Problem & Context: When you encounter the issue and constraints that matter.
• Forces: Competing concerns (e.g., flexibility vs. simplicity, performance vs. decoupling).
• Solution: Core structure and collaborations among participants.
• Participants & Collaborations: Roles of classes/objects and how they interact.
• Consequences: Benefits, liabilities, and trade-offs.
• Implementation notes / Known uses / Related patterns: Practical tips, where it appears, and how it composes with others.

• Shared language: Saying “use Strategy” or “apply Adapter” compresses complex intent into a few words.
• Reusability & consistency: Avoids ad-hoc solutions; encourages proven structures.
• Lower coupling, higher cohesion: Clear roles and interfaces make code safer to change.
• Testability & extensibility: Abstractions (interfaces, composition) make behavior easier to substitute and extend.

Patterns are optional tools, not mandates. Overuse introduces needless abstractions; misapplied patterns can obscure simple code. Pick a pattern only when its forces match your context and the consequences are acceptable.

Encapsulation improves long-term maintainability. Prefer accessing state through well-named methods (or properties) rather than direct field access. This keeps callers stable when representation changes and aligns with pattern intent (e.g., Strategy hides variant behavior; Proxy hides access mechanics).

The remainder of this module surveys each category and introduces representative patterns with motivation, structure, and trade-offs so you can choose the right pattern for the problem at hand.