GuideIntermediate
Design Patterns
Learn to read someone else's code and name what you see — "this is a Strategy," "there's a God object here" — and, above all, to know when a pattern earns its complexity and when NOT to abstract, because every pattern adds indirection and indirection is a cost you pay. This guide isn't a catalog of the 23 GoF patterns to memorize: it covers the ones that actually show up in real code and in reviews, organized by the problem they solve — behavior that varies (Strategy, Template Method, State), creating objects (Factory, Builder, why you should distrust the Singleton), structure and adaptation (Adapter, Facade, Decorator, Composite), and communication between parts (Observer, Command). It also teaches the rule of three, YAGNI, and premature abstraction as the costliest mistake, and how to use patterns as review vocabulary: naming code smells (God object, feature envy, shotgun surgery) so a problem becomes actionable. You work on Boletia, an event-ticketing platform where everything varies — notification channels, payment providers, ticket types — and that also has the opposite problem: a plugin architecture built for something that will only ever have one implementation. It closes with a capstone project where you remove an abstraction that doesn't earn its keep and introduce the pattern that truly emerges from a 300-line checkout, in small, safe steps.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Understand what patterns really are: a named solution to a recurring problem, and shared vocabulary as their real superpower
- Recognize when NOT to abstract: the rule of three, YAGNI, and premature abstraction as the costliest mistake you can make
- Apply patterns for behavior that varies: Strategy to swap the "how," Template Method for a shared skeleton, and State when behavior depends on state
- Apply object-creation patterns: Factory to decide what to build in one place, Builder to assemble something complex step by step, and why to distrust the Singleton
- Apply structure and adaptation patterns: Adapter for incompatible interfaces, Facade for a simple door to something complex, Decorator, and Composite
- Apply communication patterns between parts: Observer to notify without knowing who's listening, coupling by event instead of direct call, and Command
- Use patterns as code review vocabulary: name code smells (God object, feature envy, shotgun surgery) and anti-patterns in an actionable way
- Run a capstone project: refactor two corners of Boletia — one over-patterned, one under-structured — and defend each decision with its trade-off
Before you start
What you need to bring
It's for you if...
- Developers already working on code spanning more than one file who feel the friction of touching something and breaking something else far away
- Devs who want to move from "I know 23 patterns by heart" to actually reading, naming, and judging them in real code
- People who need to name structural problems in three words during a code review
- Ideal (not required) for anyone who already completed the Software Development Foundations Guide
Requirements and materials
- Ability to program and experience working on code spanning more than one file: functions, classes, and objects
- Recommended (not required): the Software Development Foundations Guide completed (decomposition, coupling, cohesion, trade-offs)
- No prior knowledge of any design pattern required
- Examples use object-oriented Python
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: patterns as a language, not as recipes
- 2. A pattern is a named solution to a recurring problem
- 3. The real superpower: shared vocabulary
- 4. Where patterns come from (and why they aren't invented)
- 5. Spotting a pattern in someone else's code
- 6. The map: the few patterns that really matter
- 7. How NOT to study patterns
- 8. Project: name the patterns in Boletia
- 1. Module introduction: the pattern you didn't add
- 2. Every abstraction has a cost
- 3. The rule of three
- 4. Premature abstraction: the costliest mistake
- 5. YAGNI: you aren't gonna need it
- 6. The plugin-for-one-implementation antipattern
- 7. Coupling vs. indirection: pick your poison
- 8. Project: remove an abstraction that doesn't earn its keep
- 1. Module introduction: separate what changes from what doesn't
- 2. Strategy: swapping the how
- 3. Boletia's pricing rules as Strategy
- 4. Template Method: same skeleton, different steps
- 5. State: when the object behaves according to its state
- 6. In a language with first-class functions, do you need the class?
- 7. The trap: not every conditional is a hidden Strategy
- 8. Project: replace a giant conditional with judgment
- 1. Module introduction: the "how does this get built" problem
- 2. Factory: deciding what to build in one place
- 3. Boletia's payment providers as a Factory
- 4. Builder: assembling something complicated in parts
- 5. Singleton: the pattern to be most suspicious of
- 6. Dependency injection in plain words
- 7. When a plain constructor or function is enough
- 8. Project: tidy up provider creation
- 1. Module introduction: wrap, adapt, simplify
- 2. Adapter: making two incompatible interfaces understand each other
- 3. Boletia's messy payment API as Adapter
- 4. Facade: a simple door to something complicated
- 5. Decorator: adding behavior without touching the original
- 6. Composite: treating the whole and the part alike
- 7. The line at "just write a wrapper function"
- 8. Project: isolate an external dependency
- 1. Module introduction: who tells whom
- 2. Observer: notifying without knowing who's listening
- 3. Boletia's notifications as Observer
- 4. Coupling by event instead of by direct call
- 5. Command: packaging an action as an object
- 6. The hidden cost: the flow you can no longer trace with your finger
- 7. When a direct call is more honest
- 8. Project: decouple notification from purchase
- 1. Module introduction: naming is half of fixing
- 2. The vocabulary of what's wrong: code smells
- 3. God object, feature envy, shotgun surgery
- 4. Naming a problem in a review so it's actionable
- 5. Anti-patterns: when a "pattern" is the trap
- 6. Refactoring toward a pattern (and away from one)
- 7. The pattern as conversation, not verdict
- 8. Project: write review comments with vocabulary
- 1. Module introduction: the right pattern at the right time
- 2. Read the code before you touch it
- 3. Spotting the pattern that wants to emerge
- 4. Spotting the pattern to remove
- 5. Refactoring in small, safe steps
- 6. Justifying the change (the why, not the name)
- 7. When to leave ugly code alone
- 8. Final project: refactor a corner of Boletia and defend it
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!