All 23 classic patterns plus dependency injection and repositories, each solving a real problem in Pedal, a city bike-share: docks that release different vehicles, payment providers with clashing APIs, bikes that change state, promo rules written by marketing. Every page shows the pain first, draws the pattern, runs the code in Python, TypeScript and Java, and says when not to use it.
The Low-level design track's patterns module is a short tour of the handful that come up in almost every interview. This track gives every pattern its own page: the problem it solves, a drawing of its roles, the change it makes cheaper, runnable code, a lab, and the simpler option to reach for first. Pedal is the same app the Architecture styles track builds, so here you see it up close, one class at a time.
Start from the problem in front of you. Read across a row for one pattern; the last column names the pattern people most often mix it up with.
| Pattern | Use it when | In Pedal | Often confused with |
|---|---|---|---|
| Factory method | Which class to create depends on who is creating | Each kind of dock releases its own vehicle | Simple factory, abstract factory |
| Abstract factory | Objects must come as a matching set | Each city's lock, terminal and display | Factory method |
| Builder | An object has many optional parts | A ride receipt with optional lines | Constructor with ten arguments |
| Prototype | Copying a configured object is easier than building it | New fare plans start as copies | Builder |
| Singleton | Exactly one shared instance | The pricing config | A global variable; dependency injection |
| Adapter | An interface doesn't match the one you need | Two payment providers, one interface | Facade, decorator |
| Decorator | Add behaviour around an object without editing it | Logging and retries around fares | Proxy, inheritance |
| Facade | A subsystem is too busy for its callers | One startRental() call | Adapter, mediator |
| Proxy | Access to an object needs control | A remote dock, a cached availability count | Decorator |
| Composite | Single items and groups should look the same | City, zones and stations count free bikes | Decorator |
| Bridge | Two things vary independently | Alert kinds × delivery channels | Strategy, adapter |
| Flyweight | Too many objects repeat the same data | 40,000 bikes share a few model records | Cache, singleton |
| Strategy | One step has interchangeable algorithms | Member, pay-as-you-go and student pricing | State, template method |
| State | Behaviour depends on a changing state | Docked, in use, faulty, in repair | Strategy |
| Template method | Fixed steps, some filled in by subclasses | Each city's monthly report | Strategy, factory method |
| Command | Requests must be queued, logged or undone | Operator actions on docks | Strategy, memento |
| Chain of responsibility | Several handlers may deal with a request | Unlock checks in order | Decorator, pipes and filters |
| Observer | Others must react without the source knowing them | A return notifies billing and the map | Mediator, event bus |
| Mediator | Many objects talk to each other in a tangle | A station controller for its docks | Observer, facade |
| Iterator | Walk a collection without knowing its storage | A member's trips, page by page | A plain loop over a list |
| Visitor | New operations over a fixed set of classes | Export the fleet two ways | Pattern matching |
| Memento | Undo without exposing an object's insides | A route plan being edited | Command |
| Interpreter | Rules written in a small language | Promo rules from marketing | A parser library |
| Dependency injection | Objects find their own dependencies | Real payments in production, fakes in tests | Singleton, service locator |
| Repository and unit of work | Domain code is tangled with storage | Rides and payments saved together | DAO, active record |
About 40 minutes a day. Before each page, read its first section and sketch your own fix for ten minutes, then compare.
| Week | Study | Output by Friday |
|---|