Discussion :

[aristeas]

lu,

Je voudrais savoir si l'utilisation des Singleton, en nombre dans ma future application, ne risque pas de trop charger la mémoire vive, le CPU, etc... ?

Y a t il une règle d'usage à respecter ? (genre mettre l'object à null lorsqu'il n'est pas utilisé)


Exemple Developpez.com du Singleton :

Code :

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

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
 
/** Exemple d'implémentation d'un singleton.<p>
  * Cet exemple ne fait rien.
  */
 
public class Singleton {
 
    /** Récupère l'instance unique de la class Singleton.<p>
    * Remarque : le constructeur est rendu inaccessible
    */
    publicstatic Singleton getInstance() {
        if (null == instance) { // Premier appel
            instance = new Singleton();
        }
        return instance;
    }
 
    /** Constructeur redéfini comme étant privé pour interdire
    * son appel et forcer à passer par la méthode <link
    */
    private Singleton() {
    }
 
    /** L'instance statique */
    private static Singleton instance;
}

Merci
@+

[tchize_]

pourquoi as-tu beaucoup de singletons, est la question que tu devrais te poser. Pourquoi tes singletons devraient occuper beaucoup de mémoire en est un autre.

Mais de toutes facons, mettre à null les singleton retire l'intérête même d'avoir des signelton, puisque tu pourra avoir plusieurs instance de la classe.

[fr1man]

Je ne veux pas relancer un débat sur le singleton, mais l'écriture suivant est préférable :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Singleton {
	private static Singleton instance= new Singleton();
 
	private Singleton() {
	}
 
	public static Singleton getInstance() {
		return instance;
	}

[jabbounet]

Ce qu'il faut surtout éviter avec les singleton c'est l'écriture concurentielle car cela deviens un goulet d'étranglement.

Par contre tu peux t'en servir comme objet porteur de configuration que tu charge a l'init et que tu n'accede qu'en lecture pendant l'execution.

[aristeas]

lu,

En fait, je suis en train de tester la communication via les sockets.
Et le singleton me semble la meilleure façon de mettre à jour les données, dans les écrans, du client lorsque le serveur envoie ses données.

Ainsi, lorsqu'un object sera transmis, il sera analysé par le client puis mettra à jour les écrans associés (Table, Label, etc...) ; écran qui sont unique. C'est pour cela que le singleton me semble "bien".
Me suffira de prévoir une méthode de mise à jour dans chaque "class" de singleton.


Si vous avez mieux je suis preneur

@+

[millie]

En fait, je suis en train de tester la communication via les sockets.
Et le singleton me semble la meilleure façon de mettre à jour les données, dans les écrans, du client lorsque le serveur envoie ses données.

Si ton singleton dépend de ton client, ce n'est pas vraiment un singleton.

En Flex, on appelait ça un "model locator", je ne sais pas si c'est une terminologie reconnue.