Ostatnie argumenty w metodach interfejsu - o co chodzi?

W Javie jest całkowicie legalne definiowanie finalargumentów w metodach interfejsu i nie przestrzeganie tego w klasie implementującej, np .:

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

W powyższym przykładzie, bari bazma przeciwległe finaldefinicji w klasie VS interfejsu.

W ten sam sposób nie finalsą wymuszane żadne ograniczenia, gdy jedna metoda klasy rozszerza inną, albo abstractnie.

Chociaż finalma jakąś praktyczną wartość w treści metody klasy, czy jest jakiś punkt określający finalparametry metody interfejsu?

Nie wydaje się, żeby to miało jakiś sens. Zgodnie ze specyfikacją języka Java 4.12.4 :

Deklaracja zmiennej końcowej może służyć jako przydatna dokumentacja, której wartość się nie zmieni i może pomóc uniknąć błędów programistycznych.

Jednak finalmodyfikator parametru metody nie jest wspomniany w regułach dopasowywania podpisów zastąpionych metod i nie ma wpływu na obiekt wywołujący, tylko w treści implementacji. Ponadto, jak zauważył Robin w komentarzu, finalmodyfikator parametru metody nie ma wpływu na wygenerowany kod bajtowy. (Nie dotyczy to innych zastosowań final.)

Niektóre IDE skopiują podpis metody abstrakcyjnej / interfejsu podczas wstawiania metody implementującej do podklasy.

Nie sądzę, żeby miało to jakiekolwiek znaczenie dla kompilatora.

EDYCJA: Chociaż uważam, że tak było w przeszłości, nie sądzę, aby obecne IDE to robiły.

Końcowe adnotacje parametrów metody są zawsze istotne tylko dla implementacji metody, nigdy dla osoby wywołującej. Dlatego nie ma rzeczywistego powodu, aby używać ich w podpisach metod interfejsu. Chyba że chcesz stosować ten sam spójny standard kodowania, który wymaga ostatecznych parametrów metody, we wszystkich sygnaturach metod. Miło jest móc to zrobić.

Aktualizacja: Oryginalna odpowiedź poniżej została napisana bez pełnego zrozumienia pytania, dlatego też nie odnosi się bezpośrednio do pytania. :)Niemniej jednak musi być pouczająca dla osób, które chcą zrozumieć ogólne użycie finalsłowa kluczowego.

Jeśli chodzi o pytanie, chciałbym zacytować swój komentarz od dołu.

Uważam, że nie jesteś zmuszony wdrożyć ostateczności argumentu, abyś mógł zdecydować, czy powinien on być ostateczny, czy nie we własnej implementacji.

Ale tak, to brzmi dość dziwnie, że można zadeklarować to finalw interfejsie, ale nie jest to ostateczne wdrożenie. Byłoby bardziej sensowne, gdyby:

za. finalsłowo kluczowe nie było dozwolone dla argumentów metody interfejsu (abstrakcyjnej) (ale można go użyć w implementacji), lub
b. zadeklarowanie argumentu jako finalinterfejsu zmusiłoby go do zadeklarowania go finalw implementacji (ale nie do wymuszenia w przypadku niefinałów).

Mogę wymyślić dwa powody, dla których podpis metody może mieć finalparametry: Beans i Objects (w rzeczywistości oba są z tego samego powodu, ale nieco inne konteksty ).

Obiekty:

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

finalKluczowe zapewnić, że nie będzie przypadkowo utworzyć nową lokalną garnek do gotowania, pokazując błąd kompilacji, gdy staraliśmy się zrobić. Dzięki temu bulion z kurczaka został dodany do naszego oryginalnego garnka do gotowania, który addChickenotrzymaliśmy według metody. Porównaj to z addVegetablesmiejscem, w którym straciliśmy kalafior, ponieważ dodało to do nowego lokalnego garnka do gotowania zamiast oryginalnego garnka, który dostał.

Fasola: Jest to ta sama koncepcja co obiekty (jak pokazano powyżej) . Ziarna są zasadniczo Objectw Javie. Jednak fasole (JavaBeans) są używane w różnych aplikacjach jako wygodny sposób przechowywania i przekazywania określonej kolekcji powiązanych danych. Podobnie jak addVegetablesmoże to zepsuć proces gotowania, tworząc nowy garnek do gotowania StringBuilderi wyrzucając go z kalafiorem, tak samo może zrobić to samo z garnkiem JavaBean .

Uważam, że może to być zbyteczny szczegół, ponieważ to, czy jest ostateczny, czy nie, jest szczegółem implementacji.

(Coś w rodzaju deklarowania metod / członków w interfejsie jako publicznych).