Switch Java - Maîtrisez-le pour un code plus clair et robuste

Le switch Java reste l’un des outils les plus efficaces quand une valeur unique doit orienter un traitement clair, sans transformer le code en chaîne de conditions. Dans les versions récentes du langage, il ne sert plus seulement à choisir entre quelques constantes: il peut aussi retourner une valeur, gérer `null` explicitement et travailler avec des patterns. Je vais donc aller droit au but: quand l’utiliser, comment l’écrire proprement, et où se cachent les erreurs qui surprennent encore trop de développeurs.

Quand le switch vaut mieux qu’un if/else

Je choisis un `switch` quand je lis une seule valeur et que je dois basculer entre un nombre limité d’issues. C’est typiquement le cas avec une `enum`, un code métier, une commande texte ou un mois de l’année. En revanche, dès qu’il faut tester des plages de valeurs, combiner plusieurs conditions indépendantes ou gérer une logique vraiment ouverte, `if/else` reste plus lisible.

Je tranche simple: si une seule variable suffit à décider, le `switch` est souvent le meilleur choix. Si la décision dépend d’un raisonnement plus riche, je reviens à une logique conditionnelle plus explicite. Cette distinction évite de forcer l’outil dans un rôle qu’il n’a pas, et elle prépare justement la bonne syntaxe pour la suite.

La syntaxe classique et la version moderne

Le `switch` classique repose sur des `case` suivis de `break`, alors que la forme moderne privilégie les flèches (`->`) et peut produire directement une valeur. La différence n’est pas cosmétique: elle change la manière dont le contrôle s’exécute, et elle réduit fortement les erreurs de `fall-through` involontaire.

int score = switch (day) {
    case MONDAY, FRIDAY -> 6;
    case WEDNESDAY -> {
        System.out.println("Milieu de semaine");
        yield 9;
    }
    default -> 0;
};

Dans ce type de code, `yield` joue le rôle précis de renvoyer la valeur du bloc vers l’expression `switch`. C’est ce point qui le différencie de `break`, lequel sert à sortir d’un `switch` statement classique. À mes yeux, c’est l’un des passages les plus utiles à maîtriser, parce qu’il rend le code plus sûr sans le rendre verbeux.

Les règles d’exhaustivité qui évitent les bugs silencieux

Un `switch` bien écrit ne laisse pas le hasard décider à sa place. Dans les expressions, et dans les `switch` qui utilisent des patterns ou `null`, le compilateur veut savoir que tous les chemins sont couverts. C’est une bonne chose: un cas manquant ne devient pas un bug discret qui se révèle trois semaines plus tard en production.

return switch (status) {
    case OPEN -> "Ouvert";
    case CLOSED -> "Fermé";
    default -> "Inconnu";
};

Quand les valeurs possibles ne sont pas entièrement couvertes, le compilateur refuse généralement le code. Sur une `enum`, si vous traitez toutes les constantes connues, le contrôle d’exhaustivité peut suffire sans `default`, mais je recommande de garder un fallback explicite dès que la source des données vient de l’extérieur: API, JSON, base de données ou file de messages. Dans ces cas-là, un `default` clair documente votre intention au lieu de la deviner.

Il faut aussi traiter `null` sans naïveté. Sans label dédié, un `switch` peut encore lever une `NullPointerException` si la valeur passée est nulle. Si l’absence de valeur est possible, je préfère l’annoncer franchement avec `case null -> ...` ou, selon le besoin, avec `case null, default -> ...`. Ce petit détail change beaucoup de choses quand l’entrée vient d’un système que je ne contrôle pas entièrement, et c’est justement ce qui nous amène aux patterns.

Les patterns, `when` et l’ordre des cas

Quand `when` simplifie vraiment le code

Le vrai saut qualitatif du `switch` moderne, c’est la possibilité de faire correspondre non seulement des constantes, mais aussi des types et des conditions supplémentaires. Le `when` sert précisément à ça: il ajoute une garde booléenne après un pattern. Je l’utilise quand le type donne la première décision, puis qu’un test métier affine le résultat.

static String describe(Object obj) {
    return switch (obj) {
        case String s when s.length() == 1 -> "Caractère isolé";
        case String s -> "Chaîne";
        case Integer i when i > 0 -> "Entier positif";
        case null -> "Valeur nulle";
        default -> "Autre";
    };
}

Ici, le type guide la première lecture, puis la garde `when` sépare les cas plus précis. C’est plus lisible qu’un empilement de `instanceof` et de blocs `if`, surtout quand la hiérarchie métier devient un peu riche. Si vous manipulez des objets issus de records ou de hiérarchies fermées, ce style peut vraiment alléger le code.

Pourquoi l’ordre des cas n’est pas un détail

Avec les patterns, l’ordre des `case` compte davantage qu’on ne le croit. En pratique, je classe les cas du plus précis au plus général pour éviter qu’un label trop large rende les suivants inatteignables. Un `case CharSequence` placé avant `case String` est un mauvais signal, parce que le second devient inutile.

• Constantes d’abord, quand il y en a.
• Gardes ensuite, si un `when` affine un type.
• Types larges en dernier, pour ne pas masquer les cas plus spécifiques.
• `default` seulement quand il a un vrai sens, pas comme réflexe décoratif.

Cette discipline est importante parce qu’elle rend le comportement prévisible pour le lecteur comme pour le compilateur. Dès qu’on a compris cet ordre logique, on peut passer à des usages très concrets, qui sont souvent la vraie raison d’adopter `switch` dans un projet.

Des exemples concrets à réutiliser dans un projet

Statuts et modes avec `enum`

Le cas le plus propre reste l’`enum` de statut ou de mode. Le domaine est fermé, le code est stable, et chaque branche est lisible en une ligne. C’est exactement le genre de situation où un `switch` apporte de la clarté sans coût cognitif.

enum EtatCommande { BROUILLON, PAYEE, EXPEDIEE, ANNULEE }

static String libelle(EtatCommande etat) {
    return switch (etat) {
        case BROUILLON -> "Brouillon";
        case PAYEE -> "Paiement validé";
        case EXPEDIEE -> "Expédiée";
        case ANNULEE -> "Annulée";
    };
}

Ce genre d’implémentation a un avantage très concret: si l’`enum` évolue, le compilateur vous force à revoir la logique au lieu de laisser un comportement incomplet passer inaperçu. C’est une sécurité utile, pas une contrainte esthétique.

Commandes texte et entrées utilisateur

Les chaînes fonctionnent aussi, mais je conseille presque toujours de normaliser l’entrée avant le `switch`. La comparaison reste sensible à la casse, donc un mot tapé par un utilisateur ou reçu d’une API mérite souvent un `trim()` et une conversion cohérente avant le traitement.

static String action(String commande) {
    if (commande == null) return "Commande absente";

    return switch (commande.trim().toLowerCase(Locale.ROOT)) {
        case "start" -> "Démarrage";
        case "stop" -> "Arrêt";
        case "status" -> "État";
        default -> "Commande inconnue";
    };
}

Je préfère cette approche à une série de `if` dispersés, parce qu’elle centralise la logique de décision. Le point d’attention, en revanche, est simple: si les entrées sont très hétérogènes, il faut traiter la normalisation avant le `switch`, pas à l’intérieur de chaque branche.

Lire aussi : PrintWriter en Java - Écrivez du texte sans pièges !

Hiérarchies d’objets et types métiers

Avec les versions récentes de Java, le `switch` devient aussi intéressant pour les hiérarchies d’objets, surtout quand elles sont fermées. Sur une hiérarchie `sealed`, le compilateur peut souvent vérifier que toutes les variantes sont couvertes, ce qui rend l’approche très robuste pour les domaines métiers bien modélisés.

sealed interface Shape permits Rectangle, Circle {}
record Rectangle(double length, double width) implements Shape {}
record Circle(double radius) implements Shape {}

static double perimeter(Shape shape) {
    return switch (shape) {
        case Rectangle r -> 2 * (r.length() + r.width());
        case Circle c -> 2 * Math.PI * c.radius();
    };
}

Ce type de code remplace proprement une cascade de `instanceof` suivie de cast manuels. J’aime particulièrement ce format quand le modèle de domaine est stable, parce qu’il rapproche la logique métier de sa représentation technique. Si l’arbre de types peut évoluer hors de votre module, gardez quand même un fallback explicite pour ne pas dépendre d’un contrat implicite trop fragile.

Les réflexes qui rendent un switch vraiment robuste

• Choisir `switch` pour un choix fermé, pas pour une logique de plage.
• Préférer `->` et `switch` expression dès qu’il faut produire une valeur.
• Ajouter `default` quand la source des données est externe ou évolutive.
• Traiter `null` explicitement si l’entrée peut être absente.
• Classer les cas du plus précis au plus général.
• Normaliser les chaînes avant le `switch` quand l’entrée vient d’un utilisateur ou d’une API.

En pratique, je regarde toujours une chose avant d’écrire le code: est-ce qu’une valeur unique suffit à décider? Si oui, le `switch` garde le code compact et lisible; sinon, je reviens à une logique conditionnelle plus explicite. C’est ce filtre simple qui fait la différence entre une instruction bien utilisée et un bloc qui devient difficile à maintenir au premier changement métier.