Héritage, interfaces et polymorphisme en Java

L’héritage crée une sous-classe à partir d’une superclasse existante. Dans class Student extends Person, tout étudiant est une personne. Un objet étudiant réunit son état de personne et son état supplémentaire d’étudiant dans un seul objet.

Ajoute les éléments propres à l’étudiant

Voici une petite superclasse et une sous-classe :

class Person {
    private String name;
    public Person(String name) { this.name = name; }
    public String getName() { return name; }
}

class Student extends Person {
    private int credits;
    public Student(String name) { super(name); }
    public void study() { credits += 5; }
    public int getCredits() { return credits; }
}

Student hérite de getName(). Elle ajoute un champ de crédits et deux méthodes. Après Student s = new Student("Ada Lovelace");, le champ de crédits vaut initialement 0. Deux appels à s.study() le portent d’abord à 5, puis à 10. s.getName() renvoie toujours « Ada Lovelace » : la méthode héritée lit le champ privé déclaré dans Person.

L’instruction super(name) transmet le nom au constructeur de Person. Les constructeurs ne sont pas hérités, donc Student déclare son propre constructeur. Une sous-classe peut ajouter des méthodes et redéfinir un comportement hérité, mais elle ne peut pas supprimer une méthode publique héritée de son interface de programmation publique.

Identifie les membres accessibles

Les membres privés ne sont pas hérités. Le champ privé name existe toujours dans chaque étudiant, mais Student ne peut pas le lire directement. Garder le champ privé et fournir un accesseur permet à Person de contrôler ses propres données. Entre paquetages, l’accès à un membre d’instance protected comporte une restriction supplémentaire : le code d’une sous-classe accède au membre par lui-même ou par une référence du type de sa propre sous-classe, et non par une référence quelconque à la superclasse.

Teste la relation avant d’étendre une classe

Java autorise une superclasse directe par classe. Une chaîne telle que GraduateStudent extends Student et Student extends Person est valide ; extends Student, Teacher ne l’est pas. Une classe sans superclasse explicite étend Object. Object elle-même n’a pas de superclasse.

Utilise le test « est un » : tout objet de la sous-classe peut-il être utilisé partout où une instance de la superclasse est attendue ? Un camion est un véhicule. Un client possède une adresse, mais un client n’est pas une adresse. Pour cette seconde relation, utilise la composition :

class Customer {
    private Address address;
}

Ici, Address est une autre classe. Le champ permet à un client d’utiliser une adresse sans prétendre en être une. Étendre une classe pour simplement emprunter une méthode pratique revient aussi à hériter de tout son contrat public. Enfin, une classe final ne peut pas être étendue. Comme String est finale, class ShortString extends String ne compile pas.

Un constructeur de sous-classe doit assurer la construction de la partie correspondant à la superclasse dans le même objet. Il peut appeler un constructeur de la superclasse avec super(...) ou déléguer à un autre constructeur de sa propre classe avec this(...).

Choisis le constructeur de la superclasse

class Person {
    private final String name;
    Person(String name) { this.name = name; }
}
class Student extends Person {
    private final String studentId;
    Student(String name, String studentId) {
        super(name);
        this.studentId = studentId;
    }
    Student(String name) {
        this(name, "no id yet");
    }
}

Le constructeur à deux arguments transmet le nom à Person et stocke lui-même l’identifiant. Le constructeur à un argument lui délègue cette tâche. Un constructeur contient au plus un appel explicite de constructeur : this(...) ou super(...). En suivant la chaîne de this(...), on atteint finalement un constructeur qui appelle super(...).

Si aucun des deux n’est écrit, Java insère super(). Cet appel échoue ici, car Person ne possède qu’un constructeur exigeant un nom. Dès qu’un constructeur est déclaré, Java ne fournit pas de constructeur par défaut sans argument. Une classe sans constructeur déclaré reçoit un constructeur par défaut qui appelle super().

Écrire new Person(name) dans Student produit autre chose : cela construit un objet distinct. Cette instruction n’initialise pas l’état de personne de l’étudiant courant et ne remplace pas l’appel obligatoire au constructeur de la superclasse.

Suis l’ordre de l’initialisation

class Base {
    Base() { System.out.println("Base ready"); }
}
class Middle extends Base {
    Middle() { System.out.println("Middle ready"); }
}
class Top extends Middle {
    Top() { super(); System.out.println("Top ready"); }
}

new Top() remonte la chaîne de constructeurs jusqu’à Object. Au retour des appels, la sortie est « Base ready », « Middle ready », puis « Top ready ». Les initialiseurs de champs de chaque classe s’exécutent après le retour du constructeur de sa superclasse et avant le reste du corps de son constructeur.

Une méthode redéfinissable appelée par un constructeur de superclasse peut déjà exécuter une version redéfinie dans une sous-classe. Si cette version lit un champ de type référence de la sous-classe avant que sa valeur lui soit affectée, elle voit null, même si le champ possède un initialiseur dans sa déclaration. Limite le travail du constructeur à l’initialisation de l’état ; évite les appels aux méthodes que les sous-classes peuvent redéfinir.

Reconnais le changement apporté par Java 25

En Java 25, un constructeur peut valider des paramètres avant son appel explicite de constructeur :

Student(String name, String studentId, int credits) {
    if (credits < 0) {
        throw new IllegalArgumentException("negative credits");
    }
    super(name);
    this.studentId = studentId;
}

Java 25 autorise aussi, avant l’appel, des affectations simples à des champs déclarés dans la classe courante sans initialiseur dans leur déclaration. Il reste interdit de lire les champs de l’objet courant, d’appeler ses méthodes d’instance ou de transmettre this avant l’appel. Pour les versions standard du langage antérieures à Java 25, garde super(...) ou this(...) en première position. Java 22 à 24 proposaient des formes antérieures en aperçu.

Une redéfinition donne à une sous-classe sa propre implémentation d’une méthode d’instance héritée. Son nom et ses types de paramètres correspondent à ceux de la méthode initiale, de sorte que les appelants peuvent continuer à utiliser la même opération.

Étends une méthode fonctionnelle

Supposons que la rémunération annuelle d’un salarié corresponde à douze mensualités. Un responsable reçoit aussi une prime annuelle :

class Employee {
    private final double monthlySalary;
    Employee(double monthlySalary) {
        this.monthlySalary = monthlySalary;
    }
    public double yearlyPay() { return 12 * monthlySalary; }
}
class Manager extends Employee {
    private final double bonus;
    Manager(double monthlySalary, double bonus) {
        super(monthlySalary);
        this.bonus = bonus;
    }
    @Override
    public double yearlyPay() {
        return super.yearlyPay() + bonus;
    }
}

Pour new Manager(3000.0, 5000.0), l’appel à la superclasse renvoie 36 000,0. L’ajout de 5 000,0 donne 41 000,0. super.yearlyPay() sélectionne délibérément l’implémentation de la superclasse. La méthode de la superclasse reste accessible dans la sous-classe, même si les appels ordinaires sur le responsable exécutent la version redéfinie.

Écrire return yearlyPay() + bonus; appelle à nouveau la méthode du responsable elle-même. Aucun appel ne se termine, si bien que l’exécution finit par échouer avec StackOverflowError. L’absence de super. change le sens de l’appel.

Laisse le compilateur vérifier la signature

Place @Override au-dessus de chaque méthode qui en redéfinit une autre. Une faute d’orthographe comme yearlypay() ou un paramètre supplémentaire provoque alors une erreur de compilation. Sans l’annotation, Java peut accepter une nouvelle méthode que les appelants n’utilisent jamais.

Une redéfinition valide suit ces règles :

• Ses types de paramètres correspondent exactement.
• Son type de retour est identique ou, pour un retour de type objet, est un sous-type du type initial. Cette restriction autorisée est un type de retour covariant.
• Son accès est au moins aussi ouvert que celui de la méthode héritée.
• Elle n’ajoute pas d’exceptions contrôlées interdites par la déclaration héritée.

Par exemple, public String toString() ne peut pas être remplacée par String toString() avec un accès de paquetage. Les appelants existants doivent conserver l’accès.

Distingue redéfinition, surcharge et masquage

role() et role(String language) sont des surcharges ; la seconde ne remplace pas la première. Le choix d’une surcharge utilise les types déclarés des arguments à la compilation. Les méthodes statiques sont aussi sélectionnées à partir du type utilisé à la compilation ; elles ne sont donc pas redéfinies dynamiquement.

Une méthode privée n’est pas héritée ; une méthode de même nom dans la sous-classe est indépendante. Une méthode final ne peut pas être redéfinie, et les constructeurs ne peuvent pas l’être non plus. Au-delà de la compilation, la méthode doit toujours remplir son objectif initial. Une version redéfinie pour un responsable qui renverrait la rémunération mensuelle fausserait le code qui additionne les rémunérations annuelles, même si sa signature était correcte.

Toute classe Java étend Object directement ou indirectement. Les tableaux sont aussi des objets. Cette racine commune fournit des méthodes comme toString(), equals(Object), hashCode() et getClass(), même lorsqu’une classe n’en déclare aucune.

Remplace la description affichée par défaut

La méthode héritée Object.toString() produit un nom de classe, @ et le code de hachage de l’objet en hexadécimal. Un texte comme « school.Person@1b6d3586 » indique la classe mais ne décrit pas les données de la personne. Le nombre peut changer d’une exécution à l’autre et Java ne garantit pas qu’il s’agisse d’une adresse mémoire.

Une redéfinition utile montre les champs dont les lecteurs ont besoin. Ici, un étudiant a hérité de getName() et stocke un champ credits :

@Override
public String toString() {
    return getName() + " (" + credits + " credits)";
}

Pour une étudiante nommée Ada Lovelace avec 10 crédits, System.out.println(s) affiche « Ada Lovelace (10 credits) ». L’appel d’affichage obtient automatiquement le texte de l’objet. La concaténation de chaînes fait de même : "Student: " + s inclut la même description.

Pour une référence nulle, l’affichage et la concaténation produisent « null ». Un appel explicite s.toString() lorsque s est null lève une NullPointerException, car aucun objet ne peut recevoir cet appel.

Si Person.toString() renvoie déjà le nom de la personne, une sous-classe peut s’appuyer sur ce résultat :

@Override
public String toString() {
    return super.toString() + ", student id " + studentId;
}

Pour l’identifiant « S-17 », cela produit « Ada Lovelace, student id S-17 ». L’utilité de super.toString() dépend de ce que la superclasse renvoie réellement. Si elle utilise encore la version de Object, elle apporte le texte par défaut contenant la classe et le code de hachage.

Distingue l’identité des informations sur la classe

Object.equals(Object) compare l’identité : elle renvoie vrai lorsque les deux références désignent le même objet. Deux objets new Person("Ada") distincts ne sont pas égaux selon cette implémentation héritée, même si leurs noms correspondent. Des classes comme String, Integer et ArrayList fournissent des versions redéfinies fondées sur la valeur.

getClass() indique la classe effective à l’exécution :

Person p = new Student("Ada Lovelace");
System.out.println(p.getClass().getSimpleName());

Cela affiche « Student » lorsque Student possède le constructeur montré. Le type déclaré de la variable ne modifie pas la classe de l’objet. getClass() est finale et ne peut pas être redéfinie.

hashCode() est utilisée par les collections fondées sur le hachage. Parmi les autres méthodes de Object figurent la méthode protégée clone() et les méthodes de coordination des threads wait(), notify() et notifyAll().

Vérifie l’orthographe exacte

Java distingue toString() de tostring(). Une méthode toString(String prefix) est une surcharge : l’affichage ne l’appelle donc pas. @Override détecte ces deux erreurs. Une représentation textuelle ne définit pas non plus l’égalité : deux objets peuvent afficher le même texte tout en étant considérés comme inégaux.

Deux objets peuvent représenter la même valeur sans être le même objet. Un catalogue de livres peut considérer deux objets livre comme égaux lorsque leur code de catalogue et leur édition correspondent. Définis cette règle en redéfinissant equals(Object) et garde le hachage cohérent avec elle.

Compare les champs qui définissent la valeur

import java.util.Objects;

final class Book {
    private final String code;
    private final int edition;
    Book(String code, int edition) {
        this.code = code;
        this.edition = edition;
    }
    @Override
    public boolean equals(Object other) {
        if (this == other) return true;
        if (!(other instanceof Book b)) return false;
        return edition == b.edition && Objects.equals(code, b.code);
    }
    @Override
    public int hashCode() {
        return Objects.hash(code, edition);
    }
}

Le test d’identité accepte rapidement le même objet. Le test de type rejette un objet sans rapport ou une référence nulle, puis introduit b comme un Book. Les éditions, de type primitif, sont comparées avec == ; Objects.equals compare les codes sans erreur même si un code est nul. Deux livres portant le code « B-1042 » et l’édition 2 sont considérés comme égaux. L’édition 3 constitue une valeur différente.

Le paramètre doit être de type Object. Écrire equals(Book other) ajoute une surcharge et laisse en place la méthode héritée equals(Object). Le code de bibliothèque qui appelle cette signature continuerait à comparer l’identité. @Override fait échouer la déclaration incorrecte à la compilation.

Respecte les engagements de l’égalité

Pour des références non nulles, l’égalité doit être :

• Réflexive : un objet est égal à lui-même.
• Symétrique : inverser les deux objets donne la même réponse.
• Transitive : si un premier objet est égal à un deuxième et que le deuxième est égal à un troisième, le premier est égal au troisième.
• Cohérente : des comparaisons répétées donnent le même résultat tant que les données comparées ne changent pas.

Un objet doit aussi être considéré comme inégal à null. Des objets égaux doivent renvoyer des codes de hachage égaux. Des objets inégaux peuvent partager un code de hachage : une collision de hachage ne prouve pas l’égalité. Calcule le code de hachage à partir des mêmes champs que l’égalité, comme le fait ici Objects.hash(code, edition).

Une collection fondée sur le hachage utilise le code de hachage pour trouver des candidats avant de vérifier leur égalité. Redéfinir uniquement equals peut conduire un ensemble à conserver des livres distincts mais égaux ou empêcher une Map de trouver une clé égale. Modifier un champ utilisé pour le hachage alors que son objet est stocké comme clé peut laisser cet objet rangé sous son ancien code de hachage.

Préserve la symétrie entre sous-classes

Supposons qu’une classe Book extensible accepte tout objet qui vérifie instanceof Book, tandis que Ebook ajoute la taille du fichier au test d’égalité et n’accepte que les livres numériques. Un livre peut accepter un livre numérique de même code et de même édition, mais le livre numérique rejette le livre. La comparaison a perdu sa symétrie.

Une approche impose des classes effectives identiques, en vérifiant l’absence de nullité avant getClass(). Une autre rend l’égalité de la superclasse finale pour que les sous-classes ne puissent pas étendre la règle d’égalité. Une classe de valeur finale, comme ci-dessus, évite entièrement la question de l’égalité dans les sous-classes. Les records génèrent l’égalité et le hachage à partir de leurs composants ; les constantes d’énumération possèdent déjà une égalité fondée sur l’identité, adaptée à leurs valeurs fixes.

Une classe abstraite est une classe de base qui ne peut pas être instanciée directement. Elle peut contenir des champs communs et des méthodes fonctionnelles tout en laissant certaines opérations à compléter par les sous-classes.

Laisse une opération obligatoire abstraite

abstract class Shape {
    private final String name;
    Shape(String name) { this.name = name; }
    public abstract double area();
    public String describe() {
        return name + " with area " + area();
    }
}
class Rectangle extends Shape {
    private final double width;
    private final double height;
    Rectangle(double width, double height) {
        super("rectangle");
        this.width = width;
        this.height = height;
    }
    @Override
    public double area() { return width * height; }
}

area() possède une signature et un point-virgule, mais pas de corps. Elle indique ce que toute forme concrète doit fournir. Comme Shape contient une méthode abstraite, la classe doit aussi être abstraite. Rectangle fournit l’implémentation manquante et peut être instanciée.

Pour new Rectangle(3.0, 4.0), le constructeur de la superclasse stocke « rectangle ». Le constructeur de la sous-classe stocke les dimensions. Son aire est de 12,0 mètres carrés lorsque les dimensions sont en mètres. L’appel de describe() renvoie « rectangle with area 12.0 ». L’appel à area() dans la méthode héritée exécute l’implémentation du rectangle.

Utilise normalement les constructeurs et les méthodes concrètes

Une classe abstraite peut avoir des champs, des constructeurs et des méthodes avec un corps, aux niveaux d’accès habituels. Son constructeur s’exécute lors de la création d’un objet de sous-classe. new Shape() est interdit même si un constructeur correspondant existe ; new Rectangle(3.0, 4.0) est valide.

Une seconde sous-classe peut utiliser la même description héritée tout en calculant l’aire différemment. Une implémentation pour le cercle renvoie Math.PI * radius * radius. Pour un rayon de 1,5 m, le calcul est π multiplié par 2,25, soit environ 7,07 mètres carrés. La méthode partagée describe() n’a pas besoin d’une branche propre au cercle.

Une variable peut tout de même avoir le type abstrait : Shape s = new Rectangle(3.0, 4.0);. Java interdit de construire la classe abstraite, mais autorise à référencer un objet concret par son intermédiaire.

Fais du travail manquant une erreur de compilation

Chaque sous-classe concrète doit fournir ou hériter des implémentations de toutes les méthodes abstraites. Une sous-classe qui en laisse certaines inachevées doit aussi être déclarée abstraite. Renvoyer 0 depuis une méthode provisoire area() permettrait à une sous-classe concrète incomplète de compiler et de donner discrètement des résultats erronés. Déclarer area() abstraite rend ce travail manquant visible au compilateur.

Les méthodes abstraites ne peuvent pas être privées, statiques ou finales : chacun de ces modificateurs empêcherait la redéfinition par la sous-classe qui fournit l’opération. Une classe abstraite peut ne contenir aucune méthode abstraite ; le modificateur empêche alors uniquement sa construction directe. Utilise ce type de classe de base lorsque ses sous-classes passent le test « est un » et bénéficient d’un état ou de code partagé.

Une interface nomme une capacité que plusieurs classes peuvent fournir. Elle indique les méthodes disponibles pour cette capacité sans exiger que les classes partagent les mêmes champs d’instance ou la même superclasse.

Déclare et implémente les méthodes

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
}
class Phone implements Chargeable {
    private int battery;
    Phone(int battery) { this.battery = battery; }
    @Override
    public int batteryPercent() { return battery; }
    @Override
    public void charge(int minutes) {
        battery = Math.min(100, battery + 2 * minutes);
    }
}

Les méthodes abstraites de l’interface sont implicitement publiques. Les méthodes qui les implémentent doivent être explicitement publiques ; omettre ce modificateur réduirait l’accès et ferait échouer la compilation. Une classe concrète doit fournir ou hériter des implémentations publiques appropriées pour chaque méthode abstraite. Une classe abstraite qui implémente l’interface peut en laisser certaines à ses sous-classes.

Pour un téléphone chargé à 35 %, charge(20) ajoute 40 points de pourcentage et le laisse à 75 %. Après 20 minutes de plus, la charge atteindrait 115 avant plafonnement, donc Math.min stocke 100. Une ElectricScooter peut implémenter la même interface tout en n’ajoutant qu’un point par minute : en partant de 50 %, elle atteint 70 après 20 minutes. L’interface fixe l’opération disponible, tandis que la classe fournit son comportement.

Utilise l’interface comme type

Chargeable device = new Phone(35);
device.charge(20);
System.out.println(device.batteryPercent());

Ce code affiche 75. Un appelant peut utiliser les méthodes de l’interface et les méthodes publiques disponibles sur tout objet. Les opérations propres au téléphone ne sont pas disponibles par l’intermédiaire de device, sauf si l’interface déclarée les expose.

Les interfaces peuvent aussi être les types de paramètres, de valeurs de retour et d’éléments de liste. Une méthode qui accepte Chargeable peut utiliser un téléphone ou une trottinette sans connaître l’organisation de leurs champs. La bibliothèque Java utilise la même approche : List possède des implémentations comme ArrayList et LinkedList ; Runnable déclare run() ; Comparable déclare la comparaison selon l’ordre naturel.

Combine plusieurs capacités

Une classe étend une classe et peut implémenter plusieurs interfaces. L’ordre est class Phone extends Device implements Chargeable, Connectable. Une interface peut en étendre plusieurs : interface SmartDevice extends Chargeable, Connectable. Les classes qui l’implémentent doivent alors fournir toutes les opérations abstraites héritées.

Une interface n’a ni constructeurs ni champs d’instance. new Chargeable() ne compile pas. Un champ déclaré comme int FULL = 100; est implicitement une constante publique, statique et finale, consultée sous la forme Chargeable.FULL.

Une méthode abstraite d’interface n’apporte aucun code fonctionnel. Son implémentation peut provenir de la classe elle-même ou d’une méthode publique héritée de la superclasse. Les méthodes par défaut sont les méthodes d’interface qui peuvent fournir un comportement d’instance hérité.

Les interfaces peuvent fournir du code fonctionnel ainsi que des déclarations de méthodes abstraites. Le modificateur d’une méthode détermine si les objets qui implémentent l’interface en héritent, si les appelants utilisent le nom de l’interface ou si seul le code de l’interface peut l’utiliser.

Construis un comportement par défaut à partir du contrat

interface Chargeable {
    int batteryPercent();
    void charge(int minutes);
    default boolean needsCharge() {
        return batteryPercent() < 20;
    }
    static int clamp(int percent) {
        return Math.max(0, Math.min(100, percent));
    }
}

Une méthode par défaut est une méthode d’instance publique qui possède un corps. Un téléphone indiquant 15 % hérite de needsCharge() et renvoie vrai. À 20 %, il renvoie faux. La méthode par défaut appelle l’opération abstraite batteryPercent() ; elle ne lit pas le champ privé d’un téléphone. Une classe peut redéfinir la méthode avec sa propre implémentation publique.

Une méthode statique d’interface appartient à l’interface : Chargeable.clamp(130) renvoie 100 et Chargeable.clamp(-5) renvoie 0. Les classes qui implémentent l’interface n’en héritent pas, donc Phone.clamp(130) n’est pas un appel valide à cette méthode. Les méthodes par défaut et statiques d’interface ont été introduites en Java 8.

Depuis Java 9, une interface peut aussi déclarer des méthodes privées pour partager du code auxiliaire entre ses propres méthodes. Une méthode auxiliaire privée d’instance aide les méthodes par défaut ; une méthode auxiliaire privée statique peut aussi aider les méthodes statiques. Les classes qui implémentent l’interface ne peuvent pas appeler directement ces méthodes auxiliaires.

Résous les conflits entre méthodes par défaut

Deux interfaces sans lien de parenté peuvent fournir la même signature :

interface Lamp {
    default String describe() { return "lamp"; }
}
interface Speaker {
    default String describe() { return "speaker"; }
}
class SmartLamp implements Lamp, Speaker {
    @Override
    public String describe() {
        return Lamp.super.describe() + " and "
             + Speaker.super.describe();
    }
}

Sans la redéfinition, SmartLamp présente un conflit et ne compile pas. Les appels qualifiés InterfaceName.super.method() sélectionnent les méthodes par défaut de ses superinterfaces directes. Cette implémentation renvoie « lamp and speaker ».

Une déclaration abstraite dans la superclasse peut aussi obliger une sous-classe concrète à implémenter la méthode ; une méthode par défaut d’interface ne supprime pas cette obligation.

Tiens compte des classes qui implémentent déjà l’interface

L’ajout d’une méthode abstraite oblige chaque classe concrète qui implémente l’interface à fournir ou à hériter une implémentation correspondante. Une méthode par défaut évite souvent ce changement en fournissant un comportement fonctionnel, mais elle peut introduire un conflit avec une autre méthode héritée. Les méthodes par défaut aident une interface à évoluer ; les règles d’héritage déterminent toujours si les classes obtenues compilent.

Une classe abstraite et une interface peuvent toutes deux définir des méthodes obligatoires. Le choix dépend de la relation entre les objets et de la nécessité pour leur implémentation de partager un état d’instance.

Compare ce que chacune fournit

Les champs d’une interface sont des constantes publiques, statiques et finales, et non des données propres à chaque objet. Les méthodes auxiliaires privées d’une interface aident ses propres méthodes fonctionnelles ; elles ne créent pas d’état privé pour chaque objet qui l’implémente.

Place l’état de classes étroitement apparentées dans une classe abstraite

Un programme de dessin comporte des cercles, des rectangles et des triangles. Chaque forme stocke un nom et une position, et calcule son aire différemment. Une classe abstraite Shape peut conserver les champs et le constructeur communs, fournir des méthodes fonctionnelles de déplacement ou de description et déclarer area() abstraite.

Toutes les formes concrètes sont des sortes de Shape, si bien que le reste du code peut demander une forme et recevoir n’importe laquelle. De même, une classe abstraite Enemy pourrait posséder des points de vie et une méthode partagée takeDamage(int points), tout en laissant les classes propres à chaque ennemi définir le déplacement. L’état partagé donne à ces classes de base un rôle utile.

Place une capacité transversale dans une interface

Le même programme de dessin peut exporter des formes, des zones de texte et des images. L’export ne fait pas d’une zone de texte une forme, et ces objets peuvent déjà avoir besoin de superclasses différentes. Une interface Exportable peut déclarer String exportText(). Chaque classe implémente l’opération à partir de ses propres données.

Une classe peut combiner les deux rôles : class Circle extends Shape implements Exportable. La superclasse fournit l’état de la forme et le code partagé ; l’interface permet au code d’export d’utiliser le cercle. Une classe qui implémente plusieurs interfaces garantit plusieurs capacités sans hériter de leurs champs d’instance.

Combine un contrat et une implémentation partielle

Une classe abstraite peut implémenter une interface et ne compléter que certaines méthodes. Les sous-classes concrètes terminent les opérations restantes. List et AbstractList dans Java utilisent cette organisation ; ArrayList étend AbstractList. Les appelants peuvent dépendre de l’interface tandis que les classes qui l’implémentent réutilisent une classe de base lorsqu’elle convient.

Par exemple, List<String> names = new ArrayList<>(); permet aux appelants d’ajouter, de lire et de supprimer des noms par l’intermédiaire de List. Remplacer l’initialiseur par new LinkedList<>() préserve ces appels. Un paramètre déclaré comme ArrayList<String> refuserait une LinkedList<String> même s’il n’a besoin que d’opérations de liste.

Une classe abstraite ne contenant que des méthodes abstraites occupe tout de même l’unique place de superclasse de la sous-classe. Elle n’est pas interchangeable avec une interface. Choisis l’interface lorsque seul le contrat commun est nécessaire et ajoute une classe de base lorsque des implémentations apparentées bénéficient d’un état ou de code partagé.

Le polymorphisme permet à une référence de type général de désigner des objets de différents sous-types. L’objet conserve tout son état et son comportement ; la référence donne aux appelants une vue particulière des opérations disponibles.

Nomme les deux types

Person p = new Student("Ada Lovelace", "S-17");

Le type déclaré, aussi appelé type statique, est Person : il apparaît dans la déclaration de la variable. Le type effectif, ou type à l’exécution, est Student : c’est la classe instanciée par new. La classe effective de l’objet ne change pas après sa construction.

Affecter une référence d’étudiant à une référence de personne est un transtypage ascendant. Il est automatique et sûr, car tout étudiant est une personne. Le même étudiant peut aussi être référencé par une variable Object. Une référence à un objet qui implémente une interface peut faire l’objet d’un transtypage ascendant vers cette interface, comme dans Chargeable c = new Phone(35);.

Aucune donnée de l’étudiant n’est supprimée par l’affectation. Il existe toujours un seul objet étudiant avec son identifiant d’étudiant, les données de personne héritées et ses méthodes redéfinies. Le fait de le référencer par un type plus général change ce à quoi le compilateur permet d’accéder par cette référence.

Vérifie les appels par rapport au type déclaré

Si Person déclare getName(), alors p.getName() compile. Si seule Student déclare getStudentId(), alors p.getStudentId() ne compile pas. Le compilateur vérifie l’interface de programmation de Person même lorsque l’initialiseur crée clairement un étudiant.

L’affectation inverse Student s = p; n’est pas acceptée sans transtypage. Une référence de personne pourrait désigner une personne qui n’est pas étudiante. Cette restriction empêche le code de traiter un objet comme s’il appartenait à un sous-type dont il n’est pas une instance.

Permets aux paramètres et aux listes d’accepter plusieurs sous-types

Une méthode static void printCard(Person person) peut recevoir un objet Person, Student ou Teacher, à condition que les deux dernières classes étendent Person. Son code peut s’appuyer sur le contrat de personne. Un type de retour peut aussi être général, par exemple pour une méthode qui renvoie un Shape.

Une liste dont le type d’élément est général peut stocker différentes classes de formes :

List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(1.5));
shapes.add(new Rectangle(3.0, 4.0));
for (Shape shape : shapes) {
    System.out.println(shape.area());
}

Ici, List et ArrayList proviennent de java.util, et chaque forme concrète fournit area(). La boucle utilise uniquement cette opération commune.

Une List<Circle> n’est pas une List<Shape>. Si c’était le cas, du code qui la reçoit comme liste de formes pourrait ajouter un rectangle dans une liste censée ne contenir que des cercles. Lorsqu’une méthode exige une List<Shape>, crée la liste avec ce type d’élément dès le départ.

Un appel de méthode est résolu en deux étapes. À la compilation, Java vérifie les types déclarés et choisit une signature de méthode. À l’exécution, la liaison dynamique choisit l’implémentation redéfinie de la méthode d’instance selon la classe effective de l’objet.

Suis un appel dans une méthode héritée

class A {
    String who() { return "A"; }
    String hello() { return "Hello from " + who(); }
}
class B extends A {
    @Override String who() { return "B"; }
}
class C extends B { }

Avec A x = new C();, x.hello() est autorisé car A déclare hello(). La classe C ne redéfinit pas hello(), et B non plus, donc Java exécute l’implémentation de A.

Dans cette méthode, who() signifie this.who(). L’objet receveur reste l’objet C. Java cherche à partir de C, puis trouve l’implémentation de who() la plus proche dans B. Le résultat est « Hello from B ». Entrer dans une méthode héritée ne transforme pas l’objet receveur en objet de la superclasse.

Choisis une surcharge avant une redéfinition

static String kind(Object value) { return "object"; }
static String kind(String value) { return "string"; }

Dans une classe qui contient ces méthodes, Object value = "hi"; kind(value) sélectionne kind(Object) et renvoie « object ». Le type déclaré de la variable est Object ; Java ne réexamine pas les surcharges à partir de la chaîne effective à l’exécution.

Pour un appel de méthode d’instance, la liaison dynamique peut encore choisir une redéfinition de la signature déjà sélectionnée. Elle ne peut pas passer à une autre surcharge qui semblerait simplement plus spécifique pour l’argument effectif. Identifie d’abord la signature, puis cherche sa redéfinition.

Reconnais les appels et les membres qui ne suivent pas ce mécanisme

Si P déclare String label = "P"; et que Q extends P déclare son propre String label = "Q";, alors P p = new Q(); p.label lit « P ». Les champs sont masqués, et non redéfinis. Les deux champs existent dans l’objet. Évite de réutiliser les noms des champs hérités, car le type de référence peut amener des accès d’apparence identique à lire des états différents.

super.method() sélectionne l’implémentation de la superclasse, y compris une implémentation dont cette superclasse hérite. Si la méthode sélectionnée effectue elle-même un appel ordinaire sur this, cet appel interne peut encore être lié à une méthode redéfinie dans une sous-classe.

Une référence de type général doit parfois accéder à une opération propre à un seul sous-type. Un transtypage descendant indique au compilateur de traiter la référence comme ce sous-type. À l’exécution, Java vérifie si l’objet est déjà de ce type.

Comprends ce que change un transtypage

Supposons que Person p référence un étudiant. Student s = (Student) p; permet d’appeler s.getStudentId(). Les deux variables référencent toujours le même objet. Le transtypage ne le copie pas, ne change pas sa classe effective et n’ajoute pas de champs d’étudiant à une simple personne.

Si p référence en réalité new Person("Grace Hopper"), ce transtypage lève une ClassCastException. Le compilateur accepte la relation possible entre personne et étudiant, mais l’objet à l’exécution doit effectivement la respecter. Un transtypage entre des classes qui ne peuvent pas être apparentées, comme une référence Person transtypée vers la classe finale Integer, échoue à la compilation.

Cela diffère d’une conversion primitive : (int) 3.9 crée la valeur entière 3. Un transtypage de référence vérifie et change seulement le type avec lequel une référence existante est utilisée.

Combine le test et la nouvelle variable

Depuis Java 16, le filtrage par motif rend le cas sûr plus concis :

static void showStudentId(Person person) {
    if (person instanceof Student student) {
        System.out.println(student.getStudentId());
    }
}

Le test est vrai pour un étudiant ou une instance d’une sous-classe d’étudiant. La variable student est disponible dans le bloc, où l’on sait que le test a réussi. Une simple personne passe le bloc. Une référence nulle rend aussi le test faux, si bien que le bloc ne tente jamais d’appeler une méthode sur null.

L’ancienne forme teste person instanceof Student, puis déclare Student student = (Student) person; dans la branche exécutée lorsque le test réussit. Les deux formes protègent le transtypage. Tester ailleurs un objet sans rapport ne protège pas un transtypage de person ; le test et le transtypage doivent concerner la même référence.

Un transtypage ascendant n’a pas besoin d’être explicite. Person person = student; compile déjà et ne peut pas échouer à cause d’une incompatibilité de type. Le transtypage de null vers un type référence compatible produit null ; utiliser ce résultat pour appeler une méthode d’instance échoue néanmoins avec une NullPointerException.

Décide si un test de type est nécessaire

Les tests de type conviennent au code qui reçoit un Object, comme equals(Object other), ou qui a besoin d’une opération propre à un sous-type, comme l’identifiant d’un étudiant. Ils peuvent aussi aider à manipuler des classes qui ne peuvent pas être modifiées.

Un enchaînement répété de tests de type pour une opération partagée pose un autre problème. Si le code vérifie chaque classe de forme pour calculer son aire, chaque forme ajoutée exige une branche supplémentaire. Déclarer area() dans Shape et laisser les sous-classes l’implémenter permet à l’appelant d’utiliser simplement shape.area().

Un transtypage ne peut pas rendre une opération commune manquante disponible dans tous les sous-types. Place le comportement partagé dans le contrat commun et réserve les tests de sous-type aux traitements qui exigent réellement ce sous-type particulier.

Une méthode reste utile avec de nouvelles classes lorsque son paramètre expose précisément les opérations dont elle a besoin. L’appelant fournit les objets ; la liaison dynamique fournit leurs comportements respectifs.

Additionne les aires sans branches propres aux classes

static double totalArea(List<Shape> shapes) {
    double total = 0;
    for (Shape shape : shapes) {
        total += shape.area();
    }
    return total;
}

Avec un cercle de rayon 1,5 m, un rectangle de dimensions 3,0 m et 4,0 m, et un triangle de base 4,0 m et de hauteur 2,5 m, les aires sont environ 7,06858, 12,0 et 5,0 mètres carrés. En additionnant l’aire non arrondie du cercle, on obtient environ 24,07 mètres carrés. Chaque objet fournit sa propre méthode area().

Ajouter une classe Triangle n’exige pas de modifier la boucle. La nouvelle classe implémente l’opération de forme existante. Un résultat négatif violerait le contrat de l’aire même si la redéfinition compilait ; le code général dépend aussi bien du sens de l’opération que de sa signature.

La même approche fonctionne avec une interface. Une méthode chargeAll(List<Chargeable> devices, int minutes) parcourt les appareils et appelle device.charge(minutes). Après 20 minutes, le téléphone initialement à 35 % atteint 75 % et la trottinette initialement à 50 % atteint 70 %. La boucle ne choisit jamais elle-même une règle de charge.

Laisse les appelants choisir une implémentation de liste

Un paramètre List<Shape> accepte aussi bien une ArrayList<Shape> qu’une LinkedList<Shape>. Un paramètre ArrayList<Shape> refuse la liste chaînée bien qu’il n’ait besoin que d’opérations de liste. Utilise le type le plus général qui fournit les méthodes nécessaires ; tout déclarer comme Object serait trop général, car ce type ne possède ni area() ni les opérations de liste.

Rends les objets triables avec Comparable

Comparable<T> définit l’ordre naturel d’un objet. Le résultat de compareTo est négatif lorsque cet objet précède l’autre, nul en cas d’égalité de rang et positif lorsqu’il le suit. C’est le signe du résultat qui compte ; il n’a pas besoin d’être exactement −1 ou 1.

record Runner(String name, int seconds)
        implements Comparable<Runner> {
    @Override
    public int compareTo(Runner other) {
        return Integer.compare(seconds, other.seconds);
    }
}

Une liste modifiable contenant Mia en 3 605 s, Ken en 3 490 s et Ana en 3 720 s devient Ken, Mia, Ana après Collections.sort(runners). list.sort(null) utilise aussi l’ordre naturel. Construis une liste modifiable avec new ArrayList<>(List.of(...)) ; tenter de trier le résultat non modifiable de List.of(...) lève une UnsupportedOperationException.

Utilise Integer.compare au lieu de soustraire les valeurs. La soustraction peut provoquer un dépassement de capacité pour de grandes valeurs de signes opposés et renvoyer un signe incorrect. Le même principe s’applique à Double.compare pour les champs décimaux. Dans cet exemple de coureurs, des temps égaux donnent une égalité de rang même si les noms diffèrent : une égalité de comparaison et l’égalité des objets ne signifient donc pas nécessairement la même chose. Privilégie un ordre naturel dont le résultat nul est cohérent avec l’égalité ; documente toute différence intentionnelle.

Un type énuméré donne son propre type à un ensemble fixe de choix nommés. enum Size { SMALL, MEDIUM, LARGE } permet d’écrire Size size = Size.MEDIUM;. Il empêche un appelant de transmettre la chaîne mal orthographiée « MEDUIM » ou l’entier 7 à une méthode qui exige un Size.

Utilise les noms, les constantes et switch

Chaque constante d’énumération est un objet unique, donc size == Size.LARGE est une comparaison appropriée. Une variable de type énuméré peut aussi valoir null. Size.values() renvoie toutes les constantes dans l’ordre de leur déclaration ; Size.valueOf("LARGE") trouve le nom exact. La recherche est sensible à la casse : « large » provoque une IllegalArgumentException.

name() renvoie le nom déclaré. ordinal() renvoie le rang, qui commence à zéro, donc Size.MEDIUM.ordinal() vaut 1. Insérer une constante modifie les rangs suivants : un rang ordinal constitue donc un mauvais code à stocker ou une mauvaise valeur métier. Par défaut, toString() renvoie aussi le nom.

Une expression switch, standard depuis Java 14, peut renvoyer une valeur :

String label = switch (size) {
    case SMALL -> "S";
    case MEDIUM -> "M";
    case LARGE -> "L";
};

Nommer chaque constante rend l’expression exhaustive sans branche par défaut. Ces cas supposent que size n’est pas null ; énumérer les constantes ne traite pas le cas null.

Donne à chaque constante des données utiles

enum CupSize {
    SMALL(250), MEDIUM(350), LARGE(500);
    private final int milliliters;
    CupSize(int milliliters) { this.milliliters = milliliters; }
    public int milliliters() { return milliliters; }
}

Le point-virgule sépare la liste des constantes des membres. Le constructeur s’exécute une fois pour chaque constante lors de l’initialisation du type énuméré. Il est implicitement privé et les appelants ne peuvent pas créer de nouvelles constantes avec new CupSize(400).

Deux grands gobelets et un petit contiennent 1 250 mL, soit 1,25 L. Ce calcul utilise le champ milliliters, et non les rangs des constantes. Parcourir CupSize.values() et afficher chaque constante et sa capacité donne « SMALL: 250 mL », « MEDIUM: 350 mL » et « LARGE: 500 mL ».

Donne aux constantes leur propre comportement

Un type énuméré peut implémenter une interface et donner aux différentes constantes des corps de méthode distincts :

enum Operation {
    ADD { int apply(int a, int b) { return a + b; } },
    MULTIPLY { int apply(int a, int b) { return a * b; } };
    abstract int apply(int a, int b);
}

Operation.MULTIPLY.apply(6, 7) renvoie 42. Chaque constante complète l’opération abstraite. Les types énumérés étendent implicitement java.lang.Enum ; ils ne peuvent pas étendre une autre classe et les classes ordinaires ne peuvent pas les étendre.

Utilise un type énuméré pour des options fixées lors de l’écriture du programme, comme les directions ou les états d’une commande. La liste changeante des produits d’un magasin relève des données : ajouter des produits ne devrait pas exiger de réécrire et de recompiler une déclaration de type énuméré.

Un record est une classe de données concise, standard depuis Java 16. Son en-tête énumère les valeurs, appelées composants, qui définissent chaque instance : record Point(int x, int y) { }.

Utilise les membres générés

Le compilateur fournit un champ privé et final pour chaque composant, un constructeur canonique prenant ces composants dans l’ordre et des accesseurs publics portant leurs noms. Il fournit aussi equals, hashCode et toString fondés sur les composants.

Point a = new Point(3, 4);
Point b = new Point(3, 4);
System.out.println(a.x());
System.out.println(a.equals(b));
System.out.println(a == b);

Ce code affiche 3, true et false sur des lignes distinctes. Les valeurs correspondantes des composants rendent les records égaux, mais les deux expressions new créent des objets distincts. Des records égaux ont des codes de hachage égaux. Leur texte généré, utile, comprend les noms du record et des composants ; les JDK actuels affichent « Point[x=3, y=4] ». Ce format textuel exact n’est pas garanti : ne l’analyse donc pas comme un format de données.

Les accesseurs sont x() et y(), et non getX() et getY(). Un mutateur qui effectue l’affectation this.x = x ne compile pas, car le champ du composant est final. Une méthode peut renvoyer une nouvelle valeur à la place : Point moveRight(int dx) { return new Point(x + dx, y); }.

Valide les données dans un constructeur compact

record Temperature(double celsius) {
    Temperature {
        if (celsius < -273.15) {
            throw new IllegalArgumentException("below absolute zero");
        }
    }
}

Un constructeur compact répète le nom du record sans liste de paramètres. Il vérifie ou normalise les paramètres reçus ; Java affecte les champs des composants après l’exécution de son corps. Cette vérification rejette −300 °C et accepte 21,5 °C. Un composant textuel pourrait être normalisé avec name = name.trim(); avant l’affectation automatique.

Un record public nécessite un constructeur compact public. Les records peuvent aussi déclarer des champs statiques, des méthodes statiques et des méthodes d’instance. Un constructeur supplémentaire délègue au constructeur canonique avec this(...). Les champs d’instance supplémentaires en dehors des composants sont interdits.

Protège les objets mutables des composants

Les champs de composants finaux rendent l’immuabilité superficielle. Un record contenant une liste mutable référence toujours cette liste :

record Team(String name, List<String> members) {
    Team {
        members = List.copyOf(members);
    }
}

Une fois java.util.List importée, ce code stocke une copie non modifiable. Les ajouts ultérieurs à la liste initiale ne modifient pas les membres de l’équipe, et team.members().add("Lee") lève une UnsupportedOperationException. La copie protège la structure de la liste ; elle ne rend pas profondément immuables les objets mutables qui en sont les éléments.

Les records étendent implicitement java.lang.Record et sont finaux. Ils ne peuvent pas étendre une autre classe ni être étendus, mais peuvent implémenter des interfaces comme Comparable. Utilise-les pour des données définies par leurs valeurs ; utilise une classe ordinaire pour un état changeant, des champs d’instance masqués supplémentaires ou une hiérarchie de classes extensible.