Le singleton. Le patron de conception utilisé, surutilisé et surtout mal utilisé par les développeurs. Bien que l’idée derrière celui-ci semble être géniale et convenir à toutes les situations, il est important de bien le comprendre et ne pas tomber dans le piège de l’utilisation fautive de ce patron.

Tout d’abord, pour les développeurs moins habitués avec cet paradigme de programmation, voici ce qu’est, selon Wikipédia, un singleton dans un développement applicatif.

En génie logiciel, le singleton est un patron de conception (design pattern) dont l’objet est de restreindre l’instanciation d’une classe à un seul objet (ou bien à quelques objets seulement). Il est utilisé lorsque l’on a besoin d’exactement un objet pour coordonner des opérations dans un système. Le modèle est parfois utilisé pour son efficacité, lorsque le système est plus rapide ou occupe moins de mémoire avec peu d’objets qu’avec beaucoup d’objets similaires.

Dans ma réalité actuelle, le singleton comporte un grand nombre d’avantages, sûrement encore plus d’inconvénients. Lorsqu’on joue avec les technologies Microsoft et .NET, certaines fonctionnalités ne nous permettent pas de jouer avec un singleton comme on le voudrait. Des situations bien précises m’ont pousser à repenser et améliorer le singleton dans le contexte de la programmation au sein de la plateforme SharePoint (et ASP.NET, en général).

Dans mes récentes recherches, les deux aspects suivants ont été revisité afin de redorer l’image du singleton :

• Support générique de l’héritage des comportements de singleton
• Gestion du singleton aux travers d’une requête HTTP

Dans les prochains billets, ces deux aspects seront mis de l’avant et permettront de comprendre le problème, d’analyser le cheminement vers la solution, et de voir une ébauche de la solution proposée. Vous pourrez revenir plus tard sur ce billet afin d’avoir une mise à jour vers les liens des billets à ce sujet.

• Partie 1 : Le singleton générique
• Partie 2 : Le singleton de contexte (À venir…)