Discussion :

[alex'l]

Bonjour,
J'ai une classe qui contient une dizaine de méthodes (principalement des méthodes qui exécutent des commandes système). Ces méthodes sont appellées régulièrement par beaucoup d'autre classes.
Pour obtenir une instance facilement de cette classe, j'ai décidé de faire un singleton donc j'effectue des appels au méthodes comme ca :

Code :

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

MaClasse.getInstance().maMéthode()

Mais j'aurais très bien pu mettre toutes mes méthodes en static et faire des appels comme ca :

Code :

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

MaClasse.maMéthode()

Question : Savez vous si il y a une différence entre les deux solutions ? ou si une solution est mieux que l'autre (niveau performance par exemple...) (il y a peut etre un cours qui existe car personnellement c'est un problème qui revient souvent) ... merci

[BRAUKRIS]

Oué c une trés bonne question, la seule différence que je vois c'est que dans le cas du Singleton tu n'instancies pas d'objet car le constructeur est 'private" mais dans le second cas il faut instancié un objet avant d'utiliser ces méthodes. Jsuis pas certain

En d'autres mots, le singleton c'est pour créer une classe qui n'aura qu une seule instance dans ton programme alors que dans ta 2iéme solutions tu partages des attributs ou méthodes dans plusieurs instance.

[BRAUKRIS]

Autre chose, si tu as différentes classes qui utilise des méthodes différentes pourquoi ne pas utilisé une classe abstraite.

[bouye]

Mais j'aurais très bien pu mettre toutes mes méthodes en static et faire des appels comme ca :

Code :

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

MaClasse.maMéthode()

mais dans le second cas il faut instancié un objet avant d'utiliser ces méthodes

.

Non puis ses méthode sont statiques dans le 2nd cas.

Le getInstance() pourrait très bien déférer l'allocation du singleton (histoire de conserver la mémoire) ou même retourner une instance d'une classe-fille (ex: une factory différente suivant la configuration du programme), ....
Egalement dans certains cas (ex: paramètres stockés dans des map) il vaut mieux manipuler une instance plutot que coder le nom de la classe en dur. Dans d'autre c'est plus simple d'appeler la classe directement (ex: fonction utilitaire dont on sait que l'implémentation sera toujours la même quelque soit l'utilisation - voir SwingUtilities).

En fait c'est vraiment celon l'archi de ton programme et tes besoins.

[alex'l]

Le getInstance() pourrait très bien déférer l'allocation du singleton

tu veux dire quoi par là?

[adiGuba]

Salut,

Le getInstance() pourrait très bien déférer l'allocation du singleton

tu veux dire quoi par là?

Je pense qu'il veut dire par là que tu peux facilement utiliser d'autres implémentations en renvoyant une autre classe...
Par exemple (avec AnotherSingleton qui hérite de Singleton) :

Code :

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

1
2
3
4
5
6
7
8
9
10
public static Singleton getInstance() {
	if (instance==null) {
		if ( /* n'importe quel condition */ ) {
			instance = new AnotherSingleton();
		} else {
			instance = new Singleton();
		}
	}
	return instance;
}

Ce te permet de facilement changer l'implémentation de ton Singleton sans toucher au code... alors que si tu utilises des méthodes statiques il faudra modifier tout le code pour changer les appels de méthodes...

De plus le singleton est une classe normale, tu peux donc faire un traitement particulier dans le constructeur (comme lire des fichiers de configuration, etc...) et ainsi avoir des relations entre les méthodes... Alors que les méthodes statiques sont indépendantes...

a++

[alex'l]

Autre chose, si tu as différentes classes qui utilise des méthodes différentes pourquoi ne pas utilisé une classe abstraite.

Quelle classe serait abstraite? Pour faire quoi?

[alex'l]

Ce te permet de facilement changer l'implémentation de ton Singleton sans toucher au code...

C'est vrai que ca peut être interessant. Je n'avais pas vu cet intéret d'utiliser le singleton... merci.

[bouye]

Lire 'Design Pattern" et "Design Pattern Explained" (les 2 existent en francais, le 2nd offre des exemples Java et C++) tout est très bien expliqué dedans. Il me semble également qu'il y a un bouquin spécifiquement sur les patterns en Java... à moins que ce ne soit un article sur le site de Sun.

[dlemoing]

Ce te permet de facilement changer l'implémentation de ton Singleton sans toucher au code...

Contre-exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class MaClasse implements MonInterface {
    private static MaClasse singleton;

    static {
        singleton = new MaClasse();
    }

    public static MonInterface getInstance() {
        return singleton;
    }
...
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class MaClasse2 extends MaClasse {
    private static MaClasse2 singleton;

    static {
        singleton = new MaClasse2();
    }

    public static MonInterface getInstance() {
        return singleton;
    }
...
}

Code :

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

1
2
MonInterface toto = MaClasse.getInstance();//Objet type MaClasse
MonInterface tata = MaClasse2.getInstance();//Objet type MaClasse2

Il te faudra donc, si tu veux changer la classe à utiliser, modifier tous les appels à la méthode getInstance() en choisissant la classe concrète à utiliser.

Une autre solution est au cours de l'initialisation de ton application, créer une instance de ton objet, la placer dans un "registre" et demander par la suite à ce registre de te fournir cette instance unique.
Cette solution t'offre un offre avantage, ta classe n'a plus à savoir qu'elle a un fonctionnement de singleton et on peut choisir de changer ce comportement sans gros impact sur l'application. Il suffit de configurer le registre pour qu'il fonctionne avec un "prototype" qu'il clone.

Code :

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

1
2
3
public class MaClasse implements MonInterface {
    ...
}

Code :

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

1
2
3
public class MaClasse2 extends MaClasse {
...
}

Code :

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

1
2
3
4
5
6
7
8
9
public class Registre {
    public void add(String cle, Object obj, boolean singleton) {
    ...
    }

    public Object get(String cle) {
    ...
    }
}

Code :

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

1
2
3
4
5
6
7
8
9
MonInterface toto = new MaClasse();
registre.add("toto", toto, true);
MonInterface toto2 = (MonInterface)registre.get("toto");
System.out.println(toto == toto2);//true

MonInterface titi = new MaClasse2();
registre.add("titi", titi, false);
MonInterface titi2 = (MonInterface)registre.get("titi");
System.out.println(titi == titi2);//false car 2 instances différentes mais avec les mêmes valeurs pour leur différents champs car utilisation d'un prototype

Si tu utilises un registre plus évolué, tu pourras lire dans un fichier de configuration la classe concrète à utiliser. C'est la démarche adoptée par Spring que j'ai grandement simplifié.

[bouye]

Moi je verrai plutot ca comme ca dans le cas ou on n'a pas besoin d'initiliaser toutes les classes concrete et ou on a besoin que d'une seule et unique instance de type MonInterface.

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
27
public abstrat class MaClasseAbstraite implements MonInterface { 
    private static MaClasseAbstraite singleton; 

    static { 
         if (testSuivantParametreDInitialisation) {
             singleton = new MaClasseConcrete1(); 
         }
         else {
             singleton = new MaClasseConcrete2(); 
         }
    } 

    public static MonInterface getInstance() { 
        // Voir les divers limitations/avantages de chaque methodes d'instanciantion des singletons dans la FAQ du site.
        return singleton; 
    } 
... 
}

class MaClasseConcrete1 extends MaClasseAbstraite { 
...
}

class MaClasseConcrete2 extends MaClasseAbstraite { 
...
}

Un exemple débile : tu fais un prog tout simple qui sauve des icones et tu veux juste utiliser une méthode saveImage(File, Image); qui produit une icon dependante de la plateforme surlaquelle l'app tourne sans te préocuper de connaitre les détails inhérents aux divers formats de fichiers et qui marche surquelle platforme. Sous Windows ca te retourne un createur de fichier ICO qui utilisera un encodeur/decodeur que tu auras fait ou récupéré, sous Linux un createur de PNG ou de pixmaps qui utilise ImageIO.

Un autre exemple peut etre une factory de widget graphiques dont la variante A produit des widget avec des options de debuggage et de trace activee, et la variante B produira les meme widgets sans options de debuggage pour la version finale du programme. Idem avec des widgets ayant des LnF ou apparences differentes (est-ce donc la maniere dont UIManager fonctionne en interne ???). A ce moment-la c'est une variable static à vrai/faux, un fichier de conf/pref ou divers autres manieres qui permettent de determiner quelle type de factory utiliser.

Le registre peut-etre cependant une maniere interessante de faire.
Encore une fois le choix de la méthode exacte depend des besoins et de l'archi de l'API ou de l'app.

[dlemoing]

Le registre est également plus flexible.
Comment avec ton exemple changer le comportement et passer d'un mode singleton à une utilisation illimitée ou à un pool d'instances ?
De plus, si je veux maintenant faire cohabiter un singleton de type MaClasseConcrete1 et un autre de type MaClasseConcrete2, comment faire ?
Si on est sur de vouloir une et une seule instance, on peut effectivement utiliser le modèle singleton. Par contre, il faut tenir compte des inconvénients en terme de flexibilité (toujours tenir compte des avantages ET inconvénients des patterns).

[bouye]

En fait c'est vraiment celon l'archi de ton programme et tes besoins.

Encore une fois le choix de la méthode exacte depend des besoins et de l'archi de l'API ou de l'app.

[SEMPERE Benjamin]

Salut,

Le getInstance() pourrait très bien déférer l'allocation du singleton

tu veux dire quoi par là?

Je pense qu'il veut dire par là que tu peux facilement utiliser d'autres implémentations en renvoyant une autre classe...
Par exemple (avec AnotherSingleton qui hérite de Singleton) :

Code :

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

1
2
3
4
5
6
7
8
9
10
public static Singleton getInstance() {
	if (instance==null) {
		if ( /* n'importe quel condition */ ) {
			instance = new AnotherSingleton();
		} else {
			instance = new Singleton();
		}
	}
	return instance;
}

Ce te permet de facilement changer l'implémentation de ton Singleton sans toucher au code... alors que si tu utilises des méthodes statiques il faudra modifier tout le code pour changer les appels de méthodes...

De plus le singleton est une classe normale, tu peux donc faire un traitement particulier dans le constructeur (comme lire des fichiers de configuration, etc...) et ainsi avoir des relations entre les méthodes... Alors que les méthodes statiques sont indépendantes...

a++

Salut adiGuba, une question dans ce cas d'utilisation du singleton, il ne faudrait pas mieux utiliser le pattern "Factory" ou encore "Abstract Factory" ??

Merci

[bouye]

La methode getInstance() d'une classe singleton peut tres bien etre vu comme un appel à une fabrique... et donc de là à l'étendre étendu à une frabriqe abstraitre il n'y a qu'un pas. C'est très rare que les patterns existent seuls* en général ils sont souvent composés entre eux.

* Le singleton tiré direct texto du bouquin peut très bien être utilisé aussi.
Il a des limitation mais est plus simple à coder après tout.

[adiGuba]

Salut adiGuba, une question dans ce cas d'utilisation du singleton, il ne faudrait pas mieux utiliser le pattern "Factory" ou encore "Abstract Factory" ??

Oui en effet c'est un mélange entre le pattern Factory et le pattern Singleton.

En fait je voulais montrer que le pattern Singleton pouvait évoluer plus facilement que si on utilisait que des méthodes statiques dans tout le code...

a++

[SEMPERE Benjamin]

Salut adiGuba, une question dans ce cas d'utilisation du singleton, il ne faudrait pas mieux utiliser le pattern "Factory" ou encore "Abstract Factory" ??

Oui en effet c'est un mélange entre le pattern Factory et le pattern Singleton.

En fait je voulais montrer que le pattern Singleton pouvait évoluer plus facilement que si on utilisait que des méthodes statiques dans tout le code...

a++

ok merci

[xavlours]

Bon, au risque que personne ne me lise (perso je ne vais jamais jusqu'au bout des thread-fleuves) je donne mes habitudes :

1° Je declare un attribut statique si toutes les instances le partagent (je prévois donc d'avoir plusieurs instances)

2° Je déclare une méthode statique si elle n'a besoin que de ses arguments, de constantes (normal) et d'attributs statiques déjà nécessaires pour le point 1°.

Si je veux plusieurs méthodes accessibles statiquement, qui ont besoin de variables communes, je fais un singleton. Ca rallonge un peu le code (souvent moins que des noms de methodes/attributs vraiment explicites), mais c'est plus facile à reprendre.

Je n'ai jamais recouru aux Factory, mais il y a des cas ou ca aurait été justifié. Concevoir ma factory comme un singleton alourdissait les appels et la relecture.

[dlemoing]

Moi j'utilise l'injection de dépendances avec Spring, je ne me pose pas ce genre de questions, mon code reste orienté objet et je garde toute la flexibilité dont j'ai besoin.
Le BeanFactory de Spring est une Factory qui peut me produire des singletons au même titre que des prototypes.