Catégories
Design patterns

Design Pattern: Factory

Problématique

Lors du développement d’applications nécessitant un grand nombre de type de données différentes,
mais contenant des données communes, il est fréquent de devoir concevoir une classe qui va
instancier différents types d’objets suivant un paramètre fourni.
Cependant, cette architecture engendre plusieurs problèmes, tout d’abord le code est amené à se
répéter pour chaque condition de création de notre entité, l’évolution de la classe entité peut alors
nécessiter de modifier les appels de l’entité, puisque l’on appelle un type concret, restreignant
l’évolutivité du code.
De plus, ce code va être amené à évoluer régulièrement lors de l’ajout de nouveaux produits à
fabriquer ou de la suppression de certains produits obsolètes. Ceci est un cas très fréquent dans les
applications de gestion où la gestion des entités métier est très présente et évolue souvent.

static void Main(string[] args)
{
    //...
}

Présentation

L’utilisation du design pattern factory nécessite de repenser la façon de procéder à la création des
entités.
Chaque entité ne sera plus appelée à partir de son constructeur, mais à partir d’une méthode d’une
classe factory qui sera chargée d’instancier l’entité en prenant en compte des paramètres passés.
L’annexe 1 permet de voir le lien entre la factory et l’entité du framework et l’héritage utilisé pour la
classe Projet de DevTeam.
La classe exacte de l’objet n’est donc pas forcément connue par l’appelant, la méthode retournant un
type abstrait, Entity, afin de clarifier le type, on peut utiliser l’opérateur « as » lors de l’instanciation
pour pouvoir accéder aux méthodes et propriétés propre au type.

Exemples

 public class ImageReaderFactory {
     public static ImageReader getImageReader( InputStream is ) {
         int imageType = figureOutImageType( is );
 
         switch( imageType ) {
         case ImageReaderFactory.GIF:
             return new GifReader( is );
         case ImageReaderFactory.JPEG:
             return new JpegReader( is );
         // etc.
         }
     }
 }

Avantages

Le principal avantage est de découpler la création d’un objet de son utilisation par une classe cliente,
on peut ainsi faire évoluer la classe EntryForm sans que cela n’ait d’incidence sur les utilisateurs sur
la classe ProjectEntryForm (voir Figure 5).
Le design pattern factory, tend aussi à diminuer les dépendances entre les différents éléments de
l’architecture du projet en favorisant l’abstraction du code. Cela permet ainsi une meilleure
évolutivité du code et une plus grande facilité de maintenance.

Inconvénients

Cependant, son utilisation doit être pensée au tout début du projet pour être efficace, de plus les
factory n’étant pas seulement utilisés sur les entités, mais aussi les entryforms, les listpages et les
DbAdapters associés, cela induit un grand nombre de classes dans la solution pour une seule entité.
De plus comme tout design pattern, pour être efficace il faut qu’il soit correctement implémenté
pour éviter d’aboutir à un antipattern

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *