Bien implémenter son singleton
Lorsque plusieurs membres d’un programme vont utiliser les mêmes données, on se retrouve confronté au choix entre le singleton et la classe statique. Ce choix est assez important, et dépend entièrement de la visibilité de ces données. Il sera parfois plus judicieux d’utiliser une classe statique qu’un singleton. Par exemple, en programmant un jeu de tennis en C# (que je n’ai pas encore complètement terminé d’ailleurs…), j’avais besoin d’accéder souvent au calendrier ATP. La visibilité de ce calendrier était pratiquement globale, beaucoup de classes devaient y avoir accès et il était plus facile d’en faire une classe statique avec ses méthodes statiques… Dans d’autres cas, le singleton était plus approprié. Il n’est pas limité en accès aux membres statiques, il est sérializable, etc…
Récemment, en révisant du code sur un projet au boulot, je suis tombé sur des mauvaises implémentations de singletons de ce type :
-
public class SinglePart {
-
private static SinglePart oPart = null;
-
-
public static SinglePart getSinglePart() {
-
if (oPart == null){
-
oPart = new SinglePart();
-
}
-
return oPart;
-
}
-
}
La classe fonctionnait bien, puisque le programmeur avait fait attention à ne l’instancier qu’une seule fois. En fait, il y a 2 erreurs avec cette implémentation :
- Il manque un constructeur privé pour remplacer le constructeur public et donc éviter une autre instanciation via ce dernier.
- Rien n’assure que le singleton ne soit créé deux fois en même temps par deux threads séparés.
La solution consiste donc à ne pas oublier le constructeur privé, ainsi que l’utilisation du mot clef synchronized :
-
public class SinglePart {
-
private static SinglePart oPart = null;
-
-
// constructeur privé
-
private SinglePart() {}
-
-
public synchronized static SinglePart getSinglePart() {
-
if (oPart == null){
-
oPart = new SinglePart();
-
}
-
return oPart;
-
}
-
}