Surtout pour le début d'un nouvel ensemble pour le cours "Architecture et Design Patterns", je continue ma série de publications sur les motifs GRASP.
introduction
Décrits dans le livre de Craig Larman "Applying UML and patterns, 3rd edition", les patterns GRASP sont des généralisations des patterns GoF, ainsi qu'une conséquence directe des principes de la POO. Ils complètent l'échelon manquant dans l'échelle logique qui vous permet de dériver des modèles GoF à partir des principes de la POO. Les modèles GRASP ne sont pas des modèles de conception (comme ceux du GoF), mais les principes fondamentaux de la répartition des responsabilités entre les classes. Comme le montre la pratique, ils ne sont pas très populaires, mais l'analyse des classes conçues à l'aide de l'ensemble complet des modèles GRASP est une condition préalable à l'écriture de bon code.
La liste complète des modèles GRASP se compose de 9 éléments:
- Expert en information
- Créateur
- Manette
- Couplage bas
- Cohésion élevée
- Polymorphisme
La dernière fois, nous avons discuté du modèle de contrôleur . Aujourd'hui, je propose d'examiner les modèles restants de la liste.
Polymorphisme
Différents comportements doivent être gérés en fonction du type, permettant le remplacement des pièces du système.
Il est proposé de répartir les responsabilités entre les classes en utilisant des opérations polymorphes, laissant chaque système externe avec sa propre interface. A titre d'exemple, on peut citer des bibliothèques standardisées, ou une configuration d'application en connectant certains plugins pour différents clients selon leurs besoins.
La présence d'une construction de commutateur dans le code est une violation de ce principe, les commutateurs et sont sujets à refactoring.
La surutilisation du polymorphisme conduit à une sur-complication du code et est généralement déconseillée.
Fabrication pure
Un faible couplage et une cohésion élevée doivent être garantis. Pour cela, il peut être nécessaire de synthétiser une essence artificielle. Le modèle Pure Fabrication suggère que vous ne devriez pas hésiter à le faire. À titre d'exemple, considérons la façade de la base de données. Il s'agit d'un objet purement artificiel qui n'a pas d'analogues dans le domaine. En général, toute façade est Pure Fabrication (sauf s'il s'agit bien sûr d'une façade architecturale dans l'application correspondante).
Indirection
Il est nécessaire de répartir les responsabilités entre les objets, en évitant la liaison directe. Pour ce faire, vous pouvez attribuer des responsabilités de communication entre composants ou services à un objet intermédiaire.
Traduit en russe, le modèle implique ce qui suit: tout objet du code doit être appelé via son interface (le même objet intermédiaire).
L'indirection est le modèle le plus clé répertorié dans cet article. Tout d'abord, c'est très simple en termes de sécurité. Deuxièmement, cela donne au code beaucoup de flexibilité sans être des optimisations prématurées en raison du premier point. Si toutes les classes s'appellent via des interfaces, cela conduit à la possibilité de "déchirer" n'importe quel élément du système et de le réutiliser ailleurs. De plus, l'utilisation d'Indirection vous permet d'ajouter presque n'importe quel modèle d'un gang de quatre sans trop de pression ou de refactorisation des classes.
Variations protégées
Il est nécessaire de concevoir le système de manière à ce que les modifications de certains de ses éléments n'affectent pas les autres. Comme solution, il est proposé d'identifier les points de changements ou d'instabilité possibles et d'attribuer les responsabilités de manière à assurer le fonctionnement stable du système.
En fait, ce n'est pas un modèle, mais un objectif atteint en suivant le reste des modèles.
Production
Les modèles GRASP se composent de 8 modèles:
- Expert en information - nous traitons les informations là où elles sont contenues.
- Créateur - nous créons des objets là où ils sont nécessaires.
- Contrôleur - nous déplaçons la logique multithreading dans une classe ou un composant séparé.
- Couplage faible 5) Cohésion élevée - nous concevons des classes avec une logique métier homogène et un nombre minimum de connexions entre elles.
- Polymorphisme - diverses options pour le comportement du système, si nécessaire, sont formalisées sous la forme d'appels polymorphes.
- Pure Fabrication — , , Low Coupling High Cohesion.
- Indirection — .
- Protected Variations — , .
: