Gisteravond heb ik bij SnelStart een korte presentatie gegeven over het State Pattern. Wat is het, waar gebruiken we het voor en waarom?
Als we naar een pattern kijken als een ’type oplossing, voor een type probleem’ dan is het niet alleen belangrijk om het probleem dat een pattern oplost te kennen, maar ook te kunnen herkennen. Kennen: Het state pattern is de oplossing voor het type probleem waarbij we een class hebben die, afhankelijk van de state waarin hij verkeerd, ander gedrag moet vertonen bij het aanroepen van zijn methoden. Herkennen: De naïeve oplossing voor dit type probleem is het introduceren van een enumeratie en in elke methode een switch/case statement om de juiste code uit te voeren. Aan deze combinatie kun je een goede kandidaat voor gebruik van het state pattern gelijk herkennen.
Natuurlijk blijft dan nog de vraag over waarom het gebruik van het state pattern beter is dan die naïeve implementatie. Er zijn tal van argumenten te noemen, maar de belangrijkste voor mij zijn testbaarheid en onderhoudbaarheid. Een implementatie op basis van polymorfisme in plaats van een aantal conditionele switches, verminderd bijna altijd het aantal testgevallen dat je moet vangen in je unit tests. Daarnaast, onderhoudbaarheid: Bedenk wat er gebeurd wanneer iemand een state-enumeratie uitbreidt met een nieuwe waarde en een switch/case statement vergeet aan te passen. Je programma compileert, je testen draaien nog en toch zit er waarschijnlijk een grote bug in je programma. Met een state pattern heb je dit niet omdat je compiler je dwingt om de nieuwe state volledig te implementeren.
Maar wat is het state pattern dan precies? Een state pattern kenmerkt zich door een outer class die zelf geen gedrag implementeert, maar alle aanroepen delegeert naar een inner class die de huidige staat van de outer class omschrijft. Een voorbeeld in UML zie je hieronder.
Nu zegt een plaatje meer dan duizend woroden, maar is code nog veel mooier. Hier kun je een visual studio C# solution met vier projecten downloaden met een gedetaileerde implementatie van het state pattern en een stap-voor-stap refactoring hier naar toe vanaf een naïeve implementatie.