GRASP

Un article de MonWiki.

La conception des objets logiciels peut être pensée en terme de responsabilités, de rôles, et de collaborations. Ces notions font partie d'une approche plus vaste nommée conception pilotée par les responsabilités ou CPR.

Note : dans la CPR, les objets logiciels ont des responsabilités. Ces responsabilités sont de deux types : savoir et faire.

GRASP signifie General Responsibility Assignment Software Patterns. C'est une aide pédagogique pour concevoir des objets avec des responsabilités.

[modifier]

Créateur

Q : Qui crée un A ?

R : Affecter à la classe B la responsabilité de créer une instance de la classe A si une ou plusieurs des conditions suivantes est vraie (the more, the better) :

contient ou agrège des objets A,
enregistre des objets A,
utilise étroitement des objets A,
possède les données d'initialisation des objets A.

[modifier]

Expert en Information

Q : Quel est le principe général d'affectation des responsabilités aux objets ?

R : Affecter une responsabilité à l'expert en information, c'est à dire à la classe qui possède les informations nécessaires pour s'acquitter de la responsabilité.

[modifier]

Faible Couplage

Q : Comment minimiser les dépendances, réduire l'impact des changements et augmenter la réutilisation ?

R : Affecter une responsabilité de sorte que le couplage demeure faible (éviter tout couplage inutile). Appliquer ce principe pour évaluer les solutions possibles.

[modifier]

Contrôleur

Q : Quel est le premier objet au-delà de l'IHM (la couche présentation) qui reçoit et coordonne ("contrôle") une opération système ?

R : Affecter la responsabilité à une classe qui correspond à l'un des cas suivants :

La classe représente le "système" global, un "objet racine",
La classe représente un scénario de cas d'utilisation dans lequel l'événement système se produit, souvent nommé Gestionnaire<NomDuCasDUtilisation>, Coordinateur<NomDuCasDUtilisation> ou Session<NomDuCasDUtilisation> (contrôleur de cas d'utilisation ou contrôleur de session)
- Utiliser la même classe contrôleur pour tous les événements système appartenant au même scénario.
- Pour simplifier, une session est une instance de conversation avec un acteur. La durée des sessions peut être quelconque, mais celles-ci sont souvent organisées autour de cas d'utilisation (session de cas d'utilisation).

Corollaire : notez que les classes fenêtre, vue et document ne figurent pas dans cette liste. De telles classes ne doivent pas effectuer les tâches associées aux événements système. Elles reçoivent généralement ces événements et les délèguent à un contrôleur.

[modifier]