Arguments finaux dans les méthodes d'interface - à quoi ça sert?

En Java, il est parfaitement légal de définir des finalarguments dans les méthodes d'interface et de ne pas obéir à cela dans la classe d'implémentation, par exemple:

public interface Foo {
    public void foo(int bar, final int baz);
}

public class FooImpl implements Foo {

    @Override
    public void foo(final int bar, int baz) {
        ...
    }
}

Dans l'exemple ci-dessus, baret baza les finaldéfinitions opposées dans la classe VS l'interface.

De la même manière, aucune finalrestriction n'est appliquée lorsqu'une méthode de classe en étend une autre, que ce soit abstractou non.

Bien que finalle corps de la méthode de classe ait une valeur pratique, y a-t-il un point précisant les finalparamètres de la méthode d'interface?

Il ne semble pas y avoir de raison. Selon la spécification du langage Java 4.12.4 :

Déclarer une variable final peut servir de documentation utile indiquant que sa valeur ne changera pas et peut aider à éviter des erreurs de programmation.

Cependant, un finalmodificateur sur un paramètre de méthode n'est pas mentionné dans les règles de correspondance des signatures de méthodes remplacées, et il n'a aucun effet sur l'appelant, uniquement dans le corps d'une implémentation. De plus, comme l'a noté Robin dans un commentaire, le finalmodificateur sur un paramètre de méthode n'a aucun effet sur le code d'octet généré. (Ce n'est pas vrai pour les autres utilisations de final.)

Certains IDE copient la signature de la méthode abstraite / d'interface lors de l'insertion d'une méthode d'implémentation dans une sous-classe.

Je ne pense pas que cela fasse une différence pour le compilateur.

EDIT: Bien que je pense que c'était vrai dans le passé, je ne pense pas que les IDE actuels le fassent plus.

Les annotations finales des paramètres de méthode sont toujours pertinentes uniquement pour l'implémentation de la méthode, jamais pour l'appelant. Par conséquent, il n'y a aucune vraie raison de les utiliser dans les signatures de méthode d'interface. Sauf si vous souhaitez suivre la même norme de codage cohérente, qui nécessite des paramètres de méthode finaux, dans toutes les signatures de méthode. Alors c'est bien de pouvoir le faire.

Mise à jour: La réponse originale ci-dessous a été rédigée sans bien comprendre la question, et ne répond donc pas directement à la question. :)Néanmoins, elle doit être informative pour ceux qui cherchent à comprendre l'utilisation générale du finalmot - clé.

Pour ce qui est de la question, je voudrais citer mon propre commentaire ci-dessous.

Je pense que vous n'êtes pas obligé de mettre en œuvre la finalité d'un argument pour vous laisser libre de décider s'il doit être définitif ou non dans votre propre mise en œuvre.

Mais oui, cela semble assez étrange que vous puissiez le déclarer finaldans l'interface, mais que ce soit non final dans l'implémentation. Cela aurait été plus logique si:

une. finalLe mot clé n'était pas autorisé pour les arguments de méthode d'interface (abstraite) (mais vous pouvez l'utiliser dans l'implémentation), ou
b. déclarer un argument comme finaldans interface le forcerait à être déclaré finaldans l'implémentation (mais pas forcé pour les non finales).

Je peux penser à deux raisons pour lesquelles une signature de méthode peut avoir des finalparamètres: Beans et Objects (en fait, ce sont tous les deux la même raison, mais des contextes légèrement différents. )

Objets:

public static void main(String[] args) {
    StringBuilder cookingPot = new StringBuilder("Water ");
    addVegetables(cookingPot);
    addChicken(cookingPot);
    System.out.println(cookingPot.toString());
    // ^--- OUTPUT IS: Water Carrot Broccoli Chicken ChickenBroth 
    //      We forgot to add cauliflower. It went into the wrong pot.
}

private static void addVegetables(StringBuilder cookingPot) {
    cookingPot.append("Carrot ");
    cookingPot.append("Broccoli ");
    cookingPot = new StringBuilder(cookingPot.toString());
    //   ^--- Assignment allowed...
    cookingPot.append("Cauliflower ");
}

private static void addChicken(final StringBuilder cookingPot) {
    cookingPot.append("Chicken ");
    //cookingPot = new StringBuilder(cookingPot.toString());
    //     ^---- COMPILATION ERROR! It is final.
    cookingPot.append("ChickenBroth ");
}

Le finalmot-clé garantit que nous ne créerons pas accidentellement une nouvelle marmite locale en affichant une erreur de compilation lorsque nous avons tenté de le faire. Cela garantit que le bouillon de poulet est ajouté à notre marmite d'origine que la addChickenméthode a obtenue. Comparez cela à l' addVegetablesendroit où nous avons perdu le chou-fleur parce qu'il l'a ajouté à une nouvelle marmite locale au lieu de la marmite d'origine.

Beans: C'est le même concept que les objets (comme indiqué ci-dessus) . Les beans sont essentiellement des Objects en Java. Cependant, les beans (JavaBeans) sont utilisés dans diverses applications comme un moyen pratique de stocker et de transmettre une collection définie de données associées. Tout comme le addVegetablespourrait gâcher le processus de cuisson en créant une nouvelle marmite StringBuilderet en le jetant avec le chou-fleur, il pourrait également faire de même avec une marmite JavaBean .

Je pense que c'est peut-être un détail superflu, car le fait qu'il soit définitif ou non est un détail de mise en œuvre.

(Un peu comme déclarer des méthodes / membres dans une interface comme public.)