Un design pattern ou pattern de conception consiste en un schéma à objets qui forme une solution à un problème connu et fréquent. Le schéma à objets est constitué par un ensemble d'objets décrits par des classes et des relations liant les objets.
Les patterns répondent à des problèmes de conception de logiciels dans le cadre de la programmation par objets. Ce sont des solutions connues et éprouvées dont la conception provient de l'expérience de programmeurs. Il n'y a pas d'aspect théorique dans les patterns, notamment pas de formalisation (à la différence des algorithmes).
A.Introduction aux patterns de construction
A.1. Présentation
Les patterns de construction ont pour vocation d'abstraire les mécanismes de création d'objets. Un Système utilisant ces patterns devient indépendant de la façon dont les objets sont crées et, en particulier, des mécanismes d'instanciation des classes concrètes.
Ces patterns encapsulent l'utilisation des classes concrètes et favorisent ainsi l'utilisation des interface dans les relations entre objets, augmentant les capacités d'abstraction dans la conception globale du système.
A.2. Problématique
Dans la plupart des langages à objets, la création d'objets se fait grâce au mécanisme d'instanciation se fait par appel de l'opérateur new paramétré par classe.
Dans cette optique il est difficile de paramétrer le mécanisme de création d'objets, la classe transmise en paramètre à l’opérateur new ne pouvant être substitué par une variable. L'utilisation d'instruction conditionnelles dans le code du client est souvent pratiqué avec l’inconvénient que chaque changement dans la hiérarchie des classes à instancier demande des modifications dans le code des clients.
1.Le Pattern Abstract Factory
Description:
Le but du pattern Abstract Factory est la création d'objets regroupés en famille sans devoir connaître les classes concrètes destinées à la création de ces objets.
Exemple:
Lorsqu'un Client à la possibilité d'instancier des produits (a,b,c,..) directement via des sous-classes concrètes d'un ensemble (architecture) composée de famille(F1a, F1b, F2a,...) de produit, si, par la suite de nouvelles familles (F3a,..) de produit doivent être prises en compte, les modifications à apporter à l'objet Client peuvent être assez conséquentes.
But:
Rendre la classe Client indépendante de l'ensemble (architecture) des familles(F1a, F1b, F2a,...) et des produits.
Solution:
- On introduit une Interface FabriqueAbstraite contenant les signatures des méthodes pour définir chaque produit, dont le type de retour de ces méthodes est constitué par les types des classes abstraites de produit.
-Une sous classe d'implantation FabriqueAbstraite est introduit pour chaque famille de produit FabriqueConcretFamilleX ,FabriqueConcretFamilleZ,.. Une telle sous-classe implante les opérations de de création du produit appropriée pour la famille à laquelle elle est associée.
-L'objet Client prend alors pour paramètre une instance répondant à l'interface FabriqueAbstraite c'est à dire une instance de FabriqueConcretFamilleX ou FabriqueConcretFamilleZ,.. (car il y a un mécanisme d'héritage)
Avantages:
- L'objet Client n'a pas besoin de connaître les sous-classes concrètes et reste ainsi indépendant des familles de produit.
Diagramme de classes:
Participants:
- FabriqueAbstraite est une interface spécifiant les signatures des méthodes créant les différents types de produit.
- FabriqueConcretFamille1, FabriqueConcretFamille2 sont les classes concrètes implantant les méthodes créant les produits pour chaque famille de produit. Connaissant la famille et le produit, elles sont capables de créer une instance du produit pour cette famille.
- TypeAAbstrait, TypeBAbstrait sont les classes abstraites des produits indépendamment de leur famille. Les familles sont introduites dans leurs sous-classes concrètes.
- Client
Collaborations:
La classe Client utilise une instance de l'une des fabriques concrètes pour créer ses produits au travers de l'interface FabriqueAbstraite.
Domaines d'utilisation:
- Un système utilisant des produits a besoin d'être indépendant de la façon dont ces produits sont créés et regroupés.
- Un système est paramétré par plusieurs familles de produits qui peuvent évoluer.