Bloc d'initialisation ou constructeur ?

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 :D

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 :wink:

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.

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

Code:

---

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.

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:

---

1 2 3 4

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

---

en

Code:

---

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.

Citation:

---

Envoyé par Uther

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.

Je ne connaissais pas le bloc d'initialisation... je trouve ça intéressant. Une des utilités que je lui vois est de permettre, dans le cas ou il y a plusieurs constructeurs, d'avoir un code qui sera executé par tous les constructeurs sans avoir besoin de créer une méthode du style

Code:

---

1 2	private void init() {}

---

ou d'appeler un des constructeurs en faisant un this() qui se charge d'initialiser les champs.

c'est à double tranchant. Avec une méthode appelée depuis le constructeur, en voyant les constructeur, tu vois ce qui se passe. Le bloc d'initialisation, lui, peut etre placé n'importe ou dans la classe, à des kilomètres des constructeur, çà aide pas à la lisibiltié du code.