Patrons de conception/Fabrique

La fabrique (factory) est un patron de conception de création utilisé en programmation orientée objet. Comme les autres modèles de création, la fabrique a pour rôle l'instanciation d'objets divers dont le type n'est pas prédéfini : les objets sont créés dynamiquement en fonction des paramètres passés à la fabrique.

Patrons de conception

Version imprimable

[ Modifier le sommaire ]

Prototype

Fabrique abstraite

Patron de conception
Catégorie : « Gang of Four » – Création
Nom français :	Fabrique / Fabrication
Nom anglais :	Factory method / Virtual Constructor
Permet la sélection de la classe concrète de l'instance créée en fonction des paramètres de construction

Comme en général, les fabriques sont uniques dans un programme, on utilise souvent le patron de conception singleton pour gérer leur création.

Diagramme de classes UML

Le patron de conception Fabrique peut être représenté par le diagramme de classes UML suivant :

Diagramme de classe pour le patron de conception Fabrique

Exemples

Base de données

Considérons une interface de base de données qui supporte de nombreux types de champs. Les champs d'une table sont représentés par une classe abstraite appelée Champ. Chaque type de champ est associé à une sous-classe de Champ, donnant par exemple : ChampTexte, ChampNumerique, ChampDate, ou ChampBooleen.

La classe Champ possède une méthode display() permettant d'afficher le contenu d'un champ dans une interface utilisateur. Un objet de contrôle est créé pour chaque champ, la nature de chaque contrôle dépendant du type du champ associé : le contenu de ChampTexte sera affiché dans un champ de saisie texte, celui de ChampBooleen sera représenté par une case à cocher.

Pour résoudre ce problème, Champ contient une méthode de fabrique appelée createControl() et appelée depuis display() pour créer l'objet adéquat.

Animaux

Dans l'exemple suivant, en Java, une classe « fabrique » des objets dérivés de la classe Animal en fonction du nom de l'animal passé en paramètre. Il est également possible d'utiliser une interface comme type de retour de la fonction.

public class FabriqueAnimal
{
    private static FabriqueAnimal instance = new FabriqueAnimal();
    
    private FabriqueAnimal() {}

    public static FabriqueAnimal getFabriqueAnimalInstance() {
        return instance;
    }

    public Animal getAnimal(String typeAnimal) throws ExceptionCreation
    {
        if (typeAnimal.equals("chat"))
            return new Chat();
        else if (typeAnimal.equals("chien"))
            return new Chien();
        else
            throw new ExceptionCreation("Impossible de créer un " + typeAnimal);
    }
}

public abstract class Animal {
   public abstract void myName();
}

public class Chat extends Animal {
   @Override
   public void myName() {
     System.out.println("Je suis un Chat");
   }
}

public class Chien extends Animal {
   @Override
   public void myName() {
     System.out.println("Je suis un Chien");
   }
}

public class FabriqueExemple{
   public static void main(String [] args){
     FabriqueAnimal fabrique =  FabriqueAnimal.getFabriqueAnimalInstance();
     try {
       Animal animal = fabrique.getAnimal("chien");
       animal.myName();
     } catch(ExceptionCreation e) {
       e.printStackTrace();
     }
   }
}

Utilisation

Les fabriques sont utilisées dans les toolkits ou les frameworks, car leurs classes sont souvent dérivées par les applications qui les utilisent.
Des hiérarchies de classes parallèles peuvent avoir besoin d'instancier des classes les une des autres.

Autres avantages et variantes

Bien que la principale utilisation de la Fabrique soit d'instancier dynamiquement des sous-classes, elle possède d'autres avantages qui ne sont pas liés à l'héritage des classes. On peut donc écrire des fabriques qui ne font pas appel au polymorphisme pour créer plusieurs types d'objets (on fait alors appel à des méthodes statiques).

Noms descriptifs

Les langages orientés objet doivent généralement avoir un nom de constructeur identique au nom de la classe, ce qui peut être ambigu s'il existe plusieurs constructeurs (par surcharge). Les méthodes de fabrication n'ont pas cette obligation et peuvent avoir un nom qui décrit mieux leur fonction. Dans l'exemple suivant, les nombres complexes sont créés à partir de deux nombres réels qui peuvent être interprétés soit comme coordonnées polaires, soit comme coordonnées cartésiennes ; l'utilisation de méthodes de fabrication ne laisse aucune ambiguïté :

public class Complex
{
    public static Complex fromCartesian(double real, double imag)
    {
        return new Complex(real, imag);
    }

    public static Complex fromPolar(double rho, double theta)
    {
        return new Complex(rho * cos(theta), rho * sin(theta));
    }

    private Complex(double a, double b)
    {
        //...
    }
}

Complex c = Complex.fromPolar(1, pi); // Identique à fromCartesian(-1, 0)

Le constructeur de la classe est ici privé, ce qui oblige à utiliser les méthodes de fabrication qui ne prêtent pas à confusion.

Encapsulation

Les méthodes de fabrication permettent d'encapsuler la création des objets. Ce qui peut être utile lorsque le processus de création est très complexe, s'il dépend par exemple de fichiers de configuration ou d'entrées utilisateur.

L'exemple ci-dessous présente un programme qui crée des icônes à partir de fichiers d'images. Ce programme sait traiter plusieurs formats d'images représentés chacun par une classe :

public interface ImageReader
{
    public DecodedImage getDecodedImage();
}

public class GifReader implements ImageReader
{
    public GifReader( InputStream in )
    {
        // Vérifier qu'il s'agit d'une image GIF,
        // lancer une exception si ce n'est pas le cas,
        // décoder l'image sinon.
    }
 
    public DecodedImage getDecodedImage()
    {
        return decodedImage;
    }
}

public class JpegReader implements ImageReader
{
    //... même principe
}

Chaque fois que le programme lit une image, il doit créer le lecteur adapté à partir d'informations trouvées dans le fichier. Cette partie peut être encapsulée dans une méthode de fabrication :

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.
        }
    }
}

Le type d'image et le lecteur correspondant peuvent ici être stockés dans un tableau associatif, ce qui évite la structure switch et donne une fabrique facilement extensible.

Bonnes pratiques

Nommer la classe de la fabrique avec le nom de la classe instanciée en préfixe et le mot factory en suffixe, pour indiquer aux lecteurs qu'on utilise ce patron sur telle classe.
Eviter de sauvegarder le résultat de la fabrique (en base de données) depuis la classe de celle-ci, pour respecter les principes SOLID et autoriser la création d'objets éphémères, par exemple dans les tests automatiques.