Software design pattern Study Guide

📖 Core Concepts Design Pattern – a reusable solution description for a common software problem; it’s a template, not copy‑paste code. Design Motif – the “micro‑architecture” (classes, methods, relationships) that a pattern captures; developers adapt the motif to their own codebase. Pattern Categories – Creational (object creation), Structural (organizing classes/objects), Behavioral (object collaboration), Concurrency (parallel processing). Documentation Sections – Context, Forces, Solution, plus Problem, Consequences, Implementation (Gang of Four format). Domain‑Specific Patterns – UI, Information Visualization, Secure, and Web patterns address specialized concerns. Applicability – patterns work across languages & platforms but may clash with functional paradigms (mutable‑state patterns) or be unnecessary when a language offers built‑in support. 📌 Must Remember Patterns speed development, prevent hidden bugs, and improve readability for anyone familiar with them. Overuse → unnecessary complexity & indirection → possible performance hit. OO patterns show relationships without mandating concrete class names; they may be unsuitable for non‑OO languages. Concurrency patterns can be unsafe on certain hardware/language combos and may act as anti‑patterns. 🔄 Key Processes Identify the Problem & Forces – determine context, constraints, and what the design must achieve. Select a Pattern Category – match problem type (creation, structure, behavior, concurrency). Locate a Specific Pattern – choose the pattern whose documented forces align with yours. Map the Motif – adapt the pattern’s classes/methods to your codebase, preserving relationships. Implement & Refine – follow the “Solution” section, watch for language‑specific shortcuts that could replace the pattern. Validate Consequences – check readability, performance, and whether you introduced extra indirection. 🔍 Key Comparisons Creational vs. Structural – Creational focuses how objects are created; Structural focuses how objects are composed. Behavioral vs. Concurrency – Behavioral deals with object collaboration in a single thread; Concurrency adds parallel execution concerns. Pattern vs. Built‑in Language Feature – Pattern provides a design-level solution; a built‑in feature solves the same problem directly (may render the pattern unnecessary). ⚠️ Common Misunderstandings “Pattern = Code” – a pattern is a description; you must translate it into code that fits your domain. All Patterns Are Universal – some patterns rely on mutable state and clash with functional languages. More Patterns = Better Design – over‑patterning adds indirection and can hurt performance. 🧠 Mental Models / Intuition “Template, not a Blueprint” – think of a pattern as a recipe: you follow the steps but swap ingredients (classes, methods) to suit your dish (application). “Force‑Balance” – every pattern is about balancing competing forces (e.g., flexibility vs. simplicity); identify those forces first. 🚩 Exceptions & Edge Cases Language‑Provided Solutions – languages with native factories, dependency injection, or concurrency primitives may make the corresponding pattern redundant. Non‑OO Environments – OO patterns (e.g., Strategy, Observer) may be inapplicable or need heavy adaptation in procedural or functional code. Concurrency Anti‑Patterns – patterns that introduce unsafe parallelism on hardware lacking proper memory models. 📍 When to Use Which Need to hide object creation? → Use a Creational pattern (Factory, Builder). Need to simplify complex object graphs? → Use a Structural pattern (Adapter, Composite). Need to define flexible object interaction? → Use a Behavioral pattern (Strategy, Observer). Need to manage threads or async tasks? → Consider a Concurrency pattern (Thread Pool, Producer‑Consumer) only if the language lacks safe built‑in constructs. 👀 Patterns to Recognize Repeated “Plug‑in” Relationships → likely a Strategy or Decorator (Behavioral/Structural). Hierarchical “has‑a” trees → suggests Composite (Structural). Object creation through a separate “creator” class → points to Factory (Creational). Multiple threads sharing a queue → signals a Producer‑Consumer (Concurrency). 🗂️ Exam Traps Choosing a pattern because it sounds “cool” – exam answers will penalize selections that don’t match the stated forces. Selecting a pattern that introduces mutable state for a functional‑language question – wrong because of incompatibility with functional paradigms. Assuming every OO problem needs a pattern – distractors may list patterns for simple cases where a straightforward solution is preferred. Confusing “documentation format” sections – remember the Gof format includes Context, Problem, Solution, Consequences, Implementation; “Forces” is a separate documentation element. --- Use this guide to quickly recall what a design pattern really is, when it shines, and the red‑flags that can turn a good design into a bad one.