In 2001 ben ik afgestudeerd aan de Noordelijke Hogeschool Leeuwarden, opleiding Hogere Informatica. Tijdens bepaalde lessen zijn design-patterns wel behandeld, maar volgens mij niet heel uitgebreid. Ik ben "ooit" een blog-bericht tegengekomen waarin gesteld werd dat het boek Design Patterns Explained, geschreven door Alan Shalloway en James R. Trott een "must-read" is. Dat heb ik toen gekocht, het is op de plank gezet en daarna er niet meer afgekomen. Het is de 2e editie, gedateerd mei 2009, ik vermoed dat ik het rond die tijd gekocht heb. Omdat ik de afgelopen tijd wat mantelzorgactiviteiten had en daarvoor moest wachten heb ik het boek meegenomen en een aantal hoofdstukken doorgelezen. Afgelopen zondag, 22 april, heb ik de rest van het boek uitgelezen. Want als je ergens mee begint, moet je het ook afmaken.
Wat zijn nu eigenlijk design-patterns? Als je het hoort denk je aan bepaalde patronen die je kunt volgen en het werk voor je makkelijker/overzichtelijker maken. Deels is dat ook zo. Zo heb je in .NET het get/set pattern (misschien ook wel in andere programmeertalen). Even een kort voorbeeld:
class Test
{
private int _Amount = 0;
public void setAmount(int value)
{
_Amount = value;
}
public int getAmount()
{
return _Amount;
}
}
class TestGetterAndSetter
{
public int Amount { get; set; }
}
In de class TestGetterAndSetter is Amount een property geworden. Je hoeft niet meer zelf een interne variabele aan te maken, en ook het eventueel uitbreiden van het opvragen of instellen van de waarde hou je op deze manier centraal waardoor het ook voor een andere programmeur die je code voor het eerst ziet inzichtelijk is.
In het boek wordt echter ook een aantal voorbeelden gegeven van oplossingen die je zonder design-patterns zou maken (maak een class aan, laat andere classes daarvan overerven, etc.). Waarbij je ziet dat het een groot systeem wordt, moeilijk onderhoudbaar, veel afhankelijkheden. Zou er een nieuwe variant bij moeten komen (wees eerlijk, een klant komt vaak na verloop van tijd met de wens om zaken aan te passen of uit te breiden), dan zorgt het toevoegen van die ene variant een uitbreiding van het systeem met een 4-tal classes. Ehm, dat wil je niet. Haal er een bepaald pattern overheen zodat je visie op het probleem/mogelijke oplossing een andere insteek krijgt en zorg dat er een lean-en-mean oplossing komt (in het boek met het Factory Method Pattern). Dat ziet er inderdaad een stuk beter uit. Het kan dus zijn dat je op de "traditionele manier" een log systeem of helemaal geen oplossing kunt bedenken, maar door het toepassen van een design pattern een bepaalde abstractie kunt toevoegen waardoor de oplossing beter wordt of je juist eindelijk een oplossing voor het probleem kunt bedenken.
Zoals in het boek gezegd wordt is het mogelijk dat je bepaalde "patterns" al gebruikt zonder eigenlijk te weten dat het een "pattern" is. Door eigen ervaring heb je naar eigen inzicht al een soort standaardoplossing gemaakt. Wel wordt in het boek gezegd dat een "pattern" niet de heilige graal is, na verloop van tijd zul je door ervaring zelf zien of een pattern in jouw probleemsituatie past. Soms zelfs in combinatie met meerdere patterns.
Een mooie term in dit boek vind ik de "switch creep". Zelf ben ik een redelijke fan van het "switch-statement", het ziet er net even een stukje netter uit dan al die "if .. else... elseif ..."-bomen die je soms in je code hebt. Een switch-creep is het feit dat je bijvoorbeeld eerst een switch(countrycode){ case "NL": ... break; case "BE": ... break; } had, maar dat de klant internationaal gaat en je vervolgens alle landen moet gaan ondersteunen. In het boek komen we hierbij in aanraking met het Strategy Pattern. Verplaats al deze code naar een class, zodat daar de intelligentie uitgevoerd wordt en jij in jouw stuk code (het bepalen van de verzendkosten, het bepalen welke valuta gebruikt moet worden) met behulp van die class op een heldere manier de data kunt opvragen.
Maar goed, dan moet je wel weten welke patterns er zijn, daarvoor had ik dit boek ook gekocht. In het boek wordt verwezen naar het basisboek voor design-patterns van The Gang of 4 (dat komt mij inderdaad nog bekend voor van school), dat boek is van 1995 (!). Design Patterns, Elements of Reusable Object-Oriented Software, geschreven door Erich Gamma, Richard Helm, Ralph Johnson en John Vlissides. En ook nog te koop bij BOL, zowel als hardcover als e-book, nu dit boek nog op voorraad is meteen gekocht. Kijken hoe lang die op de plank blijft staan ;)
Aan het eind van het boek staan een aantal boeken genoemd, en ook een aantal links. Zo is er de link naar de website die bij dit boek hoort: http://www.netobjectives.com/resources/books/design-patterns-explained
Ik kan hier een overzicht geven van de patterns die in het boek benoemd worden, maar toen ik op de voorgaande link doorklikte, kwam ik uit op de PatternRespository, een WIKI! En ook nog een handige PDF met de Design Patterns Matrix. Doe er je voordeel mee. Nu maar proberen om de DP's in praktijk te brengen, zodat je het in je vingers krijgt en je een betere programmeur wordt. Go!