Blocs d’initialisation

1. Que sont les blocs d’initialisation

En Java, il existe deux types de blocs d’initialisation :

• Blocs d’initialisation non statiques (ordinaires) — s’exécutent à chaque création d’un nouvel objet, immédiatement après l’initialisation des champs et avant l’appel du constructeur.
• Blocs d’initialisation statiques — s’exécutent une seule fois lors du chargement de la classe en mémoire (avant la création du premier objet ou l’accès aux champs/méthodes statiques).

Bloc d’initialisation non statique

Il se déclare directement dans le corps de la classe, sans mot-clé comme static :

public class User {
    private String name;

    // Bloc d’initialisation non statique
    {
        System.out.println("Le bloc non statique s’exécute !");
        name = "Nom par défaut";
    }

    public User() {
        System.out.println("Le constructeur s’exécute !");
    }
}

Bloc d’initialisation statique

Il se déclare avec le mot-clé static :

public class Config {
    public static String appName;

    static {
        System.out.println("Le bloc statique s’exécute !");
        appName = "Mon super-application";
    }
}

2. Ordre d’initialisation : qui est le patron ?

En Java, l’ordre d’initialisation des éléments d’une classe n’est pas « au hasard », mais une séquence strictement définie. Si vous avez déjà essayé de monter un meuble IKEA sans notice, vous comprenez pourquoi cet ordre est important : si vous inversez des étapes, vous obtenez une œuvre d’art au lieu d’une armoire.

Ordre d’initialisation :

1. Champs statiques et blocs statiques — dans l’ordre de leur déclaration dans la classe. S’exécutent une seule fois lors du chargement de la classe.
2. Champs non statiques et blocs non statiques — dans l’ordre de leur déclaration, à chaque création d’un nouvel objet.
3. Constructeur — s’exécute après toutes les initialisations non statiques.

Schématiquement

+-------------------------------+
|   Chargement de la classe     |
|   dans la JVM                 |
+-------------------------------+
| 1. Champs statiques           |
| 2. Blocs statiques            |
|         ↓                     |
|   Création de l’objet         |
|         ↓                     |
| 3. Champs non statiques       |
| 4. Blocs non statiques        |
| 5. Constructeur               |
+-------------------------------+

Exemple avec sortie

Écrivons une classe qui nous montrera dans quel ordre tout se passe :

public class Demo {
    static String staticField = print("1. champ static");

    static {
        print("2. bloc static");
    }

    String field = print("3. champ non statique");

    {
        print("4. bloc non statique");
    }

    public Demo() {
        print("5. constructeur");
    }

    static String print(String msg) {
        System.out.println(msg);
        return msg;
    }

    public static void main(String[] args) {
        System.out.println("Créons le premier objet Demo:");
        Demo d1 = new Demo();

        System.out.println("\nCréons le deuxième objet Demo:");
        Demo d2 = new Demo();
    }
}

Que s’affichera à l’écran ?

1. champ static
2. bloc static
Créons le premier objet Demo:
3. champ non statique
4. bloc non statique
5. constructeur

Créons le deuxième objet Demo:
3. champ non statique
4. bloc non statique
5. constructeur

À noter : les parties statiques (static) ne s’exécutent qu’une seule fois — lors du premier accès à la classe. Tout ce qui n’est pas static s’exécute à chaque création d’objet.

3. Exemples de code : à quoi servent les blocs d’initialisation

Quand un constructeur ne suffit pas

Parfois, une partie de l’initialisation doit être commune à tous les constructeurs. Par exemple, si une classe a plusieurs constructeurs et que vous ne voulez pas dupliquer la même initialisation dans chacun. Dans ce cas, il est pratique de la placer dans un bloc non statique :

public class Person {
    private String id;
    private String name;

    {
        // Ce code s’exécute avant n’importe quel constructeur
        id = java.util.UUID.randomUUID().toString();
        System.out.println("Génération d’un id unique: " + id);
    }

    public Person() {
        System.out.println("Person() sans paramètres");
    }

    public Person(String name) {
        this.name = name;
        System.out.println("Person(String name)");
    }
}

Résultat : lors de la création de tout objet Person, l’id est d’abord généré, puis le constructeur approprié s’exécute.

Initialisation de données statiques complexes

On utilise souvent un bloc statique pour initialiser des champs statiques « lourds » ou complexes, par exemple la lecture d’une configuration depuis un fichier, la création de collections, la connexion à une base de données, etc.

public class Settings {
    public static final java.util.Map<String, String> DEFAULTS;

    static {
        DEFAULTS = new java.util.HashMap<>();
        DEFAULTS.put("theme", "light");
        DEFAULTS.put("language", "ru");
        System.out.println("Bloc statique de Settings: paramètres par défaut");
    }
}

4. Points utiles

Quand utiliser les blocs d’initialisation

Quand il faut les utiliser

• Pour une initialisation commune nécessaire dans tous les constructeurs.
• Pour des données statiques complexes qui ne peuvent pas être exprimées par une simple affectation.
• Pour l’initialisation de ressources statiques (par exemple, lecture d’un fichier de configuration au démarrage de l’application).

Quand il NE faut pas les utiliser

• Si une simple affectation ou un constructeur suffit — utilisez-les.
• Évitez de « cacher » la logique métier dans des blocs d’initialisation — cela complique la lecture et la maintenance du code.
• Si l’initialisation dépend des paramètres du constructeur, utilisez le constructeur lui-même.

N’abusez pas des blocs d’initialisation

Les blocs d’initialisation sont un outil puissant, mais pas le plus utilisé. Dans la plupart des cas, une simple affectation ou un constructeur suffit. S’il y a trop de blocs d’initialisation dans une classe, le code devient illisible et difficile à maintenir.

N’utilisez pas un bloc non statique pour une logique dépendant des paramètres du constructeur

Dans un bloc non statique, vous ne pouvez pas utiliser les paramètres du constructeur, car il s’exécute AVANT le constructeur. Si vous devez initialiser quelque chose en fonction des paramètres, faites-le dans le constructeur lui-même.

Blocs statiques et héritage

Les blocs d’initialisation statiques ne sont pas hérités. Chaque classe possède son propre bloc statique. Lors du chargement d’une classe dérivée, le bloc statique de la classe de base s’exécute d’abord, puis celui de la classe dérivée.

5. Erreurs courantes avec les blocs d’initialisation

Erreur n° 1 : penser qu’un bloc non statique voit les paramètres du constructeur.
Beaucoup de débutants essaient d’utiliser les paramètres du constructeur dans un bloc non statique, mais obtiennent une erreur de compilation ou un résultat inattendu. Rappelez-vous : un bloc non statique s’exécute AVANT le constructeur, donc il n’y a pas encore de paramètres.

Erreur n° 2 : trop de logique dans les blocs d’initialisation.
Si la logique devient complexe dans les blocs d’initialisation, le code se brouille. Il vaut mieux faire le travail principal dans le constructeur ou dans des méthodes séparées.

Erreur n° 3 : plusieurs blocs statiques avec des ordres différents.
Si une classe contient plusieurs blocs statiques, ils s’exécutent dans l’ordre où ils sont déclarés dans le code, avec les champs statiques. Cela peut mener à des résultats inattendus si, par exemple, un bloc dépend du résultat d’un autre.

Erreur n° 4 : penser qu’un static-bloc s’exécute à chaque création d’objet.
Un static-bloc s’exécute une seule fois — lors du chargement de la classe. Si vous comptez sur une réinitialisation, cela n’arrivera pas.

Erreur n° 5 : tenter d’accéder à des champs non statiques depuis un bloc statique.
Dans un bloc statique, seules les variables et méthodes statiques sont accessibles. Tenter d’accéder à des champs (ordinaires) non statiques provoquera une erreur de compilation.