Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){
if(myInstance==null){
myInstance = new DAOODBCFactory();
}
return myInstance;
}
Je vois pas bien l'utilité de mettre le constructeur en privé et de
créer une méthode public pour obtenir une instance.
A première vue, je pensais que cela éviter d'instancier plusieurs fois
le même objet, mais je n'en suis pas sur.
devoo wrote: Bonjour, Il s'agit en fait d'une astuce qui permet de garantir que la classe ne pourra pas être instancié par : new MyClass () tout en autorisant l'instanciation par MyClass mc = MyClass.getInstance ()
Pour simplifier, un constructeur privé indique soit une classe qui ne peut pas être instancié par construction directe soit une classe qui ne peut tout simplement pas être instancié (classe utilitaire contenant uniquement des méthodes statiques).
devoo wrote:
Bonjour,
Il s'agit en fait d'une astuce qui permet de garantir que la classe ne
pourra pas être instancié par :
new MyClass () tout en autorisant l'instanciation par
MyClass mc = MyClass.getInstance ()
Pour simplifier, un constructeur privé indique soit une classe qui ne
peut pas être instancié par construction directe soit une classe qui ne
peut tout simplement pas être instancié (classe utilitaire contenant
uniquement des méthodes statiques).
devoo wrote: Bonjour, Il s'agit en fait d'une astuce qui permet de garantir que la classe ne pourra pas être instancié par : new MyClass () tout en autorisant l'instanciation par MyClass mc = MyClass.getInstance ()
Pour simplifier, un constructeur privé indique soit une classe qui ne peut pas être instancié par construction directe soit une classe qui ne peut tout simplement pas être instancié (classe utilitaire contenant uniquement des méthodes statiques).
pierre
Cela s'apelle le pattern du singleton Tu as raison, il permet de n'avoir qu'une seule instance ne mémoire. Tu trouveras une nombreuse litterature sur le net. Dans ton code il faut ajouter synchronized sur getInstance pour être sur que deux threads ne créent pas une instance en même temps. Il permet de remplacer une classe statique avec l'avantage que le singleton peut impléméenter une interface et donc avoir plusieurs implémentations.
Pierre.
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Cela s'apelle le pattern du singleton
Tu as raison, il permet de n'avoir qu'une seule instance ne mémoire.
Tu trouveras une nombreuse litterature sur le net.
Dans ton code il faut ajouter synchronized sur getInstance pour être sur
que deux threads ne créent pas une instance en même temps.
Il permet de remplacer une classe statique avec l'avantage que le
singleton peut impléméenter une interface et donc avoir plusieurs
implémentations.
Pierre.
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){
if(myInstance==null){
myInstance = new DAOODBCFactory();
}
return myInstance;
}
Je vois pas bien l'utilité de mettre le constructeur en privé et de
créer une méthode public pour obtenir une instance.
A première vue, je pensais que cela éviter d'instancier plusieurs fois
le même objet, mais je n'en suis pas sur.
Cela s'apelle le pattern du singleton Tu as raison, il permet de n'avoir qu'une seule instance ne mémoire. Tu trouveras une nombreuse litterature sur le net. Dans ton code il faut ajouter synchronized sur getInstance pour être sur que deux threads ne créent pas une instance en même temps. Il permet de remplacer une classe statique avec l'avantage que le singleton peut impléméenter une interface et donc avoir plusieurs implémentations.
Pierre.
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
xav
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Ca permet de n'avoir qu'une seule instance de ta classe. On retrouve cette structure dans plusieurs classe de l'API.
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){
if(myInstance==null){
myInstance = new DAOODBCFactory();
}
return myInstance;
}
Je vois pas bien l'utilité de mettre le constructeur en privé et de
créer une méthode public pour obtenir une instance.
A première vue, je pensais que cela éviter d'instancier plusieurs fois
le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Ca permet de n'avoir qu'une seule instance de ta classe. On retrouve
cette structure dans plusieurs classe de l'API.
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Ca permet de n'avoir qu'une seule instance de ta classe. On retrouve cette structure dans plusieurs classe de l'API.
ownowl
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Patern Singleton
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){
if(myInstance==null){
myInstance = new DAOODBCFactory();
}
return myInstance;
}
Je vois pas bien l'utilité de mettre le constructeur en privé et de
créer une méthode public pour obtenir une instance.
A première vue, je pensais que cela éviter d'instancier plusieurs fois
le même objet, mais je n'en suis pas sur.
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Patern Singleton
wolverin
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Patern Singleton Pourquoi ne pas utiliser une variable statique avec si besoin une init
par bloc statique au lieu du pattern singleton parfois problématique dès qu'on est en multithread ?
devoo wrote:
Bonjour à tous,
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){
if(myInstance==null){
myInstance = new DAOODBCFactory();
}
return myInstance;
}
Je vois pas bien l'utilité de mettre le constructeur en privé et de
créer une méthode public pour obtenir une instance.
A première vue, je pensais que cela éviter d'instancier plusieurs fois
le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Patern Singleton
Pourquoi ne pas utiliser une variable statique avec si besoin une init
par bloc statique au lieu du pattern singleton parfois problématique dès
qu'on est en multithread ?
Voila, en lisant des bouts de code, je suis tombé sur cela :
private myClass(){}
public static myClass getInstance(){ if(myInstance==null){ myInstance = new DAOODBCFactory(); } return myInstance; }
Je vois pas bien l'utilité de mettre le constructeur en privé et de créer une méthode public pour obtenir une instance. A première vue, je pensais que cela éviter d'instancier plusieurs fois le même objet, mais je n'en suis pas sur.
Si vous pouviez m'elcairer.
D'avance merci.
Patern Singleton Pourquoi ne pas utiliser une variable statique avec si besoin une init
par bloc statique au lieu du pattern singleton parfois problématique dès qu'on est en multithread ?
cho7
"wolverin" a écrit dans le message de news: 428a3f22$0$22836$
Pourquoi ne pas utiliser une variable statique avec si besoin une init par bloc statique au lieu du pattern singleton parfois problématique dès qu'on est en multithread ?
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
"wolverin" <serval2412nospam@yahoo.fr> a écrit dans le message de news:
428a3f22$0$22836$626a14ce@news.free.fr...
Pourquoi ne pas utiliser une variable statique avec si besoin une init
par bloc statique au lieu du pattern singleton parfois problématique dès
qu'on est en multithread ?
Personellement, de voir qu'un constructeur est privé, ca me fait tout de
suite percuter et je sais que je ne pourrai probablement pas instancier
plusieurs instance de la classe.
Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je
vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre
compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le
voulais !
Le singleton est donc plus formel pour moi, avec lui je sais à quoi
m'attendre...
"wolverin" a écrit dans le message de news: 428a3f22$0$22836$
Pourquoi ne pas utiliser une variable statique avec si besoin une init par bloc statique au lieu du pattern singleton parfois problématique dès qu'on est en multithread ?
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
Stephane Zuckerman
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Personellement, de voir qu'un constructeur est privé, ca me fait tout de
suite percuter et je sais que je ne pourrai probablement pas instancier
plusieurs instance de la classe.
Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je
vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre
compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le
voulais !
Le singleton est donc plus formel pour moi, avec lui je sais à quoi
m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait
d'utiliser le pattern singleton n'était que ça : un modèle ... Et
qu'ensuite, qu'on l'implémente à grands coups de static ou bien de
constructeurs privés, je ne vois pas trop ce que ça change ...
D'un point de vue multithread, le fait d'être en static ne change pas
grand chose de ce que j'ai vu ...
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Kupee
Stephane Zuckerman wrote:
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Stephane Zuckerman wrote:
Personellement, de voir qu'un constructeur est privé, ca me fait tout de
suite percuter et je sais que je ne pourrai probablement pas instancier
plusieurs instance de la classe.
Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je
vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre
compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le
voulais !
Le singleton est donc plus formel pour moi, avec lui je sais à quoi
m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait
d'utiliser le pattern singleton n'était que ça : un modèle ... Et
qu'ensuite, qu'on l'implémente à grands coups de static ou bien de
constructeurs privés, je ne vois pas trop ce que ça change ...
D'un point de vue multithread, le fait d'être en static ne change pas
grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors
que la méthode getInstance a moins d'etre synchronisée ne garantie pas
qu'on va instantier qu'une fois le singleton en multithread
Personellement, de voir qu'un constructeur est privé, ca me fait tout de suite percuter et je sais que je ne pourrai probablement pas instancier plusieurs instance de la classe. Avec ta méthode, je vais d'abord instancier un objet, puis un 2ème (enfin je vais essayer), et je vais avoir des résultats étranges, pour enfin me rendre compte que c'est dû au fait mon 2ème objet n'a pas été instancié comme je le voulais ! Le singleton est donc plus formel pour moi, avec lui je sais à quoi m'attendre...
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Stephane Zuckerman
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire quelque chose pour arranger ça).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait
d'utiliser le pattern singleton n'était que ça : un modèle ... Et
qu'ensuite, qu'on l'implémente à grands coups de static ou bien de
constructeurs privés, je ne vois pas trop ce que ça change ...
D'un point de vue multithread, le fait d'être en static ne change pas
grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors
que la méthode getInstance a moins d'etre synchronisée ne garantie pas
qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu
fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au
final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les
appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire
quelque chose pour arranger ça).
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire quelque chose pour arranger ça).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Kupee
Stephane Zuckerman wrote:
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire quelque chose pour arranger ça).
Oui, s'arranger pour qu'il soit instantié a un moment ou on est sur que c'est pas dangereux et après une simple méthode get qui ne teste rien. Si on appelle souvent le singleton, ca peut compter coté performances je pense.
Stephane Zuckerman wrote:
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait
d'utiliser le pattern singleton n'était que ça : un modèle ... Et
qu'ensuite, qu'on l'implémente à grands coups de static ou bien de
constructeurs privés, je ne vois pas trop ce que ça change ...
D'un point de vue multithread, le fait d'être en static ne change pas
grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors
que la méthode getInstance a moins d'etre synchronisée ne garantie pas
qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu
fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au
final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les
appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire
quelque chose pour arranger ça).
Oui, s'arranger pour qu'il soit instantié a un moment ou on est sur que
c'est pas dangereux et après une simple méthode get qui ne teste rien.
Si on appelle souvent le singleton, ca peut compter coté performances je
pense.
Euh, je me trompe sans doute, mais j'avais cru comprendre que le fait d'utiliser le pattern singleton n'était que ça : un modèle ... Et qu'ensuite, qu'on l'implémente à grands coups de static ou bien de constructeurs privés, je ne vois pas trop ce que ça change ... D'un point de vue multithread, le fait d'être en static ne change pas grand chose de ce que j'ai vu ...
Euh ben le bloc static ne sera exécuté qu'une fois a priori non ? Alors que la méthode getInstance a moins d'etre synchronisée ne garantie pas qu'on va instantier qu'une fois le singleton en multithread
Oui, mais à ce moment-là, si tu veux être thread-safe, effectivement, tu fais tout pour ... et entre autres tu utilises synchronized. :-) Donc au final, ça revient au même :-) (oui bon non, du coup on "séquencialise" les appels à getInstance() ... Enfin là encore, je suis sûr qu'on peut faire quelque chose pour arranger ça).
Oui, s'arranger pour qu'il soit instantié a un moment ou on est sur que c'est pas dangereux et après une simple méthode get qui ne teste rien. Si on appelle souvent le singleton, ca peut compter coté performances je pense.
