Module 4: Structural & Creational Patterns
Primary texts: Head First Design Patterns (approachable narratives), Design Patterns by GoF (canonical vocabulary) Selective support: Refactoring, Clean Code, Good Code, Bad Code, and OOAD chunks where they sharpen construction, bridging, composition, or injection judgment
This guide is the primary teacher. You do not need to read the pattern books end to end. You do need to become operationally strong at choosing which pattern (if any) relieves real pressure, implementing it cleanly in one of your working languages, and recognizing the misuses that turn patterns into ceremony.
Scope of This Module
This module is not a pattern catalog to memorize. It is where you learn to tell the difference between a pattern that solves a real problem and a pattern that has been bolted on because it felt professional.
What it covers in depth:
- creational control: Factory Method, Abstract Factory, Builder, and the narrower role of Prototype and Singleton
- structural interface bridging: Adapter to reconcile mismatched APIs, Facade to hide subsystem complexity, Bridge to decouple abstraction from implementation
- structural composition: Composite to treat a tree as a leaf, Decorator to stack behavior without a subclass explosion, Proxy to intercept access
- pragmatic selection: pattern categories, cargo-culting warning signs, and when a closure or a function is the real answer
- dependency injection as a design technique and composition roots as the single place wiring happens
What it deliberately does not try to finish here:
- the entire GoF catalog (behavioral patterns are in Module 3; a few minor patterns are referenced but not drilled)
- DI container configuration for specific frameworks (touched only as composition-root examples)
- architectural patterns beyond single-process design (those belong to later systems modules)
If you can draw a class diagram but cannot explain what problem the pattern is solving in the running code, you are not done.
Before You Start
Use the prerequisite diagnostic. It tests callbacks, snapshots, failure state and regression reasoning already taught in Modules 1–3. Pattern vocabulary is learned here; it is not an entry condition.
What This Module Is For
These patterns are not the point. The forces behind them are the point. Later engineering work repeatedly asks questions like:
- where do I put the
ifthat chooses between concrete implementations? - how do I integrate a third-party library without letting its shape leak everywhere?
- how do I add a feature without subclassing or rewriting the caller?
- how do I make this class testable without mocking half the world?
- where in the application does the wiring happen, and how do I keep it out of the domain?
This module builds the design reasoning needed for:
- plugin architectures, strategy registration, and configuration-driven behavior
- legacy integration, third-party SDK wrapping, and anti-corruption layers
- middleware pipelines, request decoration, and access control
- dependency-injected, test-first services and composition roots
- informed code review where you can name the force the pattern is solving
You are learning to reach for a pattern only when plainer options run out.
Concept Map
How To Use This Module
Work in order. The later clusters only make sense if the earlier construction and bridging habits are stable.
Cluster 1: Creational -- Construction Flexibility
| Order | Concept | Type | Focus |
|---|---|---|---|
| 1 | Factory Method | PRIMARY | Letting subclasses choose the concrete product |
| 2 | Abstract Factory | PRIMARY | Families of related objects that must match |
| 3 | Builder | PRIMARY | Fluent, step-wise construction of complex values |
| 4 | Prototype and Singleton | SUPPORTING | When copying or single-instance is right, and when it is a smell |
Cluster mastery check: Can you explain in one sentence which force each creational pattern relieves, and when the right answer is just new?
Cluster 2: Structural -- Interface Bridging
| Order | Concept | Type | Focus |
|---|---|---|---|
| 5 | Adapter | PRIMARY | Reconciling incompatible interfaces |
| 6 | Facade | PRIMARY | Simplifying a subsystem's API for the common case |
| 7 | Bridge | SUPPORTING | Separating an abstraction from its implementation hierarchy |
Cluster mastery check: Can you tell an Adapter from a Facade from a Bridge without drawing the canonical diagram?
Cluster 3: Structural -- Composition and Layering
| Order | Concept | Type | Focus |
|---|---|---|---|
| 8 | Composite | PRIMARY | Treating an individual and a group uniformly |
| 9 | Decorator | PRIMARY | Layering behavior without a subclass explosion |
| 10 | Proxy | PRIMARY | Controlling access, laziness, and indirection |
Cluster mastery check: Can you distinguish Decorator from Proxy by the intent of the wrapper, not just its structure?
Cluster 4: Pragmatic Pattern Selection
| Order | Concept | Type | Focus |
|---|---|---|---|
| 11 | Pattern Categories and When to Apply Them | PRIMARY | Creational / structural / behavioral as a selection aid |
| 12 | Pattern Misuse and Cargo-Culting Warning Signs | PRIMARY | The smells that mean the pattern is hurting you |
| 13 | Simpler Alternatives: Closures, Higher-Order Functions, Composition | SUPPORTING | When a function or a pair of callbacks is the real pattern |
Cluster mastery check: Can you argue both sides of "should we introduce a factory here?" and pick one with a reason?
Cluster 5: Dependency Injection and Composition Roots
| Order | Concept | Type | Focus |
|---|---|---|---|
| 14 | Dependency Injection as a Design Technique | PRIMARY | Passing collaborators in, not constructing them inside |
| 15 | Composition Roots and Configuration Boundaries | SUPPORTING | One place where wiring happens, nowhere else |
Cluster mastery check: Can you locate the composition root, identify configured service wiring, and distinguish it from ordinary value construction elsewhere?
Then work these practice pages:
| Order | Practice path | Focus |
|---|---|---|
| 1 | Creational Patterns Lab | Factory Method, Abstract Factory, Builder in real code |
| 2 | Interface Bridging Workshop | Adapter and Facade against a real third-party shape |
| 3 | Composition and DI Clinic | Composite, Decorator, Proxy, and the DI wiring that makes them testable |
| 4 | Code Katas | Short deliberate-practice drills on all major patterns |
Use Module Quiz after the concept and practice path. Use Reference and Selective Reading and Learning Resources only for targeted reinforcement.
Learning Objectives
By the end of this module you should be able to:
- Choose between Factory Method, Abstract Factory, Builder, and a plain constructor, with a written reason.
- Implement Adapter and Facade to isolate third-party or legacy code from your domain.
- Use Composite to hide the difference between an individual and a group.
- Use Decorator to add cross-cutting behavior without modifying the decorated class.
- Use Proxy to control access, defer work, or remote a call.
- Recognize cargo-culted patterns by smell: inheritance-for-reuse, ceremony without variation, and abstraction-without-need.
- Refactor pattern-heavy code into closures or higher-order functions where the language allows.
- Inject dependencies through constructors and tell why service locators are usually worse.
- Identify a composition root and keep wiring out of the domain.
- Defend a pattern choice to a skeptical reviewer in fewer than five sentences.
Outputs
- the core workshop: P01–P20, five executable groups, three experiments and one reused design project, with evidence shared across related tasks
- one "wrapped third party" exercise: Adapter + Facade around a supplied fake boundary, with a real SDK/HTTP-client comparison as optional depth
- one decorator pipeline for a real cross-cutting concern (logging, retry, caching, or auth)
- one small app (CLI, HTTP service, or game loop) that has a named, isolated composition root
- one refactoring before-and-after that removes a cargo-culted pattern and replaces it with a closure, a first-class function, or plain composition
- an honest repair/decision record for observed defects or rejected designs; no invented mistake quota
- one short memo explaining how Module 4 patterns land in Module 5 (review) and in later systems work (frameworks, plugin loading, test doubles)
Completion Standard
You have completed Module 4 when all of these are true:
- you can justify each pattern choice by naming the specific change pressure it is absorbing
- you can tell Adapter from Facade, Decorator from Proxy, and Factory Method from Abstract Factory without hedging
- you pass every core C01–C06 and extension SC1–SC6 gate with independent evidence; speed is not a gate
- you can delete a pattern that is not earning its keep and leave the code better
- you can separate configured service wiring from domain behavior while allowing ordinary domain values to be constructed where needed
- you can argue the position that "a function would be enough here" when it is true, and the opposite when it is not
If the answer looks like "I memorized the diagram," the module is not complete.
Reading Policy
- Concept pages are the main path.
- Local book chunks are selective reinforcement, not a second syllabus.
Read only if stuckmeans try the concept page, write the pattern in your own code, and review the mini drill first.Optional deep divemeans additional nuance, alternate languages, or history, not required progression.- Pattern names are vocabulary; earned reasons are the real deliverable.
Suggested Study Blocks
| Block | Work |
|---|---|
| 1 | Concepts 1-4 and one Factory Method + Builder implementation |
| 2 | Concepts 5-7 and one Adapter wrapping a real third-party shape |
| 3 | Concepts 8-10 and a Decorator pipeline with at least three layers |
| 4 | Concepts 11-13 and one "delete a pattern" refactor |
| 5 | Concepts 14-15 and one composition-root sketch for a real app |
| 6 | Practice pages 1-2 and targeted chunk reinforcement |
| 7 | Practice pages 3-4, quiz, and mistake-log cleanup |
Reference
If you need exact links into the local chunked books, use Reference and Selective Reading.
Rich Learning Pages
Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread
Required composition-contract extension
Complete concepts 16–18 and the executable lab, then pass SC1–SC6. The 18–26 hour replacement package supersedes the old two-hour quote exercise. The seven blocks above indicate sequence, not a validated seven-day duration. Budget 65–95 hours for the complete module, including this extension once; see the semester workload ledger. Independent review and learner pilots remain pending.