GRASP

Ontwerp

LET OP: Dit artikel is nog in bewerking!

Misschien het moeilijkste onderdeel van het maken van een goed ontwerp in objectgeoriënteerd ontwerpen is het toekennen van verantwoordelijkheden van de applicatie aan de klassen. Met andere woorden: Het bepalen welke klasse voor de implementatie van een bepaalde use-case verantwoordelijk is. Het proces waarin je dit bepaalt is niet eenduidig en wordt sterk beïnvloed door je ervaring in het maken van ontwerpen. Een ervaren softwareontwikkelaar neemt dit soort beslissingen dan soms ook "automatisch" of "op gevoel", wat eigenlijk betekent dat hij of zij het in het verleden een keer verkeerd gedaan heeft en dit een hoop ellende opgeleverd heeft. En het "gevoel" dat hij of zij nu heeft wellicht sterk gecorreleerd is aan de "pijn" die gevoeld werd toen ontdekt werd dat een eerder genomen beslissing verkeerd bleek. Volgens mij is dit de definitie van "ervaring". Het idee van de General Responsibility Assignment Software Patterns (GRASP)1, opgesteld door expert softwareontwikkelaars, is om een set van vragen en antwoorden te leveren zodat minder ervaren softwareontwikkelaars deze kunnen doorlopen en derhalve kunnen berusten op de ervaring van de experts. In tegenstelling tot principes, zijn patronen meestal niet optioneel. Een patroon is een beproefde oplossing voor het genoemde probleem en is wellicht de enige juiste oplossing.

Controller

todo

Creator

Het Creator Pattern beantwoordt de vraag "Welke klasse is verantwoordelijk voor het aanmaken van instanties van een bepaalde klasse?". In andere woorden, voor klasse X, welke andere klasse in het klassendiagram is verantwoordelijk voor het aanroepen van de constructor van X? Je zou deze vraag onbeantwoord kunnen laten en derhalve alle andere klassen in je klassendiagram deze mogelijkheid geven, echter dit levert verstrengeling op omdat je plots potentieel heel veel afhankelijkheden gemaakt hebt. Het is daarom vaak beter om 1 specifieke klasse de verantwoordelijkheid toe te kennen. Het antwoord op deze vraag is het doorlopen van de volgende vragenlijst. De meest geschikte klasse is die op zo veel mogelijk van onderstaande vragen "ja" antwoordt.

Is er een klasse die:

  • X-en aggregeert of persisteert?
  • X of meerdere X-en bevat?
  • de methodes van X aanroept met zichzelf als parameter?
  • kan voorzien in de parameters van de constructor van X?

Indirection

todo

Information Expert

Het Information Expert Pattern beantwoordt de vraag "Welke klasse is het meest geschikt om een bepaalde verantwoordelijkheid op zich te nemen?". In andere woorden, per use-case, hoe bepaal ik welke klasse de bijbehorende operatie moet gaan krijgen?

Het antwoord op deze vraag is om de klasse te kiezen die de meeste informatie (attributen) heeft om deze use-case uit te voeren, en dus de minste "hulp" nodig heeft van andere klassen. Voor deze use-case is deze klasse dan de informatie-expert omdat het "de meeste kennis heeft van deze use-case". Mocht een dergelijke klasse niet bestaan in het domein, overweeg dan een pure fabrication (zie onder).

High Cohesion

todo

Low Coupling

todo

Polymorphism

todo

Protected Variations

todo

Pure Fabrication

De Pure Fabrication is een oplossing voor het probleem waarin de operatie passend bij een bepaalde use-case in geen enkele van de domeinklassen goed past. Het beantwoordt de vraag "Wat te doen als geen enkele domeinklasse de information expert is voor een bepaalde use-case?" In een dergelijk geval is het nodig om een klasse te verzinnen om deze verantwoordelijkheid op zich te namen. Het verzinnen van een klasse met een eenduidig doel is in dit geval beter dan deze verantwoordelijkheid op een onduidelijke plaats onder te brengen. Een voorbeeld hiervan is te vinden in het hoofdstuk Van use-cases naar ontwerp in het artikel over het klassendiagram, waarin ik de use-case "artikelenlijst bekijken" niet goed kan plaatsen en pure fabrication toepas om de klasse ArtikelVerzameling te maken. Deze klasse is dan tevens ook de information expert voor deze use-case.

Conclusie

De set van vragen en antwoorden in GRASP adresseren veel voorkomende ontwerpproblemen en de daarbij horende patronen om een oplossing te verzinnen. Eerder waren er ontwerppatronen opgesteld door de Gang of Four, welke uiteraard nog steeds relevant zijn, maar misschien een beetje bejaard en moeilijk toepasbaar. GRASP levert een wat gemakkelijker toepasbare set en herkenbare vragen.


  1. Larman, Craig (2005) [2004]. Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). New Jersey: Prentice Hall. ISBN 0-13-148906-2. ↩︎