Réinstancier un singleton

Bonjour,

Existe-t-il un moyen de ré-instancier un singleton ?

Merci d'avance.

Salut,


Si tu cherches à faire cela c'est que tu dois avoir un gros problème : le principe même du singleton c'est justement de ne pas être instancié plusieurs fois !!!


:arrow: Détailles ton problème !


a++

Citation:

---

Envoyé par rocklass

Bonjour,

Existe-t-il un moyen de ré-instancier un singleton ?

Merci d'avance.

---

Comme l' a dit adiGuba, le principe dernière un singleton c'est d'avoir une seule instance de la classe. On utilise donc un système de cache qui contient une référence de l'objet durant la vie du programme.

De ce fait, il ne peut y avoir plusieurs instances d'un singleton sinon, cela violerait le principe précédemment annoncé.

un Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class mySingleton { private mySingleton cache;   private mySingleton() // pour ne pas être appelé par une autre classe { }   public static mySingleton getInstance() { if (cache == null) cache = new mySingleton();   return cache; } }

---

Avec ce bout de code, il est donc impossible d'avoir plusieurs instances de cette classe. A moins d'empressement créer ces instances depuis la classe elle-même.

ça, c'est l'implémentation naive du singleton à ne pas utiliser :)

Citation:

---

Envoyé par tchize_

ça, c'est l'implémentation naive du singleton à ne pas utiliser :)

---

Alors laquelle devrait-on utiliser ?

Salut,

Citation:

---

Envoyé par darrylsite

Alors laquelle devrait-on utiliser ?

---

Ceci par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public final class MySingleton { private static MySingleton INSTANCE = new MySingleton();   private MySingleton() { }   public static MySingleton getInstance() { return INSTANCE ; } }

---

Comme cela tu es sûr qu'il n'y aura qu'une seule et unique instance Singleton, car elle sera créé par le Classloader.


Dans le code que tu donnais, il est possible d'en créer plusieurs si on appelle la méthode getInstance() en même temps depuis plusieurs threads...


Sinon il y a une solution toute simple qui permet de gérer en plus la Sérialisation de manière propre :

Code:

---

1 2 3 4

public enum MySingleton { INSTANCE; }

---

a++

Je vais expliquer mon problème plus en détail. Voici ma classe singleton :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

public final class Application {   /** instance unique */ private static final Application APPLICATION = new Application();     /** workspace */ private final Workspace workspace = new Workspace();   static { // initialisation APPLICATION.workspace.init(); }   /**    * Constructeur    */ private Application() { // Traitement }   /**    * Retourne une instance unique de l'application    * @return application    */ public static Application getApplication() { return APPLICATION; }   /**    * Retourne le workspace    * @return workspace    */ public Workspace getWorkspace() { return workspace; }

---

Cette classe me permet de lancer mon application. C'est un singleton car je veux que mon application Swing ne soit lancée qu'une fois à la fois sur une même JVM.

Or je souhaite écrire un test JUnit qui lance l'application, la ferme et la relance. Pour cela, je veux détruire l'instance courante de mon application et la lancer une nouvelle fois, de telle sorte que je n'ai toujours qu'une seule instance de mon application.

Dans le cadre d'une exécution normale de mon application (pas un test), je fais un System.exit(0) pour fermer mon application, mais si je fais la même chose lors d'un test JUnit, ça ferme également le thread JUnit. C'est pour cela que je souhaite procéder autrement en détruisant l'instance de mon application et en le re-créant.

Quelle est la meilleure solution pour résoudre mon problème ?

je vois trois possibilités:

1) modifier le singleton pour obtenir sa collaboration (byebye final, ajout d'une méthode protégée reset(), etc)
2) utiliser à fond les apis reflection pour violenter méchamment le singleton (bof bof mais jouable)
3) utiliserdes framework comme powermock jmockup, mockito ou autre, certain d'entre eux permettent de jouer sur les singletons.

Citation:

---

Envoyé par tchize_

je vois trois possibilités:

1) modifier le singleton pour obtenir sa collaboration (byebye final, ajout d'une méthode protégée reset(), etc)
2) utiliser à fond les apis reflection pour violenter méchamment le singleton (bof bof mais jouable)
3) utiliserdes framework comme powermock jmockup, mockito ou autre, certain d'entre eux permettent de jouer sur les singletons.

---

Je partirai bien sur la première solution mais je ne vois pas comment implémenter ce fameux reset.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

public final class Application {   /** instance unique */ private static Application APPLICATION = new Application();     /** workspace */ private final Workspace workspace = new Workspace();     /**    * Constructeur    */ private Application() { workspace.init(); }   /**    * Retourne une instance unique de l'application    * @return application    */ public static Application getApplication() { return APPLICATION; }   protected static void resetSingleton(){ APPLICATION = new Application(); }   /**    * Retourne le workspace    * @return workspace    */ public Workspace getWorkspace() { return workspace; }

---