Het Strategy pattern is een manier om je code zo in te delen dat een programma tijdens het draaien kan kiezen tussen meerdere uitwisselbare manieren om een taak te doen. Elke manier zit in zijn eigen klasse achter een gedeelde interface, zodat de rest van het programma gewoon om ‘de strategie’ vraagt zonder te weten welke het krijgt. De aanroepende code blijft simpel. Alle variatie zit verstopt achter die ene gedeelde vorm, en jij schuift de versie naar binnen die je nodig hebt.
Denk aan een navigatie-app. Je vraagt om een route en kiest snelste, kortste of zonder tol. De app schrijft zichzelf niet opnieuw voor elke keuze. Hij plugt simpelweg een andere routestrategie in en draait die. De berekening wisselen is een aanpassing van één regel, en een vierde optie toevoegen raakt de rest van de app niet aan. Het kaartscherm, de zoekbalk, de opgeslagen ritten: geen van die delen weet of het iets uitmaakt welke routelogica eronder draaide.
In code is dit een van de klassieke ontwerppatronen. Een bekend voorbeeld is betalen. Je hebt een kaart-strategie, een iDEAL-strategie en een PayPal-strategie, elk met dezelfde pay()-methode. De checkout roept pay() aan en de juiste draait. Komt er een nieuwe provider bij, dan schrijf je één nieuwe klasse en registreer je hem. Je hoeft nooit door een wirwar van if-else-statements te spitten die groeit zodra het bedrijf een regel toevoegt. De winst is minder condities en code die makkelijker te testen is, want elke strategie controleer je op zichzelf, los van de rest, met een eigen klein setje gevallen. De prijs is een paar extra klassen. Dus het loont alleen als je echt meerdere gedragingen hebt om tussen te wisselen.
Bij TopDevs pakken we het Strategy pattern als een klant pluggable logica nodig heeft, zoals wisselbare prijsregels of verzendberekeningen, zodat nieuwe opties erbij kunnen zonder de werkende delen in gevaar te brengen.
