Letzte Argumente in Schnittstellenmethoden - worum geht es?

In Java ist es völlig legal, finalArgumente in Schnittstellenmethoden zu definieren und diese in der implementierenden Klasse nicht zu beachten, z.

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) {
        ...
    }
}

Im obigen Beispiel barund bazhat die entgegengesetzten finalDefinitionen in der Klasse VS die Schnittstelle.

Auf die gleiche Weise werden keine finalEinschränkungen erzwungen, wenn eine Klassenmethode eine andere erweitert abstractoder nicht.

Während finaleinigen praktischen Wert innerhalb der Klassenmethode Körper hat, gibt es eine Stelle spezifiziert finalfür Schnittstellenmethodenparameter?

Es scheint keinen Sinn zu haben. Gemäß der Java-Sprachspezifikation 4.12.4 :

Das Deklarieren einer Variablen final kann als nützliche Dokumentation dafür dienen, dass sich ihr Wert nicht ändert, und kann dazu beitragen, Programmierfehler zu vermeiden.

Ein final Modifikator für einen Methodenparameter wird jedoch in den Regeln für den Abgleich von Signaturen überschriebener Methoden nicht erwähnt und hat keine Auswirkungen auf den Aufrufer, nur innerhalb des Hauptteils einer Implementierung. Wie Robin in einem Kommentar bemerkt hat, hat der finalModifikator für einen Methodenparameter keine Auswirkung auf den generierten Bytecode. (Dies gilt nicht für andere Verwendungen von final.)

Einige IDEs kopieren die Signatur der Abstract- / Interface-Methode, wenn eine Implementierungsmethode in eine Unterklasse eingefügt wird.

Ich glaube nicht, dass es für den Compiler einen Unterschied macht.

EDIT: Obwohl ich glaube, dass dies in der Vergangenheit der Fall war, glaube ich nicht, dass aktuelle IDEs dies mehr tun.

Abschließende Anmerkungen zu Methodenparametern sind immer nur für die Methodenimplementierung relevant, niemals für den Aufrufer. Daher gibt es keinen wirklichen Grund, sie in Signaturen von Schnittstellenmethoden zu verwenden. Es sei denn, Sie möchten in allen Methodensignaturen denselben konsistenten Codierungsstandard befolgen, für den endgültige Methodenparameter erforderlich sind. Dann ist es schön, das zu können.

Update: Die ursprüngliche Antwort unten wurde geschrieben, ohne die Frage vollständig zu verstehen, und geht daher nicht direkt auf die Frage ein. :)Dennoch muss sie für diejenigen informativ sein, die die allgemeine Verwendung von verstehen möchtenfinal Schlüsselwörtern möchten.

Zu der Frage möchte ich meinen eigenen Kommentar von unten zitieren.

Ich glaube, Sie sind nicht gezwungen, die Endgültigkeit eines Arguments umzusetzen, damit Sie frei entscheiden können, ob es in Ihrer eigenen Umsetzung endgültig sein soll oder nicht.

Aber ja, es klingt ziemlich seltsam, dass Sie es finalin der Schnittstelle deklarieren können, es aber in der Implementierung nicht endgültig haben . Es wäre sinnvoller gewesen, wenn entweder:

ein. finalDas Schlüsselwort war für Argumente der Schnittstellenmethode (abstrakt) nicht zulässig (Sie können es jedoch in der Implementierung verwenden), oder
b. Das Deklarieren eines Arguments wie finalin der Schnittstelle würde die Deklaration finalin der Implementierung erzwingen (jedoch nicht für Nicht-Finale erzwingen ).

Ich kann mir zwei Gründe vorstellen, warum eine Methodensignatur finalParameter haben kann: Beans und Objekte ( Eigentlich sind beide der gleiche Grund, aber leicht unterschiedliche Kontexte. )

Objekte:

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 ");
}

Das finalSchlüsselwort stellte sicher, dass wir nicht versehentlich einen neuen lokalen Kochtopf erstellen, indem bei diesem Versuch ein Kompilierungsfehler angezeigt wurde. Dies stellte sicher, dass die Hühnerbrühe in unseren ursprünglichen Kochtopf gegeben wurde, den die addChickenMethode erhielt. Vergleichen Sie dies mit der Stelle, addVegetablesan der wir den Blumenkohl verloren haben, weil er diesen anstelle des ursprünglichen Topfes in einen neuen lokalen Kochtopf gegeben hat.

Bohnen: Es ist das gleiche Konzept wie bei Objekten (wie oben gezeigt) . Bohnen sind im Wesentlichen Objects in Java. Beans (JavaBeans) werden jedoch in verschiedenen Anwendungen verwendet, um eine definierte Sammlung verwandter Daten bequem zu speichern und weiterzugeben. So wie das addVegetablesden Kochprozess durcheinander bringen könnte, indem ein neuer Kochtopf erstellt StringBuilderund mit dem Blumenkohl weggeworfen wird, könnte dies auch mit einem Kochtopf JavaBean geschehen .

Ich glaube, es kann ein überflüssiges Detail sein, denn ob es endgültig ist oder nicht, ist ein Implementierungsdetail.

(So ​​ähnlich wie das Deklarieren von Methoden / Mitgliedern in einer Schnittstelle als öffentlich.)