Initialisation de bloc vs Constructeur

Allons-y, puisque "Initialisation de bloc" ne rapporte rien via les outils "Recherche dans les forums" et "Recherche dans les projets".

Dans une classe en Java, il est possible de déclarer un bloc (entre '{ }'), seulement précédé du mot réservé 'static'. Un tel bloc peut contenir du code qui n'est exécuté une seule fois, en cas de bloc 'static', lorsque la classe est chargée, c à d avant que l'objet de cette classe soit créé.
Ce fonctionnement me semble très proche de celui d'un constructeur de la classe, hormis que celui-ci n'est exécuté que lorsque la classe est instanciée.
Un esprit bien éclairé pourrait-il me dire quand une initialisation de bloc (statique ou dynamique) et/ou un constructeur s'avèrent le plus opportun à mettre oeuvre ? Avec des cas pratiques en illustrant la pertinence ...

A quels moments distincts, en fait, se passe le 'class loading' si ce n'est juste avant l'instanciation de la classe ?

J'ai posé la question ce matin sur Sun Forums > Java Essentials > Java Programming > Initialization block vs constructor
Mais les réponses obtenues "dépassent de trop ma modeste casquette".

Grand merci d'avance.

Pour ce qui est de savoir comment et pourquoi une classe est chargée et initialisée, je ne vais pas te faire un exposé complet avec exemples ; cela dépasse largement mes compétences, et il s'agit de notions qu'un programmeur moyen utilise sans forcément savoir comment ça fonctionne exactement.

De plus, en ces domaines on ne doit pas se baser sur la façon dont ça fonctionne, mais seulement sur le service rendu. Ainsi, la seule chose dont tu sois sûre est que lorsque l'exécution passe sur un code utilisant une classe, alors cette classe est disponible. C'est une sorte de miracle.

Quand vaut-il mieux utiliser static{}, ou {}, ou un constructeur ? Perso je n'utilise jamais {}, peut être est-ce une erreur. Entre static{} et constructeur le choix est simple puisque d'un coté c'est l'init de classe, de l'autre la construction d'instance.

L'usage de java est plus souple sur les instances, si j'ai un conseil à donner c'est de plutôt travailler sur des instances ; en plus de mon coté j'utilise de moins en moins les inits statiques depuis qu'il y a les énumérations, sauf au lancement d'une appli (tout ce qui est dans la fonction main, qui finalement peut être assez développé).

Je ne sais si ça répond à tes interrogations ? Sinon, précises les.

les static {} sont assez utiles, comme tu l'a dit, comme "constructeur de classe". Perso je m'en sert pour initialiser mes champs statique dans des classes qui sont généralement purement utilitaires et donc ne contiennent que des méthodes statiques. En général j'essaie d'initialiser les champs directement dans leur déclaration. Mais les map, par exemple, c'est impossible sans du code. La t'as deux possibilités

soit

Code:

---

1 2 3 4 5

static Map m = new HashMap(); { m.put(x,y); p.put(a,b); }

---

soit

Code:

---

1 2 3 4 5 6 7

static Map m = initM(); static private Map intiM(){ Map result = new HashMap(); result.put(x,y); result.put(a,b); return result; }

---

pour ce qui est des bloc non static, je les utilise pour le "constructeur" des inner class anonyme occasionellement (mais très très rarement)

Et pour ce qui est du moment de l'initialisation de la classe, la classe est initialisé lorsque le classloader se vois demandé la classe pour la première fois. Et il y a plein de raisons qui peuvent en être à l'origine.

Code:

---

1 2 3 4 5 6

static Map m = new HashMap(); { m.put(x,y); p.put(a,b); }

---

En utilisant les doubles accolades, tu peux réduire ça à :

Code:

---

1 2 3 4 5

static Map m = new HashMap(){{ put(x,y); put(a,b); }};

---

Le bloc contenu entre { ... } est copié dans chaque constructeur. C'est utile lorsqu'il s'agit d'initialiser l'état d'un objet quelque soit le constructeur appelé, et ce de la même manière à chaque fois.

Cette initialisation permettrait de se passer d'appels explicite à this() par exemple (que je ne savais pas sans ton post sur sun forums, merci)

Lien intéressant : http://java.sun.com/docs/books/tutor...O/initial.html

Citation:

---

Envoyé par ipingu

En utilisant les doubles accolades, tu peux réduire ça à :

Code:

---

1 2 3 4 5

static Map m = new HashMap(){{ put(x,y); put(a,b); }};

---

---

Cette méthode a un inconvénient, si tu commence à multiplier son utilisation. Elle crée une anonymous Inner class statique, ce qui signifie des entrées supplémentaire dans dans le class loader. Alors c'est pas trop un gros problème si tu n'as que 10 fois ça dans ton code, mais si tu commence à systématiser sont utilisation pour toutes les List / Map, voire carrément à le faire aussi pour les champs non statique afin de "rendre le code plus clair", tu va vite finir avec 4 fois plus de classes que t'en a réellement besoin ;)

Citation:

---

Le bloc contenu entre { ... } est copié dans chaque constructeur. C'est utile lorsqu'il s'agit d'initialiser l'état d'un objet quelque soit le constructeur appelé, et ce de la même manière à chaque fois.

---

Précisons qu'il est copié au début du constructeur, mais après l'appel à super.

Citation:

---

Précisons qu'il est copié au début du constructeur, mais après l'appel à super.

---

Merci pour l'info, ça manquait de précision sur la page Sun.

Et effectivement, la méthode que j'ai proposé n'est pas à utiliser abusivement pour les raisons que tu as cité.

Pour répondre à la question initiale complètement :

Il y a deux concepts différents : l'initialisation d'une classe et l'initialisation d'une instance.

L'initialisation d'une classe se fait (entre autres) lorsque tu utilises des constantes : c'est le moment où les constantes sont effectivement créées, au premier appel de la classe, bien avant le constructeur. Le code encadré dans un "static {}" est également exécuté.

Ensuite, une fois la classe chargée et initialisée, on peut créer des instances de celles-ci. Dans lequel cas, une autre initialisation intervient. C'est le constructeur. Le constructeur est assez complexe car, comme tu le dis, il y a l'initialisation de la classe mère, l'initialisation des blocs et enfin du code du constructeur. Les blocs sont exécutés dans l'ordre dans lequel ils sont définis. Voici un exemple d'initialisation qui montre cela (les nombres indiquent l'ordre d'exécution des instructions) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

abstract class MaClasseAbstraite { protected MaClasseAbstraite () { System.out.println("Bloc dans le constructeur de la classe parente"); } }   public class MaClasse extends MaClasseAbstraite { { System.out.println("Bloc précédant le constructeur"); // 2 } public MaClasse () { super(); // 1 System.out.println("Bloc dans le constructeur"); // 4 } { System.out.println("Bloc suivant le constructeur"); // 3 } }

---

Quand on créera un nouveau MaClasse, on obtiendra le résultat suivant

Code:

---

1 2 3 4

Bloc dans le constructeur de la classe parente Bloc précédent le constructeur Bloc suivant le constructeur Bloc dans le constructeur

---

Je pense que les précédentes explications concernant les bloques statiques sont plutôt clair et ne méritent pas d'explications supplémentaires.

Aussi je vais répondre a une autre partie de la question : pourquoi utiliser des bloque d'initialisation au lieu de constructeur ?

En fait, le code présent dans ces bloques d'initialisation sont du code qui sera appelé quelque soit le constructeur appelé. Une pratique courante est d'avoir un constructeur par défaut qui initialise tout et qui sera déclenché explicitement dans les autres constructeur au travers de l'instruction this().
Cependant on peut faire abstraction de ceci en définissant la partie commune à tout les constructeurs grâce aux bloques d'initialisation.

Dans la pratique, on passe souvent par des appels de constructeur.

Objectif bien éclairé et réponses bien utiles.
Grand merci à tous.