Book Exercise Lanes
These optional exercise lanes provide selective reinforcement. Required evidence is mapped in the core workshop. Use these local chunks for targeted volume after you have already learned the pattern from the guide. The goal is fluency and judgment, not completion.
How To Use This Page
- Finish the relevant concept page first and do at least one kata from the Practice section.
- Only then open the matching exercise lane.
- Work one lane before moving to the next.
- Keep a mistake log with tags such as
cargo-culted factory,adapter leaks adaptee types,decorator hides behavior,proxy confused with decorator,singleton hides scope,hidden infrastructure construction, orconfig read outside boundary.
Book links below identify topic assignments; book-level destinations do not promise a particular edition's page or section. Use the guide first; no purchase or full-book reading is required.
Lane 1: Creational Construction
Use this lane when the pain is construction complexity, variation of concrete types, or immutability discipline.
- Head First: Factory Pattern (intro)
- Head First: Simple Factory / Factory Method / Abstract Factory
- Head First: Factory Method Pattern Defined
- Head First: Abstract Factory Pattern Defined
- GoF: Factory Method / Abstract Factory / Builder / Prototype / Singleton
- Good Code, Bad Code: The Builder Pattern
- Refactoring: Replace Constructor with Factory Function
Target outcomes:
- 3 factory-method implementations, each with at least two concrete creators
- 1 abstract-factory implementation with two product kinds and two families
- 1 fluent Builder with invariants enforced in
build() - 1 deletion refactor: a cargo-culted factory removed and replaced with a direct constructor call
Lane 2: Interface Bridging
Use this lane when the pain is integration with third-party or legacy code, or subsystem complexity.
- GoF: Structural Patterns (chapter intro)
- GoF: Adapter -- Applicability / Sample Code
- GoF: Facade -- Participants / Known Uses
- GoF: Bridge -- Intent / Participants / Sample Code / Known Uses
- Head First: The Adapter and Facade Patterns (chapter)
- Head First: Enumeration-Iterator Adapter
- Head First: Lights, Camera, Facade
Target outcomes:
- 2 adapters against real third-party libraries, each with at least one exception mapping
- 1 facade over a subsystem you use regularly, covering the common 80% case
- 1 written paragraph distinguishing Adapter from Facade using your own example
- 1 Bridge sketch (may remain a sketch) with a written defense of whether you would actually build it
Lane 3: Composition and Layering
Use this lane when the pain is behavior layering, tree operations, or controlled access.
- GoF: Composite -- Implementation / Sample Code / Known Uses
- GoF: Decorator -- Implementation / Sample Code
- GoF: Proxy -- Implementation / Sample Code
- Head First: Open/Closed + Decorator chapter
- Head First: Real-World Java I/O
- Head First: Composite chapter
- Head First: Proxy chapter
Target outcomes:
- 1 Composite over a real tree structure (menu, file system, widget tree)
- 1 Decorator pipeline with at least three layers wrapping a real interface
- 1 virtual or caching Proxy over a slow resource
- 1 written paragraph distinguishing Decorator from Proxy by intent
Lane 4: Pragmatic Selection and DI
Use this lane when you have the vocabulary but need to build judgment: when to apply, when to delete, and how to wire.
- GoF: 1.5 Organizing the Catalog / 1.7 How to Select / Designing for Change
- Head First: Better Living with Patterns (chapter 13)
- Head First: May the Force Be with You (Parts 1 & 2)
- Head First: The Patterns Zoo
- Clean Code: Chapter 11 -- Systems / Dependency Injection
- Good Code, Bad Code: DI / Composition over Inheritance
- GoF: Class vs Interface Inheritance / Delegation
Target outcomes:
- 4 design briefs: pick the right pattern for a given scenario, with written justification
- 2 "delete a pattern" refactors with before/after diffs
- 1 composition root for a small app with at least three injected infrastructure collaborators
- 1 test composition root that swaps in fakes
- 1 written memo on DI vs service locator referencing one example from your own code
Required evidence and optional extra volume
The core workshop replaces the old implementation-count inventory. Complete P01–P20, the five executable groups, E1–E3 and the reused design project, then C01–C06 and SC1–SC6. Map existing work to those claims; do not build a second copy for exercise-page credit.
The lane counts above are optional targeted repetition after a specific gap is identified. They are not cumulative completion quotas. A fake provider is sufficient for required boundary checks; a real third-party SDK is optional depth. Retain the broader pattern reasoning, original attempts, repairs and changed-case defense within the published workload.
Completion Checklist
- Core workshop and composition-contract evidence are mapped to every required gate.
- Actual mistakes and repairs are retained; deliberately faulty examples are labeled separately.
- Construction, interface bridging and composition choices are defended against simpler alternatives.
- Resource ownership and configuration boundaries are explicit.
- A fresh changed case and delayed recheck support the result.
Composition-contract evidence
Complete composition trace practice, the replacement lab and SC1–SC6. The core workshop maps the required broader pattern topics; optional lane counts are not added to that workload.