Dans les systèmes d’information (cela est également vrai dans de nombreux métiers), des problématiques récurrentes de conception se présentent. En développement, plutôt que chaque développeur réfléchisse à la meilleure façon de traiter ces problématiques, des Design Patterns (ou patrons de conception) ont vu le jour permettant de proposer à un problème particulier la solution la plus élégante en regard des bonnes pratiques. Ces patrons de conception sont de plusieurs natures. Ce billet est le premier d’une série sur les patrons de conception, et on commence par les deux grands classiques des design patterns.

Singleton

Ce Design Pattern permet de s’assurer qu’une classe ne sera instancié qu’une seule fois durant toute l’exécution d’un script. C’est utile par exemple dans le cas de connexions à une base ou pour stocker des configurations. Mais l’utilisation de ce patron de conception fait de plus en plus débat, du fait des problèmes qu’il pose en environnement multi-thread (obligeant à des acrobaties comme le Double-checked locking) et dans les dépendances entre classes (problème expliqué dans le début de la page en lien).
Pour s’assurer du fait que la classe n’est instanciée qu’une fois, le constructeur de la classe et la méthode clone doivet être mis en privés. On est ainsi sûr qu’ils ne seront appelés qu’au travers de la classe. Pour pouvoir accéder de l’extérieur à l’instance de la classe, il faut créer une propriété statique dans la classe qui contiendra la dite instance. Enfin, une méthode statique permettra d’appeler le constructeur si l’instance n’existe pas encore (premier appel), ou de renvoyer la propriété instance si celle ci existe.
Pour des exemples d’implémentation dans différents langages, vous pouvez vous référer à la page Wikipédia.

Fabrique (Factory)

Ce design pattern permet de déléguer l’instanciation de vos classes à une classe usine qui le fera pour vous. Elle va attendre en paramètre le type d’objet à créer, fera l’instanciation et renverra l’objet ainsi créé.
Ce patron de conception permet notamment d’instancier des objets dérivant d’une classe abstraite.
Cela peut être particulièrement utile si vous désirez ajouter une couche d’abstraction à votre base de données. Vous n’aurez qu’à appeler votre classe usine avec le type de base souhaitée et elle vous renverra l’objet connecté, en gardant en son sein toutes les étapes d’instanciation et de connexion. Cela allège du coup grandement le code hors usine, facilite le refactoring et centralise une partie non négligeable des traitements. Vous pouvez aller voir la page Wikipédia pour plus d’informations. Et si vous avez besoin d’encore plus d’abstraction, vous pourrez faire appel au pattern Fabrique Abstraite.