En effet, si je déclare une méthode dans une interface, une erreur de compilation est générée si cette méthode n'est pas implémentée dans la classe qui implémente cette interface (je ne respecte pas le contrat défini par l'interface).
Mais si par la suite nous supprimons une méthode de notre interface ?
Le compilateur ne sait pas que la méthode implémentée dans la classe correspondait à un ancien contrat avec l'interface, et n'est plus d'aucune utilité (nous ne nous attardons pas ici au choix de la suppression d'une méthode publique et aux conséquences sur le refactoring).
Lorsque nous redéfinissons (“override” (en français, « surcharge »)) dans une classe une méthode définie dans une super-classe, nous devrions toujours l'annoter avec @Override. De cette manière, la maintenance du code est facilitée, car nous avons des erreurs de compilation si cette méthode n'existe plus en amont dans la hiérarchie de cette classe, si le nom est modifié, etc.
Dans le cas d'une classe qui fournit l'implémentation d'une méthode définie dans une classe parent abstraite, il n'est pas logique de marquer cette méthode avec l'annotation @Override, car il n'y a pas encore eu d'implémentation. Pourtant c'est ce que je fais; dans ce cas, j'utilise l'annotation @Override, car il n'existe pas d'alternative permettant de forcer l'erreur de compilation en cas de mauvaise maintenance.
Une annotation @implement serait la bienvenue dans ce cas, et serait plus appropriée au niveau sémantique.
Si nous considérons une interface comme une classe abstraite dont toutes les méthodes sont publiques et abstraites, la première implémentation d'une méthode définie dans l'interface serait annotée @implement, et si elle est surchargée par la suite, la surcharge serait annotée @Override.
« Raz-le-Brol... »
Vous pouvez modifier vos préférences dans votre profil pour ne plus afficher les interactions avec les réseaux sociaux sur ces pages.
Recherche (afficher)
Utilisateur (masquer)
Navigation (masquer)
Apparence (afficher)
Stats (afficher)
Citation (masquer)