Prepping for a technical interview by designing a ride cost estimation system โ base fare, premium fare, surge pricing, all calculating cost differently from the same input. Classic Strategy setup.
- When the goal stays fixed but the algorithm changes, that's Strategy โ one interface, many interchangeable implementations, no if/else chain
- The interface only declares what a strategy does, never how โ each concrete class fills in the how on its own
- Decorator stacks naturally on top of Strategy โ a surge pricing wrapper can multiply any existing strategy's result without either side knowing about the other
- Stacking multiple surges at once (peak hour, bad weather) is where Builder comes in โ chain the conditions, and the final
build()call returns the fully composed strategy - Open/Closed shows up without even trying here โ adding a new pricing model means writing one new class, not touching the ones that already work
- Strategy, Decorator, and Builder weren't competing options for this problem โ they were layers, each solving a different part of it at the same time