• Home
  • Docker
  • Kubernetes
  • LLMs
  • Java
  • Ubuntu
  • Maven
  • Big Data
  • Archived
Java | Outrepassement de méthode (method overriding)
  1. Outrepasser une méthode
  2. Règles d'outrepassement des méthodes
  3. Implémentation des méthodes des interfaces

  1. Outrepasser une méthode
    L'outrepassement de méthode permet à une sous-classe de fournir une définition spécifique d'une méthode déjà définie dans l'une de ses superclasses.

    La version de la méthode de la superclasse peut être invoquée à partir du code de la sous-classe en utilisant le mot clé super (exemple : super.doCallOverridenMethod()).

    Notes : L'outrepassement est un concept qui s'applique uniquement aux méthodes et non pas aux variables.

    Terminologie :
    • outrepasser une méthode : to override a method.
    • la méthode outrepassée : the overridden method.
    • la méthode outrepassante : the overriding method.
  2. Règles d'outrepassement des méthodes
    • L'outrepassement des méthodes est possible uniquement pour les méthodes qui sont héritables.
      Par exemple, une méthode marquée private n'est pas héritable et ne peut pas donc être outrepassée.
      Mais rien n'empêche de fournir une implémentation de la même méthode avec le même nom, la même signature (paramètres), et le même type de retour dans la sous-classe, mais dans ce cas c'est comme si on a créé une nouvelle méthode qui n'a absolument rien avoir avec la méthode de superclasse.

    • Une sous-classe dans le même package que celui de la superclasse peut outrepasser toutes les méthodes de cette classe qui ne sont pas marquées private.

    • Une sous-classe dans un package différent de celui de la superclasse peut outrepasser toutes les méthodes de cette classe qui sont marquées public ou protected.

    • On ne peut pas outrepasser une méthode marquée final.
      Le compilateur affichera un message d'erreur : "Cannot override the final method from SuperClass"


    • On ne peut pas outrepasser une méthode marquée static.
      Le compilateur affichera un message d'erreur : "This instance method cannot override the static method from SuperClass"


      Cependant, il est correcte de marquer static la méthode de la sous-classe ; dans ce cas il s'agit d'une nouvelle méthode qui n'a aucune relation avec la méthode de la superclasse.
      Dans ce cas, la version de la méthode invoquée dépendra du type de la variable (définie dans sa déclaration) et non pas de l'instance en mémoire.

    • Pour être considéré comme une méthode outrepassante, la liste des paramètres doit correspondre exactement à celle de la méthode de la superclasse.

      Le type de chaque paramètre de la version de la méthode de la sous-classe doit être le même que celui du paramètre correspondant de la version de la méthode de la superclasse.

      Si le nombre des paramètres est différent dans les deux versions ou que les types des paramètres sont différents (un sous-type est considéré comme différent), alors il ne s'agit pas d'un outrepassement mais de deux méthodes complètement différentes.



      Le détail de la surcharge des méthodes sera discuté dans une page séparée (Surcharge de méthode (method overloading)), mais il faut juste noter maintenant que la résolution de la méthode qui sera exécutée dépendra des types des arguments.

    • Le type de retour de la méthode outrepassante doit être du même type ou un sous-type de celui de la méthode de la superclasse.
      Si le type de retour est différent, alors le compilateur affichera une erreur.


      Pour corriger le code de l'exemple précédent, il faut modifier le type de retour en SuperClass ou SubClass.

      Il faut noter, cependant, que si le nombre des paramètres est différent dans les deux versions des méthodes de la superclasse et la sous-classe ou que les types des paramètres sont différents (un sous-type est considéré comme différent), alors cette règle ne s'applique pas vu qu'il ne s'agit pas d'un outrepassement.

    • La visibilité (modificateur d'accès) de la méthode outrepassante ne peut pas être plus restrictive que la méthode de la superclasse.
      Par exemple : on ne peut pas outrepasser une méthode declarée public et la déclarer protected ou private :


    • La visibilité de la méthode outrepassante peut être moins restrictive que la méthode de la superclasse.
      Par exemple : on peut outrepasser une méthode declarée protected et la déclarer public :


    • La méthode outrepassante peut lancer (throw) n'import quelle exception non-vérifiée (par le compilateur), indépendamment si la méthode de la superclasse lance ou non cette exception.


    • La méthode outrepassante ne peut pas lancer des exceptions vérifiées (par le compilateur) qui ne sont pas lancées par la méthode de la superclasse.


    • La méthode outrepassante peut ne pas lancer les exceptions vérifiées (par le compilateur) qui sont lancées par la méthode de la superclasse.


      Il faut rappeler que le compilateur considère uniquement le type de la variable pour décider si c'est la version de la superclasse ou celle de la sous-classe qui sera exécutée. Donc si le type de la variable est celui de la superclasse, alors il faut mettre l'appel de la méthode à l'intérieur du bloc try-catch, sinon le compilateur affichera une erreur :
    • La méthode outrepassante peut lancer uniquement des exceptions vérifiées (par le compilateur) qui sont du même type ou un sous-type des exceptions lancées par la méthode de la superclasse.

      Au cas contraire le compilateur affichera un message d'erreur :

  3. Implémentation des méthodes des interfaces
    Une classe (non-abstraite) doit implémenter toutes les méthodes des interfaces implémentées.
    L'implémentation des méthodes doit respecter les mêmes règles, vues ci-dessus, pour l'outrepassement des méthodes.
    • La liste des paramètres (ainsi que leurs types) doit correspondre exactement à celle de la méthode de l'interface implémentée.

    • Le type de retour de la méthode implémentée doit être du même type ou un sous-type de celui de la méthode de l'interface implémentée.

    • La visibilité de la méthode implémentée ne peut pas être plus restrictive que la méthode de l'interface implémentée.
      Autrement dit, le modificateur d'accès de la méthode implémentée doit être public.

    • la méthode implémentée peut lancer n'import quelle exception non-vérifiée (par le compilateur), indépendamment si la méthode de l'interface implémentée lance ou non cette exception.

    • la méthode implémentée ne peut pas lancer des exceptions vérifiées (par le compilateur) qui ne sont pas lancées par la méthode de l'interface implémentée.

    • la méthode implémentée peut ne pas lancer les exceptions vérifiées (par le compilateur) qui sont lancées par la méthode de l'interface implémentée.

    • la méthode implémentée peut lancer uniquement des exceptions vérifiées (par le compilateur) qui sont du même type ou un sous-type des exceptions lancées par la méthode de l'interface implémentée.
© 2025  mtitek