GRASP

GRASP is een Engels acroniem dat staat voor Generalized Responsibility Assignment Software Patterns/Principles. Het bestaat uit 9 richtlijnen die kunnen worden gebruikt om in objectgeoriënteerde systemen verantwoordelijkheden toe te kennen aan klassen of objecten. Elke richtlijn behandelt een combinatie van een veelvoorkomend probleem en een algemeen toepasbare oplossing voor dat probleem met betrekking tot het ontwerp van softwaresystemen.

Voor de laatste letter van acroniem GRASP wordt zowel Patterns (patronen) als Principles (richtlijnen) gebruikt. De benaming 'richtlijn' moet benadrukken dat het hier gaat om een hoger abstractieniveau dan een ontwerppatroon zoals beschreven door de "Gang of Four (GOF)". Bovendien geeft de term 'richtlijn' aan dat het om een advies gaat. Tijdens het ontwerpproces zal namelijk soms een afweging gemaakt moeten worden tussen meerdere richtlijnen. De GOF Patterns zijn ontwerpregels. Het gaat hier niet om een vrijblijvende keuze. De praktijk heeft uitgewezen dat het zo moet. Maar, uiteraard is uiteindelijk het mechanisme belangrijker dan de benaming.

De 9 richtlijnen zijn:

1. Creator
2. Information Expert
3. Low Coupling
4. High Cohesion
5. Controller
6. Polymorphism
7. Pure Fabrication
8. Indirection
9. Protected Variations

Creator

Probleem: Wie is er verantwoordelijk voor de creatie van een instantie van klasse A?
Oplossing: Geef de verantwoordelijkheid om een instantie van klasse A te maken aan die klasse B die aan het meeste van de volgende omschrijvingen voldoet:

1. B bevat A
2. B houdt de toestand van A bij
3. B gebruikt A veelvuldig
4. B heeft de data die benodigd is voor initialisatie van A

Information Expert

Probleem: Aan welke klasse kennen we een bepaalde verantwoordelijkheid toe?
Oplossing: Ken de verantwoordelijkheid toe aan de klasse die de (meeste) informatie heeft om de verantwoordelijkheid te dragen.

Low Coupling

Probleem: Hoe reduceert men de impact van wijzigingen?
Oplossing: Ken verantwoordelijkheden dusdanig toe dat de klassen zo min mogelijk afhankelijkheden hebben naar andere klassen.

High Cohesion

Probleem: Hoe houdt men klassen begrijpelijk en onderhoudbaar?
Oplossing: Ken verantwoordelijkheden dusdanig toe dat er een grote overeenkomst (oftewel samenhang) is tussen de verschillende verantwoordelijkheden van een klasse.

Controller

Probleem: Welk object onder de User Interface laag regelt de afhandeling van een systeem operatie?
Oplossing: Deze verantwoordelijkheid moet worden toegekend aan een van de volgende twee objecten:

1. Een facade controller. Dit is een vertegenwoordiger van een totaal (sub)systeem.
2. Een use case controller (ook wel session controller). Dit is de vertegenwoordiger van een use case scenario waarin de systeemoperatie voorkomt.

Polymorphism

Probleem: Wie is er verantwoordelijk voor de realisatie van type afhankelijk gedrag?
Oplossing: Ken deze verantwoordelijkheid toe aan de types waarvoor alternatief gedrag optreedt (met behulp van polymorfisme).

Pure Fabrication

Probleem: Aan wie moeten verantwoordelijkheden worden toegekend als Information Expert geen uitkomst biedt zonder schending van de Low Coupling en High Cohesion richtlijnen?
Oplossing: Ken de verantwoordelijkheden toe aan een klasse welke speciaal voor dit doel (en anderen, zoals hergebruik) in het leven wordt geroepen.

Indirection

Probleem: Hoe kunnen klassen ontkoppeld worden?
Oplossing: Ken verantwoordelijkheden toe aan een tussenliggende klasse die de interactie tussen de klassen overneemt.

Protected Variations

Probleem: Hoe voorkomt men grote impact ten gevolge van klassen die aan verandering onderhevig zijn (bijvoorbeeld vanwege uitbreiding in gedragsvarianten)?
Oplossing: Definieer een interface om gedrag waar veel variatie verwacht wordt zodat de interface gelijk blijft wanneer variaties op het gedrag geïmplementeerd worden.