Discussion :

[Invité]

Bonjour,

Je suis confronté à un problème de conception.
Pour faire simple, je souhaite utiliser le patron de conception singleton pour modéliser XX classes.
Ainsi dans ce pattern, toutes les classes ont un attribut static (instance), un constructeur privé et une methode getInstance().

Je me demandais s'il serait possible de faire une sorte d'héritage pour ne pas devoir réécrire tout ses elements XX fois dans chacune de mes classes. Le problème de l'héritage c'est que rien que l'attribut static sera commun a chacune de mes classes.
Alors qu'il faudrait qu'il soit commun a chacune des instances de classes filles dans un contexte indépendant les unes des autres.

Je ne sais pas si je suis compréhensible :/

Existe-t'il un moyen de le faire en Java ?
Merci

[thelvin]

Nope. Tout ce qui est statique et spécifique à une classe, doit apparaître dans cette classe.

Tu pourrais t'en sortir en évitant d'appeler des méthodes statiques pour chaque, mais une méthode centralisée, genre remplacer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse ma = MaClasse.getInstance();

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse ma = singletons.get(MaClasse.class);

La manière dont l'objet singletons s'y prend pour avoir les singletons, dépend si tu fais du lazy-loading ou un chargement au démarrage. Malheureusement le lazy-loading imposerait un coût de synchronisation systématique, et le chargement au démarrage impose quasi-certainement de faire quelque part la liste des classes à charger.
Mais dans les deux cas, il y a moyen d'utiliser l'introspection pour éviter de copier/coller les mêmes codes dans toutes les classes.

... Sinon il y a aussi la solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse ma = singletons.getMaClasse();

Pour chaque classe à singleton, ajouter dans une classe centrale une méthode qui donne son singleton. Ça oblige à en faire la liste, mais ça n'a pas les inconvénients ci-dessus.


Après, dans des situations très précises, il y a d'autres solutions pratiques, comme l'injection de dépendance.

[tchize_]

Un truc du genre?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 LogFactory logFactory = DiscoverSingleton.find(LogFactory.class);

Tu trouvera ça dans apache dicovery.

Bon, l'inconvénient, c'est que du coup tes programmeurs savent faire un new LogFactoryImpl() pour contourner le singelton.

[adiGuba]

Salut,


Sinon une solution simple et élégante pour créer un singleton, c'est de le définir comme une enum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public enum MaClasse {
    INSTANCE;
 
 
    // méthodes et attributs du singleton
}

• MaClasse.INSTANCE remplace MaClasse.getInstance()
• Pas de problème de lazy-loading ou autre. On est sûr d'avoir une seule et unique instance.
• Le Singleton est sérializable "proprement" (la désérialisation retournera bien MaClasse.INSTANCE et non pas une copie)

a++

[thelvin]

Tiens ça fait un peu bizarre, mais c'est pas con.

[joel.drigo]

Pour le coup, avec l'enum, on perd la possibilité d'héritage indiquée dans la question d'origine.

[Gugelhupf]

Le Singleton est sérializable "proprement" (la désérialisation retournera bien MaClasse.INSTANCE et non pas une copie)

Bonjour,

Je ne suis pas sur de bien comprendre. On peut se servir d'un singleton pour retourner l'instance d'une connexion, hors cet élément "connexion" n'est pas copiable ou sérializable. Donc un singleton ne sera pas forcément sérializable.

La désérialisation doit forcément retourner une copie non ?

[thelvin]

Pour le coup, avec l'enum, on perd la possibilité d'héritage indiquée dans la question d'origine.

Moi j'avais compris qu'ils héritaient tous de la même classe parentes, qui elle-même n'a pas de singleton, et que eux n'ont pas de sous-classe. Situation courante. D'un point de vue polymorphique, un singleton qui a des sous-types c'est pas très cohérent.
... Mais évidemment, s'il y a besoin d'héritage de ce genre, l'enum ne tient pas.

Je ne suis pas sur de bien comprendre. On peut se servir d'un singleton pour retourner l'instance d'une connexion, hors cet élément "connexion" n'est pas copiable ou sérializable. Donc un singleton ne sera pas forcément sérializable.

La désérialisation doit forcément retourner une copie non ?

Peut-être que tous les singletons ne sont pas sérialisables, mais beaucoup le sont. L'instance de connexion est loin d'être le seul exemple de pattern singleton. Et on pourrait se demander pourquoi il a besoin de tonnes de classes singleton pour des instances de connexion.

[adiGuba]

Tiens ça fait un peu bizarre, mais c'est pas con.

J'ai souvent vu cette astuce... Simple et efficace !

Pour le coup, avec l'enum, on perd la possibilité d'héritage indiquée dans la question d'origine.

Le point sur l'héritage je l'ai compris uniquement pour éviter de réécrire le getInstance() à chaque fois...
Sinon oui cela ne serait pas adapté.

La désérialisation doit forcément retourner une copie non ?

Non car les enums sont traités spécifiquement par la sérialisation :

• Lors de la sérialisation d'une enum, cela ne sauvegarde que son type et son nom.
• Lors de la désérialisation d'une enum, la valeur correspondant est récupérer à partir de son type et de son nom (sûrement via Enum.valueOf())

a++