Pages

Factory Design Pattern

Il est fréquent de devoir concevoir une classe qui va instancier différents types d'objets suivant un paramètre fourni. Par exemple une usine va fabriquer des produits en fonction du modèle qu'on lui indique. L'idée la plus simple pour répondre à ce besoin est d'écrire une succession de conditions qui suivant le modèle demandé, instancie et retourne l'objet correspondant. 
Le problème avec cette implémentation, c'est que la classe correspondant à l'usine va être fortement couplée à tous les produits qu'elle peut instancier car elle fait appel à leur type concret. Or 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.

De plus, il est fort probable que l'instanciation des différents produits soit également réalisée dans d'autres classes par exemple pour présenter un catalogue des produits fabriqués. 
On se retrouve alors avec du code fortement couplé, qui risque d'être dupliqué à plusieurs endroits de l'application.

Le modèle factory encapsule et sépare la création d'objets du reste de votre code. Dans les situations où la création d'un objet peut être complexe ou susceptible d'être modifiée, une usine (factory) peut servir de tampon agréable pour garder les choses en ordre. Sans planification adéquate Les usines peuvent entraîner des explosions de classe, par conséquent, le modèle peut être à la fois une bénédiction et une malédiction selon la façon dont il est utilisé.

Ci-dessus un exemple pour expliquer comment implémenter ce modèle :

houdass

Développeur depuis quelques années, j'ai une connaissance approfondie de nombreux langages et frameworks. Curieux de comprendre le "comment ça fonctionne" plutôt que de simplement "utiliser", c'est avec cet état d'esprit que j'évolue depuis plusieurs années et que j'élargie mes horizons.

Related Posts:

Aucun commentaire:

Enregistrer un commentaire