GRASP

en ["Modèles généraux d'affectation des responsabilités"[1]] est un ensemble de “Modèles, patrons” (en patterns, "fr") utilisés en orienté-objet qui nous aident pour l'assignation des responsabilités.

Dans le cadre des en ["Modèles généraux d'affectation des responsabilités"[1]], les solutions proposées sont généralement intuitives, et tiennent plus du bon sens que d'une ligne de conduite forcée.

Rappel : Un “Modèle, patron” (en pattern, "fr") doit répondre à certains aspects essentiels :

  • Un “Modèle, patron”[3] a un nom évocateur, qui représente bien l’essence même de son existence.
    Exemple : le “Modèle, patron”[3] “Instance unique” (en Singleton, "fr").
  • Un “Modèle, patron”[3] résout un problème.
    Exemple : une classe ne peut avoir qu’une et une seule instance.
  • Un “Modèle, patron”[3] fourni une solution.
    Exemple : il faut créer une méthode statique de la classe qui retourne l’instance unique ou Singleton.


Les en ["Modèles généraux d'affectation des responsabilités"[1]] sont répartis en 9 domaines (5 au départ, les 4 derniers ont été ajoutés par la suite) :
  1. “expert en Information” (en Information Expert, "fr")(plus d'information).
  2. “Créateur” (en Creator, "fr")(plus d'information).
  3. “faible couplage” (en Low Coupling, "fr")(plus d'information).
  4. “forte cohésion” (en High Cohesion, "fr")(plus d'information).
  5. “contrôleur” (en Controller, "fr")(plus d'information).
  6. “polymorphisme” (en Polymorphism, "fr")(plus d'information).
  7. “indirection” (en Indirection, "fr")(plus d'information).
  8. “fabrication pure” (en Pure Fabrication, "fr")(plus d'information).
  9. “variations protégées” (en Protected Variations, "fr")(plus d'information).

 

GRASP Expert

Problème :

A qui pouvons nous attribuer une responsabilité ?

Si les responsabilités sont mal réparties, les classes logicielles vont être difficilement maintenables , plus dure à comprendre, et avec une réutilisation des composants peu flexible.

Solution :

Affecter à une classe les responsabilités correspondants aux informations dont elle dispose.

 

GRASP Creator

Problème :

Qui peut avoir la responsabilité de créer une nouvelle instance de la classe ?

Solution :

Donner à la classe A la responsabilité de créer des instances de la classe B si :
  • Une classe A agrége des instances de la classe B
  • Une classe A contient des instances de la classe B
  • Une classe A utilise des instances d’une classe B
  • Une classe A possède les données nécessaires à l’initialisation des instance de classe B.

NB :

Une agrégation est une association entre un tout et ses parties.
Nous représenterons une agrégation par un trait terminé par un losange vide.

Une composition est une forme d’agrégation, mais pour laquelle la partie ne peut survivre sans son tout.
Nous représenterons une composition par un trait terminé par un losange plein.

 

GRASP Low Coupling

Problème :

Comment réduire les dépendances et augmenter la réutilisation ?

Solution :

Le couplage exprime la relation étroite qu’un élément (Classe, Système ou sous système) entretien avec un ou des autres éléments. Un élément faiblement couplé ne possède pas ou peu de dépendances vis a vis d’autres éléments.
Nous veillerons donc à assigner une responsabilité en gardant un niveau de couplage (de dépendance) bas.

Nous sommes souvent en présence du [trans id="grasp_lowcoupling" lang="en" fr="faible couplage"]Low Coupling[/trans] dans les situations suivantes :
  • Une classe A détient un attribut de la classe B
  • Une classe A implémente une méthode qui fait référence à la classe B
  • Une classe A est une sous-classe de la classe B
  • Une classe A utilise l'interface B.

 

GRASP High Cohesion

Problème :

Comment répartir les responsabilités et garder un niveau de complexité gérable ?

Solution :

La cohésion est le degré de spécialisation des responsabilités d’un composant, d'une classe. Nous devons veiller à augmenter la cohésion lors de l'assignation des responsabilités. Si une classe contient un nombre trop élevé de méthodes, nous devons vérifier si une collaboration avec d'autres objets ne nous permettrait pas d'avoir un petit nombre de méthodes qui ne doivent pas effectuer trop de tâches.
La multiplication des disciplines à responsabilité accroît exponentiellement le risque d’erreurs intrinsèques à cette classe.

 

GRASP Controller

Problème :

Qui détient les responsabilités de la gestion des événements système ?

Solution :

Nous devons affecter à une classe la responsabilité d’un message système.

Une classe Contrôleur doit être crée si elle répond à l’un des cas suivants :
  • La classe représente une contrôleur de façade, c’est à dire l’interface d’accès à l’ensemble d’un système.
  • La classe représente le scénario issu d’un [trans id="usecase" lang="en" fr="cas d’utilisation"]use case[/trans](?), nommé en général "Session", et qui est chargé de traiter tous les événements systèmes contenus dans un scénario de cas d’utilisation.

 

 

Document créé le 22/05/05 21:54, dernière modification le 23/03/18 10:27
Source du document imprimé : https://www.gaudry.be/analyse-grasp.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Notes

  1. a,b,c,d,e,f Modèles généraux d'affectation des responsabilités : correspond à « General Responsibility Assignment Software Patterns" en français

  2. a,b,c en : "Modèles généraux d'affectation des responsabilités" (en français, « General Responsibility Assignment Software Patterns »)

  3. a,b,c,d,e,f Modèles, patrons : correspond à "fr” en patterns

  4.  Instance unique : correspond à "fr” en Singleton

  5.  expert en Information : correspond à "fr” en Information Expert

  6.  Créateur : correspond à "fr” en Creator

  7.  faible couplage : correspond à "fr” en Low Coupling

  8.  forte cohésion : correspond à "fr” en High Cohesion

  9.  contrôleur : correspond à "fr” en Controller

  10.  polymorphisme : correspond à "fr” en Polymorphism

  11.  indirection : correspond à "fr” en Indirection

  12.  fabrication pure : correspond à "fr” en Pure Fabrication

  13.  variations protégées : correspond à "fr” en Protected Variations

 

Références

  1. livre Langue du document: uk Software Engineeging : ECIS, Assigning Responsabilities (2004)

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.