1
votes

Dois-je implémenter des méthodes héritées en Java?

Je suis un débutant en Java et j'ai deux questions qui me préoccupent vraiment ...

@Override n'est-il pas une sorte de duplication de code? Je veux dire, laissez-moi considérer une situation. J'implémente une fonction dans la classe Parent. Ensuite, je crée une classe Child qui hérite de cette méthode de la classe Parent. Maintenant, je suis en mesure d'utiliser cette fonction sans l'implémenter à nouveau dans la classe Child - cela fonctionne. Mais est-ce une bonne pratique? Ou peut-être devrais-je écrire @Override et implémenter à nouveau cette fonction?
Dois-je @Override les setters et les getters de la classe Parent? (Et implémentez-les dans Child - comme dans la question précédente). Ou peut-être devraient-ils être abstraits en classe Parent? Merci d'avance :)

class Animal { /*Parent class*/
    private int numOfLegs;
    protected String sound;

    public Animal(int numOfLegs, String sound) {
        this.numOfLegs = numOfLegs;
        this.sound = sound;
    }

    public int getNumOfLegs() {
        return numOfLegs;
    }

    public void makeSound() {
        System.out.println(sound);
    }
}

class Dog extends Animal{ /*Child class*/
    public Dog(int numOfLegs, String sound) {
        super(numOfLegs, sound);
    }

    @Override /*Is it necessery to implement an inherited function?*/
    public void makeSound() {
        System.out.println(sound);
    }

    /*Do I need to implement an inherited getter?/*

}

java overriding inheritance getter

1 commentaires

Vous ne devez remplacer les méthodes que lorsque vous souhaitez modifier la fonction héritée! La réponse à vos deux questions est donc non .

3 Réponses :

2
votes

Le but de la substitution, comme son nom l'indique, est de remplacer / remplacer / modifier le comportement de la méthode parente. Il ne sert à rien de remplacer une méthode avec la même implémentation. Vous pouvez simplement utiliser la méthode héritée si vous ne voulez rien changer.

0 commentaires

1
votes

@Override n'est-il pas une sorte de duplication de code?

Si vous dupliquez le même code (comme dans le parent), vous perdez le point pour lequel le remplacement est prévu: définissez un nouveau code pour une méthode que vous parent a déjà définie.

Au contraire, c'est à propos de la réutilisation du code: nous réutilisons ce qu'il est utile d'utiliser (les méthodes que nous ne remplaçons pas et que nous ne voulons pas répéter dans une nouvelle classe entièrement séparée) et nous ne remplaçons que ce qui doit être changé.

... est-ce une bonne pratique?

Ce n'est pas une bonne pratique de surcharger un code mais une question de modifier le comportement d'une méthode héritée d'une classe parente (il y a beaucoup de raisons pour lesquelles nous faisons cela) p >

Ou peut-être que je devrais écrire @Override et implémenter cette fonction une fois encore?

Encore une fois, vous ne remplacez la méthode que si vous en avez besoin.

Maintenant, ce que c'est une bonne pratique , c'est de remplacer une méthode que vous DEVRIEZ annoter avec @Override (si vous ne le faites pas, cela fonctionne aussi, mais vous perdrez les informations utiles que le compilateur peut donner avec cette annotation: par exemple vérifiez que vous remplacez la méthode et ne créez pas de surcharge car la signature de la méthode est différente de celle du parent)

Dois-je @Override les setters et les getters de la classe Parent?

Parfois, seulement si le cas d'utilisation l'exige, mais ce n'est pas courant de voir cela.

Ou peut-être devraient-ils être abstraits dans la classe Parent?

À propos qu'ils soient abstraits, eh bien, c'est un sujet complètement différent (mais étroitement lié, je sais).

Ils ne devraient être abstraits que si dans la classe parent il n'y en a pas assez des informations pour implémenter ces méthodes, des informations qui dépendent de l'implémentation concrète (dans les classes enfants).

Exemple de cas d'utilisation :

La plupart des oiseaux volent , à droite, d'autres non: Si nous créons une classe Bird , nous pouvons avoir une méthode getMovement qui renvoie "Fly". Maintenant, si nous créons une classe Penguin , nous devons remplacer cela, car ils ne volent pas. Aussi dans la classe Bird il y a une méthode getCover qui retourne "Feathers", dans la classe Penguin nous n'avons pas besoin de la remplacer, car ils ont aussi des plumes :)
public class Bird {

    // for most birds this is OK, they fly
    public String getMovement() {
        return "Fly";
    }

    public String getCover() {
        return "Feathers";
    }

}

public class Penguin extends Bird {

    // penguins don't fly, so we need to override the parent method in order to create more realistic penguins
    @Override
    public String getMovement() {
        return "Walk";
    }
    //we don't override getCover because penguins do have "Feather"
}

0 commentaires

1
votes

Vous ne devez remplacer votre méthode de la classe parente que si vous souhaitez remplacer la super-classe. Mais vous devez remplacer toutes les méthodes d'Iterface lorsque vous l'implémentez par une partie de votre classe.

Donc, vous pouvez utiliser une méthode de la classe Dog comme super.makeSound () ou Just makeSound () si vous ne voulez pas la remplacer dans la classe Child, par exemple ne pas faire de son mais faire un saut ou quelque chose comme ça autre.

0 commentaires