Attribut static héritage

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

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:

---

MaClasse ma = MaClasse.getInstance();

---

par

Code:

---

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:

---

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.

Un truc du genre?

Code:

---

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.

Salut,


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

Code:

---

1 2 3 4 5 6

public enum MaClasse { INSTANCE;     // méthodes et attributs du singleton }

---

:arrow:

• 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++

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

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

Citation:

---

Envoyé par adiGuba

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 ?

Citation:

---

Envoyé par joel.drigo

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.

Citation:

---

Envoyé par Gugelhupf

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.

Citation:

---

Envoyé par thelvin

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

---

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

Citation:

---

Envoyé par joel.drigo

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é.

Citation:

---

Envoyé par Gugelhupf

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++

Citation:

---

Envoyé par adiGuba

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é.

---

Je voulais dire que si le but est de proposer, dans une API par exemple, une classe genre AbstractSingleton, que n'importe qui peut implémenter pour la manimuler avec l'API (sinon, je ne vois pas bien le but de définir une classe commune), ce ne sera pas possible directement, puisqu'on ne peut faire que l'enum (ou plusieurs) hérite d'une classe. Bien sûr on pourrait définir une interface ISingleton avec la méthode getInstance(), et l'implémenter sur l'enum, genre :

Code:

---

1 2 3 4 5 6 7 8 9

public enum Singleton1 implements ISingleton {   INSTANCE;   public ISingleton getInstance() { return this; }   }

---

Toutefois, ceci ne permet pas d'imposer que l'instance retournée soit un singleton.

En faisant, on peut imposer que cela soit une enum, et indirectement imposer que l'instance retournée soit un singleton (s'il y'a plus simple, je suis preneur) :

Code:

---

1 2 3 4 5

public interface ISingleton<T extends Enum<T> & ISingleton<T>> {   T getInstance();   }}

---

Code:

---

1 2 3 4 5 6 7 8 9

public enum Singleton1 implements ISingleton<Singleton1> {   INSTANCE;   public Singleton1 getInstance() { return this; }   }

---

Bon, il n'y pas vraiment plus d'héritage au sens strict peut être, mais au moins ça permet effectivement d'avoir une API capable de gérer les instances de singletons conformes à ce qu'on attend.

Je ne me rappelle plus exactement, mais il me semble que pour que la sérialisation soit accepté par ObjectOutputStream, il faut que l'objet, ainsi que ses attributs doivent implémenter l'interface marqueur Serializable (sinon préciser transient pour les attributs non sérializable).

L'objet de type MaConnexion ne va pas implémenter Serializable, donc la sérialisation risque d'échouer non ?

Le traitement pour les enums est-t-il aussi "spécifique" par rapport aux classes ? :aie:


Merci

Citation:

---

Envoyé par Gugelhupf

Le traitement pour les enums est-t-il aussi "spécifique" par rapport aux classes ? :aie:

---

Ben justement pour les enums les attributs ne sont pas sauvegardé, donc cela ne posera pas de problème.

Par contre bien sûr tu ne récupèrera pas l'état du singleton sauvegardé...


a++

Je réfléchis depuis plusieurs jours à l'intérêt de sérialiser une enum.
Et je ne vois pas de réel intérêt en fait.
Je pense que les "attributs" des enum ne sont pas sérializable car ce sont l'équivalent de "public final static".

L'intérêt, c'est de sérializer un classe dont un attribut est un enum:

Code:

---

1 2 3 4 5 6 7 8

public class Personne implements Serializable { private String name; private String lastname; private Gender gender; //.... }   public enum Gender {MALE,FEMALE}

---

Bref, ca a autant d'intérêt que de pouvoir sérializer un String ou un int.

Bonjour,

Merci pour toutes vos réponses et cette discussion très enrichissante.
Je ne connaissais pas les Factories, je pense que c'est ce qui va correspondre le mieux a mes besoins.