Discussion :

[flamant]

Bonjour, sur un livre de tests java voici un test

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
abstract class Bird {
    protected Bird() {
        System.out.print("Wow-");
    }
 
    private final void fly() {
        System.out.println("Bird");
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Pelican extends Bird {
    public Pelican() {
        System.out.print("Oh-");
    }
 
    protected void fly() {
        System.out.println("Pelican");
    }
 
    static void main(String[] args) {
        var chirp = new Pelican();
        chirp.fly();
    }
}

private final void fly() {System.out.println("Bird");} : cette méthode ne peut être appelée que depuis sa classe et ne peut pas être overridée dans une classe fille. Donc à quoi sert-elle ? et est-ce que private final est possible et ne soulève pas une erreur ?

dans la classe fille Pelican on a : protected void fly() { System.out.println("Pelican");}. Il semble justement que c'est un override de la méthode précédemment discutée. Ca ne soulève pas une erreur ?

[bouye]

Le soucis a déjà été soulevé il y a 14 ans et la réponse semble être le fait que les méthodes private ne sont pas visibles et donc pas héritées par les classes enfants (le final importe peu).

Qui plus est, si tu crée dans Bird une méthode qui invoque fly() et que tu l'utilise depuis ton instance de Pelican tu verras que c'est bien la variante de Bird qui est invoquée. Donc il n'y a pas de surcharge. Le soucis disparaît des que tu replaces le private final void fly() par protected void fly() dans Bird.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
protected void doStuff() {
        fly();
    }

[flamant]

merci pour ta réponse Bouye,
il y a une chose que je n'ai pas compris: fly() dans Pelican est bien un override de fly() dans bird. Etant final dans Bird, ça soulève une erreur non

[thelvin]

Hello,

non, les membres en visibilité private ne sont pas visibles aux autres classes, que ce soit des classes descendantes ou pas, c'est traité comme s'ils n'existaient pas en ce qui concerne les autres classes. La notion de les redéfinir n'a donc pas de sens, ça ne sera jamais le cas.

Les signatures de ces méthodes sont comme elles devraient être pour que l'une redéfinisse l'autre, mais puisque celle de la classe parente est private, elle est traitée par les autres classes comme si elle n'existait pas et il n'y a pas de redéfinition. Ce n'est pas une erreur. C'est juste un peu redondant de dire qu'une méthode private est final, parce que ça ne peut pas être autrement.

(Bon, je simplifie un peu. Une méthode private est toujours final et elle est tenue à l'écart du système de redéfinitions, parce que ça a été décidé comme ça. Et aussi parce que tout l'intérêt de la redéfinition, est perdu avec des méthodes private. Mais elle peut être appelée par les classes imbriquées dans la classe qui a la méthode private, donc du point de vue de ces classes-là la méthode existe, mais elle n'a quand même pas de notion de pouvoir être redéfinie, et elle n'aura quand même aucun lien avec d'autres méthodes dans d'autres classes qui portent le même nom, parce que ça fait ça avec les méthodes private. A la rigueur, elle peut se retrouver masquée quand une méthode de même nom et de signature compatible est déclarée dans une classe imbriquée et descendante.)

[flamant]

Merci Thelvin, je comprends mieux. Résolu