Design Pattern – Corrigé TD n°2
Ce corrigé résume les concepts abordés lors du TP. Il est fortement recommandé de l'utiliser en complément des travaux pratiques pour comparer votre code avec celui proposé. Les explications restent succinctes et ne remplacent pas celles données en cours ou en TP.
Le Pattern Factory
À la fin de cet exercice, vous devriez obtenir le diagramme de classe suivant : une ProgramFactory agissant comme usine de création des objets Program. Le client n’a aucune connaissance des classes concrètes de Program ; il interagit uniquement avec la Factory et l’interface ProgramInterface.
Le Pattern Abstract Factory
Le diagramme de classe précédent illustre une implémentation du pattern Abstract Factory, où deux usines (LinuxFactory et WindowsFactory) produisent des ensembles d’objets (FileNameParser et CountFolder) adaptés à leur système d’exploitation (Windows ou Linux).
Une FactoryFactory (factory d’usines) est également présente. Bien qu’elle ne fasse pas partie du pattern Abstract Factory, elle permet de rendre le client (Main) totalement indépendant des implémentations des interfaces. Le client n’interagit qu’avec FactoryFactory et les trois interfaces.
FAQ
1. Qu’est-ce qu’un Design Pattern Factory ?
Un Design Pattern Factory est un modèle de conception qui centralise la création d’objets, masquant ainsi les détails de leur implémentation au client. Cela permet de découpler le code client de la logique de création.
2. À quoi sert le pattern Abstract Factory ?
Le pattern Abstract Factory permet de créer des familles d’objets compatibles entre eux sans spécifier leurs classes concrètes. Il est utile pour garantir une cohérence entre les objets produits par différentes usines.
3. Quelle est la différence entre Factory et Abstract Factory ?
Factory crée des objets individuels, tandis que Abstract Factory crée des familles d’objets (plusieurs types d’objets liés). Le second est plus flexible pour étendre des produits sans modifier le code client.