Initialisation de classe anonyme

Suite à l'excellent thread sur les techniques de programmation, j'aimerais avoir votre avis sur la technique d'initialisation de composant par le biais de classe anonyme...

je suis tombé sur ce lien qui présente les avantages et inconvénient de cette technique.
Étant débutant en java j'aimerais les conseils de pro , car cette syntaxe reste très peux utilisé , malgré qu'elle simplifie beaucoup l'écriture du code....

En gros ca donne ce genre de code

Code:

---

1 2 3 4 5

HashMap hMap = new HashMap(){{ add("jojo", "ok"); ..... }};

---

voilà !
a++

En fait, je ne vois pas ce qu'elle a de plus lisible, d'une part, et puis c'est une syntaxe relativement peu connue, d'autre part.

Je pense que ça suffit à expliquer pourquoi elle est peu utilisée. (Il y a aussi le fait qu'initialiser une Map avec un contenu, on n'a pas besoin de ça toutes les heures.)

Personnellement j'aime bien cette syntaxe dans de nombreux cas où elle me dispense de faire des blocs d'initialisation pleins de variables temporaires.

par principe, tous les initialisateur non-static doivent être limités. Typiquement, ça on peut:

Code:

---

1 2 3 4

class Foobar { static { /* init static fields*/ } }

---

ça c'est moins bien,,,

Code:

---

1 2 3 4

class Foobar { { /* init fields*/ } }

---

Là où ça commence à poser de vrais problèmes, c'est quand on commence à mélanger les constructeurs et les initialisateurs non-statiques, ça peut devenir difficile de prédire l'ordre d'exécution des différents trucs...

J'avais une recommandation à ce sujet dans le livre "Java Efficace" de Joshua Block... je vais essayer de la retrouver ce soir

@+

;)

Citation:

---

Envoyé par Pill_S

Là où ça commence à poser de vrais problèmes, c'est quand on commence à mélanger les constructeurs et les initialisateurs non-statiques, ça peut devenir difficile de prédire l'ordre d'exécution des différents trucs...

---

plus exactement: l'ordre est parfaitement défini mais c'est sûr qu'il faut faire attention.

1) le constructeur appelle d'abord le constructeur de la super-classe
2) ensuite les initialiseurs non-statiques dans l'ordre
3) ensuite le reste du code du constructeur

donc on peut facilement se mélanger les pinceaux avec des variables non initialisées (et si en plus on appelle des méthodes d'instance -non privées ou non final- dans le constructeur alors là c'est la cata :aie:)

merci pour vos réponse !!

thelvin
Comme vous le dites ca évite de passer par des variables locales temporaire, donc ont écrit moins de code donc plus lisible non? :aie:
Enfin c'est assez subjectif, ayant fait beaucoup de javascript, j'ai l'habitude de cette syntaxe (fonction anonyme en js, ou JSON) en arborescence.
Faut juste bien indenter sont code entre les différents bloc, sinon on peux vite se perdre avec les accolades et parenthèse....

Pill_S
Je savais pas que l'on pouvait dans une classe normale utiliser aussi les initialisateur que sont les accolades.
D'ailleurs j'ai du mal a saisir qu'est ce que ca apporte en plus dans une classe normale?

professeur shadoko
Mon IDE , netbeans , me met des avertissements quand "j'appelle des méthodes d'instance -non privées ou non final- dans le constructeur"
Pourriez vous me dire en quoi cela peux poser problème?

Sinon, est-ce que ca peux ralentir la VM, si on utilise trop cette technique, étant donné que cela augmente le nombre de fichiers compilés?

tchouss !

Citation:

---

Envoyé par kimjoa

Comme vous le dites ca évite de passer par des variables locales temporaire, donc ont écrit moins de code donc plus lisible non? :aie:

---

Il n'y a pas de solution ultime pour améliorer la lisibilité, en particulier éliminer autant de variables qu'on peut n'est pas la solution ultime.

Il faut mettre ça en balance avec ce qu'on fait pour.

Et la, on fait une syntaxe avec deux accolades qui se suivent, que peu de gens connaissent, et qui en pratique signifie "sous-classe avec constructeur par défaut, pas de redéfinition, et qui avant son constructeur appelle le code d'initialisation donné."
Discutable.

Citation:

---

Il n'y a pas de solution ultime pour améliorer la lisibilité, en particulier éliminer autant de variables qu'on peut n'est pas la solution ultime.

---

Je sais bien, après ca peux beaucoup diverger entre les personnes.
C'est comme le débat entre langage à indentation vs accolade...

Sinon outre le nombre de variable, cette structure a aussi le mérite de bien organiser le code, en combinant à la fois l'initialisation du composant et le rattachement à son parent, pratique pour les GUI.

Citation:

---

Et la, on fait une syntaxe avec deux accolades qui se suivent, que peu de gens connaissent

---

C'est sur, mais pour moi c'est pas vraiment un argument recevable. C'est pas comme si il devait utiliser un framework :mrgreen:
En 30 secondes sur google, et le développeur qui relie le code à la réponse sur cette signification.

Ça y est, je me souviens ce qui me dérange le plus dans cette syntaxe : toutes les variables qu'on met dedans doivent être final. C'est contraignant. Mais il y a plein de cas où ça ne l'est pas, donc bon...

Citation:

---

Envoyé par kimjoa

professeur shadoko
Mon IDE , netbeans , me met des avertissements quand "j'appelle des méthodes d'instance -non privées ou non final- dans le constructeur"
Pourriez vous me dire en quoi cela peux poser problème?

---

il faudrait des exemples un peu compliqués pour bien montrer des plantages potentiels ...

soit un code de constructeur dans lequel:
1) on appelle le constructeur de la super-classe
2) on execute les codes d'initialisation d'instance (blocs d'initialisation, affectation explicite d'une variable membre)
3) on execute du code

maintenant le constructeur de la super-classe s'execute et appelle une méthode d'instance ... si cette méthode est spécialisée dans la sous-classe c'est cette méthode qui sera appelée par le constructeur de la super-classe ... si cette méthode s'attend à des variables initialisées on est planté!
donc: prendre deux aspirines et reproduire artificiellement le bug :mouarf: pour s'en faire une idée ... d'où le tuyau: ne pas invoquer dans un constructeur une méthode qui soit "spécialisable" ... (donc il faut final, ou private).

Ok, ok !

Mais du coup ca me parait bizarre que au niveau de l'instanciation, une méthode peux être appliquer dynamiquement, polymorphique donc.

Ça paraitrai logique que tant que l'objet réelle de l'instance n'est pas initialisé, ses méthodes spécialisé ne soit pas accessible...

bref, vais suivre votre tuyaux ! ca évitera des prise de tète !!

merci pour cette réponse professeur shadoko !!