1.

Créational Design Patterns

a. Singleton
But : Assurer qu'une classe n'ait qu'une seule instance et fournir un point d'accès
global à cette instance.
Cas d'utilisation : Gestion de ressources partagées comme les connexions à la base
de données, file d'attente, gestionnaires de logs.
Avantages : Contrôle de l'accès global à une instance unique.
Inconvénients : Difficulté de test unitaire, couplage fort, pas flexible pour de futures
évolutions.

b. Factory Method
But : Définir une interface pour créer un objet, mais laisser les sous-classes
décider de la classe à instancier.
Cas d'utilisation : Lorsque la création d'objets nécessite une logique complexe ou
dépend de conditions spécifiques.
Avantages : Encapsulation de la logique de création, permet des sous-classes
flexibles.
Inconvénients : Complexifie parfois la hiérarchie des classes.

c. Abstract Factory
But : Fournir une interface pour créer des familles d'objets liés ou dépendants sans
spécifier leurs classes concrètes.
Cas d'utilisation : Interfaces graphiques (GUI) où différents éléments doivent être
créés en fonction du système d'exploitation (Windows, Mac).
Avantages : Cohérence dans la création d'objets liés, haut niveau d'abstraction.
Inconvénients : Complexité accrue lorsqu'il y a trop d'interfaces et de classes.
d. Builder
But : Séparer la construction d'un objet complexe de sa représentation afin que le
même processus de construction puisse créer différentes représentations.
Cas d'utilisation : Création d'objets complexes avec de nombreuses options (ex. :
construction d'une maison ou d'un rapport complexe).
Avantages : Facilite la construction d'objets complexes étape par étape.
Inconvénients : Nécessite plus de code et plus de classes.

e. Prototype
But : Créer de nouveaux objets en copiant un objet prototype existant.
Cas d'utilisation : Lorsque la création d'objets est coûteuse (copie plutôt
qu'instanciation).
Avantages : Réduit le coût de création d'objets complexes.
Inconvénients : Complexité liée à la gestion du clonage profond.
 2. Structural Design Patterns
Les patterns structurels traitent de la manière dont les objets et les classes sont
composés pour former des structures plus larges et plus flexibles.

a. Adapter
But : Permettre à des classes ayant des interfaces incompatibles de travailler
ensemble en convertissant l'interface d'une classe en une autre interface attendue.
Cas d'utilisation : Intégrer une nouvelle bibliothèque ou API sans modifier l'ancienne
structure du projet.
Avantages : Facilite la réutilisation de code existant avec des interfaces
incompatibles.
Inconvénients : Ajoute un niveau d'indirection, complexifiant le code.

b. Bridge
But : Découpler une abstraction de son implémentation afin qu'elles puissent
évoluer indépendamment.
Cas d'utilisation : Interfaces graphiques où différentes représentations d'une même
abstraction sont nécessaires (e.g., impression de documents).
Avantages : Réduit le couplage entre abstraction et implémentation.
Inconvénients : Peut ajouter de la complexité supplémentaire.

c. Composite
But : Composer des objets en structures arborescentes pour représenter des
hiérarchies partie-tout. Permet aux clients de traiter les objets individuels et les
compositions de manière uniforme.
Cas d'utilisation : Systèmes de fichiers, GUI, structures arborescentes.
Avantages : Simplifie le traitement uniforme des objets et des groupes d'objets.
Inconvénients : Complexité accrue pour gérer des objets simples et composites.
d. Decorator
But : Attacher dynamiquement des responsabilités supplémentaires à un objet.
Fournir une alternative flexible à la sous-classe.
Cas d'utilisation : Ajout de fonctionnalités à des objets de manière dynamique,
comme les fenêtres avec des barres de défilement ou des bordures.
Avantages : Evite l'explosion des sous-classes, flexible.
Inconvénients : Peut générer beaucoup de petits objets complexes à comprendre.

e. Facade
But : Fournir une interface simplifiée à un ensemble complexe de classes ou sous-
systèmes.
Cas d'utilisation : Interfaces d'API simplifiées pour des systèmes complexes (e.g.,
interface d'un sous-système d'une bibliothèque).
Avantages : Masque la complexité d'un sous-système.
Inconvénients : Peut cacher des fonctionnalités puissantes ou complexes.

f. Flyweight
But : Utiliser le partage pour prendre en charge efficacement un grand nombre
d'objets fins à granularité fine.
Cas d'utilisation : Systèmes de gestion de caractères, gestion d'objets en mémoire
(comme dans les jeux vidéo).
Avantages : Réduction de la consommation mémoire en partageant des objets.
Inconvénients : Complexité supplémentaire liée à la gestion des objets partagés.

g. Proxy
But : Fournir un substitut ou un intermédiaire pour contrôler l'accès à un objet.
Cas d'utilisation : Contrôle d'accès, gestion des objets à distance (e.g., RPC).
Avantages : Ajoute des contrôles avant d'accéder à l'objet réel (sécurité, paresseux,
etc.).
Inconvénients : Ajoute un niveau d'indirection, augmentant la complexité.
 3. Behavioral Design Patterns
Ces patterns se concentrent sur la communication entre les objets et la manière
dont ils interagissent entre eux pour accomplir des actions spécifiques.

a. Chain of Responsibility
But : Eviter de coupler l'expéditeur d'une requête à son destinataire en donnant à
plusieurs objets la possibilité de traiter la requête.
Cas d'utilisation : Systèmes de traitement de demandes, par exemple dans les
systèmes de support technique ou de validation.
Avantages : Rend le code plus flexible et extensible.
Inconvénients : Le traitement peut ne pas se terminer si aucun objet ne prend en
charge la demande.

b. Command
But : Encapsuler une requête en tant qu'objet, permettant ainsi de paramétrer des
clients avec différentes requêtes, files d'attente ou journaux.
Cas d'utilisation : Interfaces utilisateurs où les actions sont encapsulées en
commandes (ex. : annuler/rétablir).
Avantages : Permet d'ajouter des commandes sans changer le code existant.
Inconvénients : Génère beaucoup de classes supplémentaires.

c. Interpreter
But : Fournir une façon de définir une grammaire pour un langage et un
interpréteur pour ce langage.
Cas d'utilisation : Interpréteurs de langages de scripts ou calculatrices simples.
Avantages : Facilité d'implémentation des langages spécifiques.
Inconvénients : Complexité si le langage est trop compliqué.
d. Iterator
But : Fournir un moyen de parcourir une collection d'objets sans exposer sa
représentation interne.
Cas d'utilisation : Traverser des structures de données complexes comme des
arbres ou des listes.
Avantages : Simplifie l'accès à des collections sans exposer leur structure interne.
Inconvénients : Peut ajouter des objets et un overhead.

e. Mediator
But : Définir un objet qui encapsule la manière dont un ensemble d'objets interagit.
Cas d'utilisation : Systèmes où plusieurs objets interagissent de manière complexe
(e.g., systèmes de chat, simulateurs d'événements).
Avantages : Réduit le couplage entre les objets.
Inconvénients : Peut centraliser trop de responsabilités.

f. Memento
But : Sauvegarder et restaurer l'état interne d'un objet sans violer son
encapsulation.
Cas d'utilisation : Systèmes de gestion de versions, undo/redo dans les éditeurs de
texte.
Avantages : Permet de restaurer l'état précédent sans violer l'encapsulation.
Inconvénients : Peut consommer beaucoup de mémoire si l'état est volumineux.

g. Observer
But : Définir une relation de dépendance un-à-plusieurs entre objets de sorte que
lorsqu’un objet change d’état, tous ses dépendants en sont informés.
Cas d'utilisation : Systèmes réactifs, abonnements à des événements.
Avantages : Permet des mises à jour automatiques.
Inconvénients : Peut être difficile à gérer si le nombre d'abonnés est important.
h. State
But : Permettre à un objet de changer son comportement lorsque son état interne
change.
Cas d'utilisation : Machines à états, systèmes de jeu avec changements de
comportement en fonction des niveaux.
Avantages : Simplifie les transitions d'état.
Inconvénients : Peut générer beaucoup de classes pour représenter les états.

i. Strategy
But : Définir une famille d'algorithmes, encapsuler chaque algorithme, et les rendre
interchangeables.
Cas d'utilisation : Tri d'objets avec différents critères ou différentes méthodes de
calcul.
Avantages : Facilite le changement d'algorithme sans modifier le code principal.
Inconvénients : Ajoute de la complexité avec de nombreuses stratégies.

j. Template Method
But : Définir le squelette d’un algorithme dans une méthode, tout en laissant des
étapes spécifiques aux sous-classes.
Cas d'utilisation : Algorithmes où les étapes sont fixes, mais certaines parties
doivent être personnalisées (ex : traitement de fichiers).
Avantages : Réutilisation du code et flexibilité pour modifier certaines étapes.
Inconvénients : Conduit à un couplage fort entre la classe abstraite et ses sous-
classes.

k. Visitor
But : Représenter une opération à effectuer sur les éléments d’une structure
d'objets, permettant de définir de nouvelles opérations sans modifier les classes
des éléments sur lesquels elles opèrent.
Cas d'utilisation : Parcours d'arborescences ou d'objets composites avec des
opérations distinctes (ex : analyses syntaxiques).
Avantages : Facilite l'ajout de nouvelles opérations sans modifier la structure des
objets.
Inconvénients : Difficile à maintenir lorsque la structure des éléments est modifiée.