GRASP (programmation)
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
La traduction de cet article ou de cette section doit être revue ().
Le contenu est difficilement compréhensible vu les erreurs de traduction, qui sont peut-être dues à l'utilisation d'un logiciel de traduction automatique. Discutez des points à améliorer en page de discussion ou modifiez l'article.
Pour les articles homonymes, voir GRASP.
General responsibility assignment software patterns (ou principles), abrégé en GRASP, se composent de lignes directrices pour l'attribution de la responsabilité des classes et des objets en conception orientée objet.
Les différents modèles et principes utilisés par les GRASP sont : le contrôleur, le créateur, l'indirection, le spécialiste de l'information, la cohésion forte, le couplage faible, le polymorphisme, les variations protégées, et l'invention pure. Tous ces modèles répondent à certains problèmes récurrents du développement logiciel. Ils n'ont pas été conçus pour créer une nouvelle façon de travailler, mais pour mieux documenter et normaliser l'existant à l'aide de principes de programmation éprouvés en conception orientée objet.
D'après Craig Larman, « le meilleur outil de conception pour le développement de logiciels est un esprit bien éduqué sur les principes de conception. Ce n'est pas UML ou toute autre technologie »[1]. Ainsi, GRASP est surtout une boîte à outils mentale, une aide à la conception de logiciels orientés objets.
Modèles[modifier | modifier le code]
Contrôleur[modifier | modifier le code]
Le contrôleur de schéma attribue la responsabilité de traiter les événements du système à une classe non-UI qui représente l'ensemble du système ou d'un scénario cas d'utilisation. Un objet contrôleur est un non-objet de l'interface utilisateur responsable de la réception ou de la manipulation d'un système d'événements.
Le contrôleur doit être utilisé pour faire face à tous les événements du système d'un cas d'utilisation, et peut être utilisé pour plus d'un cas d'utilisation (par exemple, pour les cas d'utilisation Créer un Utilisateur et Supprimer l'Utilisateur, on peut avoir un seul UserController, au lieu de deux cas d'utilisation des contrôleurs).
Il est défini comme le premier objet, au-delà de la couche d'interface utilisateur, qui reçoit et coordonne (témoins), un système d'exploitation. Le contrôleur doit déléguer le travail qui doit être fait à d'autres objets; il coordonne ou contrôle l'activité. Il ne devrait pas faire beaucoup de travail lui-même. La portée du Contrôleur peut être considérée comme étant une partie de l'application/de la couche de service[2] (en supposant que la demande ait fait une distinction explicite entre les applications/services et la couche de la couche domaine) dans un système orienté objet avec l'ensemble de couches dans un système d'informations.
Créateur[modifier | modifier le code]
La création d'objets est l'une des activités les plus courantes dans un système orientée objet. Choisir la bonne classe qui aura la responsabilité de créer des objets est un des principes fondamentaux en orienté objet.
En général, une classe B doit être responsable de la création des instances de la classe A si l'un, ou de préférence plusieurs, des critères suivants s'appliquent :
- Les Instances de
Bagrègent des instances deA - Les Instances de
Bcontiennent des instances deA - Les Instances de
Bsont en étroite collaboration ou utilisent des instances deA - Les Instances de
Bdétiennent l'information nécessaire pour instancierA
Une forte cohésion[modifier | modifier le code]
Une forte cohésion est un modèle d'évaluation qui tente de garder les objets orientés correctement, faciles à utiliser et compréhensibles. Une forte cohésion est généralement utilisée avec un couplage faible. Une cohésion élevée signifie que les responsabilités d'un élément donné sont fortement liées et très ciblées. La séparation des programmes dans les classes et les sous-systèmes est un exemple des activités qui augmentent la cohésion des propriétés d'un système. Sinon, la faible cohésion est une situation dans laquelle un élément donné a trop d'activités sans rapport avec ses responsabilités. Les éléments avec une faible cohésion souffrent souvent d'être difficile à comprendre, difficile à réutiliser, difficile à maintenir et réfractaire au changement[3].
Indirection[modifier | modifier le code]
L'indirection prend en charge le couplage faible (et la réutilisation potentielle) entre deux éléments, en attribuant la responsabilité de la médiation entre eux à un objet intermédiaire. Un exemple de ceci est l'introduction d'un composant contrôleur de médiation entre les données (le modèle) et sa représentation (vue) dans le schéma modèle-vue-contrôleur.
Spécialiste de l'Information[modifier | modifier le code]
Spécialiste de l'Information (également expert en information) est un principe qui est utilisé pour déterminer où déléguer des responsabilités. Ces responsabilités comprennent des méthodes, des champs calculés, et ainsi de suite.
En utilisant le principe de spécialiste de l'information, une approche générale pour l'attribution de responsabilités, c'est de regarder une responsabilité donnée, de déterminer les informations nécessaires pour le remplir, puis de déterminer où cette information est conservée.
Spécialiste de l'Information va conduire à placer la responsabilité sur la classe avec le plus de renseignements nécessaires pour l'accomplir[4].
Le couplage faible[modifier | modifier le code]
On utilise le terme couplage pour désigner l'inter-dépendance d'objets entre eux. Il est recommandé de privilégier des conceptions favorisant un couplage dit faible entre des classes, des objets, des services ou des composants d'un système, afin de réduire l'impact qu'un changement sur un objet peut avoir sur les objets auxquels il est couplé. Les bénéfices recherchés sont donc :
- Peu de dépendances entre les objets pour une plus grande évolutivité et une plus grande aisance à le maintenir,
- Meilleur contrôle des potentielles régressions lors de changements sur le système
Le polymorphisme[modifier | modifier le code]
Selon le principe du polymorphisme, la responsabilité de définir la variation des comportements basés sur le type est attribuée au type pour lequel cette variation se produit. L'utilisateur du type doit utiliser des opérations de polymorphisme à la place d'effectuer des branchements explicites basés sur le type.
Variations protégées[modifier | modifier le code]
Le motif de variations protégées protège les éléments de variations sur d'autres éléments (objets, de systèmes, sous-systèmes) en enveloppant le focus de l'instabilité avec une interface et en utilisant le polymorphisme pour créer les différentes implémentations de cette interface.
Pure invention[modifier | modifier le code]
Une pure invention est une classe qui ne représente pas un concept dans le domaine du problème, spécialement composé pour réaliser un couplage faible, une forte cohésion, et la réutilisation potentielle de celle-ci dérivés (lorsqu'une solution présentée par le spécialiste de l'information de modèle qui ne fonctionne pas). Ce type de classe est appelé un service dans le domain-driven design.
Voir aussi[modifier | modifier le code]
- Anémique modèle de domaine
- Modèle de conception (de l'informatique)
- Les Modèles de conception (livre)
- SOLID (object-oriented design)
Références[modifier | modifier le code]
- Larman 2005, p. 272.
- « Application Layer like business facade? », Yahoo! Groups (domaindrivendesign), sur Yahoo! Groups (domaindrivendesign) (consulté le )
- Larman 2005, p. 314–315.
- Larman 2005 chapter 17, section 11.
Bibliographie[modifier | modifier le code]
- (en) Craig Larman, Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development, New Jersey, Prentice Hall, , 3e éd. (1re éd. 2004), 703 p. (ISBN 0-13-148906-2, lire en ligne)
