Discussion :

[GanYoshi]

Bonjour,

Je viens d'apprendre l'existence des blocs d'initialisation en java, les static et ceux d'instance, qui s'écrivent respectivement "static {}" et "{}".

Pour le bloc static d'initialisation je ne vois pas de conflit avec le constructeur, mais dans le bloc d'initialisation d'instance, je me demande 'comment définir si une action doit être réalisé dans le constructeur ou dans le bloc d'initialisation ?'

Le livre que je lit ne l'expliquant pas ^-^.

D'avance merci pour vos réponses

[Ricky81]

Un grand classique du SCJP, la séquence est la suivante :
1) Exécution partielle du constructeur appelé, jusqu'à l'appel (implicite ou non) du constructeur parent (super) inclu
2) Exécution séquentielle des blocs d'initialisation selon leur ordre d'apparition
3) Exécution de la suite du contenu du constructeur

N'hésites pas à faire un test pour t'en convaincre

[Uther]

J'aurais une question sur le même thème. Je n'ai pas de doute sur l'intérêt du bloc static, mais quel est l'intérêt du bloc d'initialisation, car j'ai du mal à voir ce que ça peut apporter dans la pratique en plus du constructeur.

[tchize_]

Le seul intérêt que je lui connaisse, c'est de pouvoir être entrelacé avec les déclarations de champs. Exemple:

Code :

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

1
2
3
4
5
6
7
 
private Map<String,String> champ1 = new HashMap<String,String>();
{
    champ1.put("clé","valeur");
    champ1.put("clé2","valeur2");
}
private int champ2 = champ1.size();

Alors que le code du constructeur est exécuté d'office après toutes les initialisations par défaut. Note qu'on peut avoir plus propre en mettant tout à null par défaut et en créant une méthode init() appelée par le constructeur.

Je crois que le bloc d'initialisation est surtout là pour raison de logique du language par rapport au bloc statique. En pratique, en 6 ans de java fulltime, je n'ai jamais eu besoin du bloc d'initialisation, alors que j'ai déjà eu besoin plusieurs fois du bloc d'initialisation statique.

[Uther]

Ok dans ce cas là, en effet ça peu servir mais çà reste plus lisible de tout faire dans le constructeur.

j'avais aussi vu une utilisation très particulière comme alternative au chainage :

Code :

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

1
2
3
4
MonObjet objet = new MonObjet();
objet.setProperty1(1);
objet.setProperty2(1);
objet.setProperty3(1);

en

Code :

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

1
2
3
4
5
MonObjet objet = new MonObjet(){{
    setProperty1(1);
    setProperty2(1);
    setProperty3(1);
}};

Mais là ça revient à détourner utiliser une structure de son réel but avec en plus une perte d'efficacité, vu qu'on se traine une création de classe anonyme.

[tchize_]

Mais là ça revient à détourner utiliser une structure de son réel but avec en plus une perte d'efficacité, vu qu'on se traine une création de classe anonyme.

A rajouter qu'une inner class anonyme rend d'office impossible l'existance de champs privés dans la classe englobante, seul moyen qu'a l'inner class d'avoir accès à tous les champs de l'outer class.