public Blog<Benwit> monblog;

Un article de benwit    7 Commentaires

Avec un titre pareil, toi, esprit perspicace, tu auras compris de qui je veux parler, n’est-ce pas ?

Et puisque que je ne t’apprendrai rien sur lui, je vais plutôt te parler de notre histoire à tous les deux, de notre rencontre, du temps qu’on a pensé ensemble, des infidélités, de notre séparation, de nos retrouvailles, etc…

Il existe de nombreux patrons de conceptions et s’il faut en choisir un pour commencer, lequel s’accorde parfaitement avec le chiffre 1 ?
Le singleton bien évidemment puisque son but est de restreindre l’instanciation d’une classe à un seul objet.

=> Rencontre du 1° type

La première fois que je l’ai aperçu, c’est lors de travaux pratiques. Le prof voulait nous initier aux patrons de conception mais plutôt que de partir dans une présentation théorique, il a simplement écrit quelques noms de ces « saints » patrons au tableau et demandé à ce qu’on en choisisse deux pour lesquels on lui ferait un petit compte rendu. Mon choix s’était porté sur Singleton et Adapter et on ne peut m’accuser d’avoir jouer petit dans la mesure où je ne les connaissais pas encore.

Pour ceux qui l’ignorent, une petite explication dynamique :

Puisqu’on ne veut pas créer plusieurs instances (objets) d’un même type (classe), la première idée consiste à interdire aux objets clients d’appeler le constructeur de notre type Singleton donc il faut le mettre en visibilité privée :

private Singleton(){};

C’est à ce moment là qu’un petit malin dit : « Ouais, mais comment on le crée alors ? »
On répond que comme les méthodes privées ne peuvent être appelées que de la classe elle même, l’instance unique sera créée dans la classe Singleton.

La question devient : « Ok, supposons qu’on a créée cette unique instance dans la classe Singleton, comment la récupère t’on dans la classe cliente ? »

De l’extérieur, comme on ne dispose pas encore d’objet, on ne peut faire appel qu’à une méthode statique publique de la classe Singleton :

public static Singleton getInstance()

En fusionnant les deux idées précédentes, on pourrait écrire

public static Singleton getInstance()
{
   return new Singleton();
};

mais cela ne fait que rajouter un niveau d’indirection et on n’est pas plus avancé puisque qu’il suffit au client de faire plusieurs appels à getInstance() pour obtenir plusieurs instances de Singleton.

Puisqu’on veut obtenir une instance unique, on sent bien que l’appel à getInstance() doit nous retourner toujours le même objet et donc qu’il faut conserver sa référence dans une variable de classe :

private static Singleton instance;

La méthode devient :

public static Singleton getInstance()
{
   if (instance == null)
    instance = new Singleton();
 
   return instance;
};

Si elle est indéfinie (au premier appel), on crée une instance que l’on mémorise et qu’on retournera les fois suivantes (les appels successifs)
Ce qui semble LA solution évidente !

=> Premier rendez vous : La classe !

Quelques années plus tard, dans la vie active, j’ai repensé à ma chère et unique instance …
belle comme une déesse, je l’ai invoquée …
et je l’ai trouvé entière à souhait.

=> Duplicité : Ange & Démon

Malheureusement, au fil d’une conversation sur plusieurs fils (thread), je me suis rendu compte qu’elle n’était pas si unique que cela, elle avait une soeur jumelle qui n’habitait pas à la même adresse ! Oh my god, comment c’était possible ???

En fait, le code précédent rencontre des problèmes dans le cas d’application multithread (les détails de cette sombre histoire au 2.2)

=> Infidélités, à mon tour !

Les patrons c’est bien, ça nous guide, mais arrive un moment où petit scarabée rêve de liberté et ne veut plus suivre aveuglément maître yoda. Il veut expérimenté par lui même …
Pour éviter de voir double et de rentrer dans des histoires de « Ce n’est pas le bon moment, synchronisons nous … » j’ai désappris « le code standard » pour écrire :

private static Singleton instance = new Singleton();
 
public static Singleton getInstance()
{
   return instance;
};

Un jour, je suis même aller voir du côté des classes « utilitaires » à méthodes statiques qui avaient aussi leurs charmes.

Puis déplorant le fait qu’en statique, on ne peut pas modifier un comportement par redéfinition, je me suis laissé tenter par un singleton à la dérive (le super singleton ayant alors un constructeur protected).

Plus tard, en réfléchissant à la manière de modifier le comportement d’un Singleton à constructeur privé (utiliser la composition au lieu de l’héritage), et constatant que par analogie, il suffisait de faire pareil avec une classe à méthodes statiques, je me suis rendu compte que je m’étais fourvoyé dans cette histoire.

=> Je te quitte !

Le coup de grâce me fut donnée le jour où j’ai réalisé que mon instance unique d’application avait des instances uniques de plusieurs services. J’avais abusé des bonnes choses.

Je suis donc retourné à la source. L’intérêt du singleton, c’est que plusieurs classes clientes partagent le même objet qui est l’unique représentant d’un certain type.
Dans le cas de mon application, il n’y a pas de classe cliente puisque c’est mon point d’entrée. Le singleton ne se justifie pas.
Ensuite, pour mes services applicatifs (service de trace, de traduction, …), le singleton était une solution si toutes les autres composants les attaquaient directement. Du moment où ces services sont injectés dans mon application (objet unique) et que ces composants ont une référence sur l’application, ce pattern n’est plus nécessaire.

=> … mais je ne t’ai pas oublié ;o)

Je l’ai utilisé à tord et à travers mais je ne le regrette pas, j’ai vu son intérêt et ses limites.

Il ne faut pas jeter le bébé avec l’eau du bain car il peut être utile.
Par exemple, le singleton peut implémenter des interfaces, alors qu’une classe à méthodes statiques ne le peut pas (ce qui n’est guère étonnant pour du code pas vraiment objet).

Mais n’oubliez pas que sa simplicité peut vous jouer des tours :

• Simplicité d’utilisation, il peut devenir l’anti-pattern du marteau en or.
• Simplicité d’apparence, si on reste sur « le code standard », il peut causer des bugs en environnement multithread.