Ontwerppatronen – extra informatie

Ontwerppatronen en opkomende architectuur

Een patroon is een ontwerpfragment dat helpt om een veel voorkomend “probleem” op een standaard manier op te lossen. Een goede patroonbeschrijving begint met de “intent”: een korte beschrijving van het probleem en de manier waarop het patroon een oplossing vormt. De geadresseerde problemen zijn vaak gerelateerd aan ongewenste afhankelijkheden tussen code modules. Toepassing van ontwerppatronen kan dus helpen om software modulairder te maken en daarmee de niet-functionele eigenschappen te realiseren. De nadruk bij patroontoepassing ligt op de softwarestructuur in plaats van op de geïmplementeerde functionaliteit. Er is een bekend citaat van Grady Booch, een persoon die zeer instrumenteel was in het populariseren van object-georiënteerde technieken: “Alle goed gestructureerde object-georiënteerde architecturen zitten vol patronen.” Het verwoordt de link tussen design patterns en software architectuur. Dat is precies waar de 4-daagse training over gaat.

De cursus behandelt de patronen die zijn opgesteld door de “Gang of Four”, de vaders van de design pattern aanpak in software engineering. Het lijkt misschien overbodig om al hun 23 patronen te bespreken, maar ze vormen een beknopte gereedschapskist waaruit de juiste mix kan worden gehaald om aan de niet-functionele eigenschappen van de software te voldoen.

De cursus illustreert de aanpak aan de hand van niet-triviale casestudy’s en praktische oefeningen. Bijvoorbeeld: het composite patroon zal worden toegepast voor uitbreidbaarheid en hergebruik, de observer voor schaalbaarheid, en de decorator voor uitbreidbaarheid en flexibiliteit. Tot slot kan de combinatie van composite en observer cash coherentie implementeren met een achtergrond.

Vereisten

Deze cursus is het natuurlijke vervolg op de training‘Object-oriented analysis & design‘ (OOAD). Er wordt verder gebouwd op de ideeën die daar werden gepresenteerd en het wordt sterk aangeraden om eerst OOAD te volgen. Een degelijke achtergrond in objectgeoriënteerd softwareontwerp via andere opleidingen of via de dagelijkse praktijk kan ook volstaan.

Voorbeeld 1

In een van de casestudies wordt een herbruikbaar component verkregen dat een aantal problemen met betrekking tot software-evolutie zal illustreren. Wanneer een softwarecomponent evolueert, is het heel belangrijk dat “oude” clientcode die tegen de component geschreven werd, ongewijzigd blijft werken. Zo’n evoluerende component wordt gezegd achterwaarts compatibel te blijven. Veel mensen hebben de indruk dat men functionaliteit moet toevoegen aan een interface als haken voor latere uitbreidingen. Dit wordt niet aanbevolen. In feite zou men de aangeboden functionaliteit moeten minimaliseren tot het strikt noodzakelijke. Clientcode compatibel houden is eenvoudig als de interface wordt uitgebreid, maar vrijwel onmogelijk als de interface wordt verkleind. Aan de andere kant wordt compatibiliteit sterk verbeterd door enkele eenvoudige syntactische regels met patronen af te dwingen. Door zulke regels toe te passen kan men de evolutie van de herbruikbare component loskoppelen van de clientcode. Dit is niet alleen belangrijk voor de levering van herbruikbare frameworks, die worden uitgerold naar een grote klantenbasis, maar ook voor de constructie van nieuwe versies van componenten in een groter, specifiek softwaresysteem. Wat men in de praktijk ziet, is dat wanneer de functionaliteit van een component wordt uitgebreid, veel andere componenten omvallen.

Voorbeeld 2

Het observer patroon kan een belangrijke rol spelen in software architectuur. Het is de object-georiënteerde variant van het “call-back” mechanisme. Net als de “call-back” keert het de afhankelijkheid om van caller naar callee. Dus, als we twee componenten hebben die handelingen aan elkaar oproepen, verwijderen we een van de resulterende afhankelijkheden. In staat zijn om de afhankelijkheden vorm te geven is geweldig, maar wederzijdse operationele aanroepen kunnen leiden tot een ander probleem: deadlock. Als de objecten die de aanroepen uitvoeren vergrendelbaar zijn, is er een kans op cyclisch wachten en kan er een deadlock optreden. Dit probleem zal in detail worden besproken in relatie tot het observer patroon. Enkele concreet gespecificeerde regels zullen worden gepresenteerd die deadlock door ontwerp kunnen voorkomen. Voor iedereen die gelijktijdige OO programma’s ontwikkelt is dit een must.