Patrons de conception Flashcards
Dessinez la structure du patron de conception structurel Composite
https://refactoring.guru/images/patterns/diagrams/composite/structure.png
Définissez l’intention du patron structurel Composite
Traiter les objets individuels et les objets composés récursivement et uniformément à l’aide d’une structure en arbre
Identifiez les raisons de l’application du patron structurel Composite (2)
- Besoin d’une structure récursive (arbre)
- Besoin d’un traitement uniforme d’éléments composés et simple (Leaf / Composite)
Identifiez les conséquences du patron structurel Composite (+2, -1) (RefacGuru -1)
+ Uniformité : Traitement des composants de manière uniforme (Leaf / Composite)
+ Extensibilité : Nouvelles sous-classes de Component fonctionnent partout où les anciennes fonctionnent
- Coût : Parfois implique un grand nombre d’objets
Refactoring Guru
- Difficulté de compréhension : Lorsque les classes dérivées sont trop différentes, l’interface Component est surgénéralisé
Identifiez les critères d’implantation du patron structurel Composite (4)
- Component connait son parent?
- Interface uniforme entre Leaf et Composite?
- Responsable de la destruction des enfants ?
- Allouer aucun espace de stockage pour Component (Classe de base)
Dessinez la structure du patron de conception structurel Proxy
https://refactoring.guru/images/patterns/diagrams/proxy/structure-indexed.png
Définissez l’intention du patron structurel Proxy
Fournir une doublure pour un autre objet afin d’en contrôler son accès, ce qui permet de faire des requêtes avant ou après la requête de l’objet initial
Identifiez les raisons de l’application du patron structurel Proxy (1) (RefacGuru 3)
- Besoin d’une référence plus versatile qu’un pointeur
Refactoring Guru
- Initialisation paresseuse du service
- Exécution d’un service externe
- Besoin d’une cache des actions réalisées avec le service
Identifiez les conséquences du patron structurel Proxy (Refactoring Guru +3, -1)
+ Abstraction du contrôle d’un service
+ Contrôle de la durée de vie d’un objet
+ Fonctionne même lorsque le service n’est pas disponible
- Délai de la réponse du service
Dessinez la structure du patron de conception structurel Decorator
https://refactoring.guru/images/patterns/diagrams/decorator/structure-indexed.png
Définissez l’intention du patron structurel Decorator
Attacher dynamiquement des responsabilités additionnelles à un objet
Identifiez les raisons de l’application du patron structurel Decorator (2)
- Désir d’ajouter/enlever des responsabilités dynamiquement à des objets individuels
- Trop difficile ou impossible d’utiliser l’héritage pour étendre les responsabilités d’un objet
Identifiez les conséquences du patron structurel Decorator (+2, -2) (Refac Guru -2)
+ Flexibilité : Permet de choisir les responsabilités «à la carte» dynamiquement pour un objet
+ Évite les classes de base complexe : Division de ses responsabilités par les décorateurs
- Difficile d’identifier les objets : Composition de décorateurs implique que l’objet change ses responsabilités
- Coût : Parfois implique un grand nombre d’objets
Refactoring Guru
- Difficile d’implémenter des décorateurs sans que l’ordre est une importance
- Difficile d’enlever un décorateur précis d’une composition de décorateur
Identifiez les critères d’implantation du patron structurel Decorator (4)
- Uniformité et conformité de l’interface
- Classe abstraite de Decorator facultative
- Garder les classes de Component légères
- Changer l’objet avec des enrobages plutôt qu’à l’interne
Dessinez la structure du patron de conception structurel Facade
https://refactoring.guru/images/patterns/diagrams/facade/structure-indexed.png
Définissez l’intention du patron structurel Facade
Fournir une interface simplifié d’un groupe d’interfaces provenant d’un sous-système
Identifiez les raisons de l’application du patron structurel Facade (3)
- Fournir une interface simple à un sous-système complexe
- Éviter un couplage fort entre les clients et les classes abstraites
- Implanter en plusieurs couches
Identifiez les conséquences du patron structurel Facade (+3) (Refac Guru -1)
+ Vue simplifiée d’un sous-système qui est suffisante pour la plupart des clients
+ Modularité : Découple les clients et le sous-système
+ Simplification des communications entre sous-système
Refactoring Guru
- Danger d’un God Object (Objet qui fait tout)
Identifiez les critères d’implantation du patron structurel Facade (4)
- Classe abstraite où les classes dérivées définissent des interfaces différentes ?
- Classes publiques ou privées ?
Dessinez la structure du patron de conception créationnel Singleton
https://refactoring.guru/images/patterns/diagrams/singleton/structure.png
Définissez l’intention du patron créationnel Singleton
- Avoir une seule instance d’une classe
- Fournir un point d’accès global à cette instance
Identifiez les raisons de l’application du patron créationnel Singleton (3) (Refac Guru 1)
- Vouloir avoir une instance unique
- Vouloir accéder à l’instance sans modification de code
Refactoring Guru
- Besoin d’un contrôle stricte sur des variables globales
Identifiez les conséquences du patron créationnel Singleton (+3, -1) (Refac Guru +2, -3)
+ Réduction de la pollution du namespace global
+ Contrôle le nombre d’instantiation d’une classe (Peut se limiter à plus qu’une)
+ Permet la généralisation par classes dérivées (Comparaison à une classe entièrement statique)
- Implantation peut être moins efficace qu’une variable globale
Refactoring Guru
+ Point d’accès global
+ Initialisation paresseuse
- Difficile à gérer en multithreading (accès à une variable partagée)
- Difficile à tester
- Danger d’un God Object (Objet qui fait tout)
Identifiez les critères d’implantation du patron créationnel Singleton (2)
- Opération getInstance() statique
- Enregistrement de l’instance du Singleton
Dessinez la structure du patron de conception créationnel Abstract Factory
https://refactoring.guru/images/patterns/diagrams/abstract-factory/structure-indexed.png
Définissez l’intention du patron créationnel Abstract Factory
Procurer une interface permettant de créer une famille
d’objets connexes ou dépendants sans spécifier leurs
classes concrètes
Identifiez les raisons de l’application du patron créationnel Abstract Factory (4)
- Nécessité de l’indépendance de la création, composition et représentation des objets
- Révéler seulement l’interface et non l’implémentation d’une librairie de classes
- Conception d’un ensemble issue d’une famille d’objets connexes
- Système doit fonctionner avec une famille particulière d’objets connexes
Identifiez les conséquences du patron créationnel Abstract Factory (+3, -1)
+ Isolation des classes concrètes
+ Facilite les changements de familles d’objets
+ Encourage la création de familles d’objets connexes
- Complexifie le support de nouveaux types d’objet
Identifiez les critères d’implantation du patron créationnel Abstract Factory (3)
- Singleton ?
- Patron Factory Method pour la création d’un produit
- Définition d’usines extensibles