Abstract Factory (Fabrique abstraite)

Les « design patterns » sont des solutions de design et d’implémentation de code informatique dans le but de le rendre propre, optimisé, robuste, maintenable et évolutif.  Ce qui permet ainsi de répondre à des problématiques récurrentes de développement, tout particulièrement en Programmation Orientée Objet (POO).

Il existe 3 principaux types de « design pattern »:

• les patterns de création,
• les patterns de structuration,
• les patterns comportementaux.

« L’abstract Factory » est un pattern de création (Creational Pattern) : il va donc nous servir pour instancier des objets.

Pour retenir facilement ce Patron de conception, on va essayer de comprendre ses termes : Factory et Abstract :

Factory : En développement orienté objet, une Factory (Fabrique) est un bout de code dédié qui a pour fonction de construire des objets : d’où son nom « Fabrique ».

Abstract : l’abstraction en développement objet permet de regrouper des comportements communs à une famille d’objets. Par exemple, un carré, un rectangle et un triangle vont hériter d’une classe « abstraite » « Forme Géométrique » qui contient un nombre de cotés, une superficie, etc.

Le pattern abstract Factory permet de rassembler des méthodes communes à des familles d’objets différents dans une classe commune : la fabrique abstraite, afin d’éviter au client d’appeler des méthodes différentes (concrètes) par famille d’objets.

Pour implémenter ce pattern, on fait intervenir en règle générale :

• L’Abstract Factory : contient les interfaces pour les opérations communes de construction d’objets,
• La Concrete Factory : contient l’implémentation concrète de construction d’un objet donné,
• Les Abstract Products : déclarent les interfaces des produits,
• Les concrete Products : déclarent les produits à implémenter,
• Un client : le client utilisera uniquement les interfaces de l’abstract Factory pour implémenter les objets concrets.

Diagramme de classe mettant en exergue le pattern Abstract Factory

Exemple concret d’utilisation :

J’implémente une application de gestion d’assemblage de voitures destinées aux marchés européen et américain. Dans les 2 cas, j’effectue les mêmes tâches comme, par exemple, monter le moteur et les roues. Cependant, j’ai des spécificités pour chacun des marché : par exemple pour le marché français j’utilise un moteur de 110ch et pour le marché américain un moteur de 200ch. Dans ce cas de figure, je souhaiterais simplifier l’implémentation car j’effectue des tâches communes (assembler des voitures) sur des produits de mêmes familles (des voitures) et qui présentent des caractéristiques différentes (donc des implémentations différentes). Ce cas de figure est un candidat idéal pour l’Abstract Factory.

Vous trouverez via le lien GitHub, un exemple de code implémentant l’Abstract Factory.

Quand l’utiliser ?

Le pattern Abstract Factory peut être intéressant dans les cas suivants :

• • Quand on veut faire cohabiter des familles d’objets ayant des comportements communs (ce qui arrive très souvent).
  • Quand je ne veux pas rendre accessible l’implémentation concrète d’une famille d’objets (le client aura accès qu’aux interfaces).

Que retenir ?

On retrouve à travers le pattern Abstract Factory des concepts fondamentaux et très utilisés en POO : l’héritage, les interfaces et les fabriques : ce qui fait de l’Abstract Factory un très bon exemple de pattern à connaitre.