Заключні аргументи в інтерфейсних методах - в чому сенс?

В Java цілком законно визначати finalаргументи в інтерфейсних методах і не підкорятись цьому в класі реалізації, наприклад:

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

У наведеному вище прикладі barі bazє протилежні finalвизначення у класі VS інтерфейс.

Таким же чином жодних finalобмежень не застосовується, коли метод одного класу поширює інший, abstractчи ні.

Хоча finalмає деяке практичне значення всередині методу методу класу, чи є якийсь пункт, що визначає finalпараметри методу інтерфейсу?

Здається, це не має жодного сенсу. Відповідно до специфікації мови Java 4.12.4 :

Оголошення змінної остаточним може послужити корисною документацією, що її значення не зміниться і може допомогти уникнути помилок програмування.

Однак finalмодифікатор параметра параметру методу не згадується в правилах узгодження підписів замінених методів, і він не впливає на абонента, лише в тілі програми реалізації. Також, як зазначив Робін у коментарі, finalмодифікатор параметра методу не впливає на сформований код байта. (Це не стосується інших цілей використання final.)

Деякі IDE копіюють підпис методу абстрактно / інтерфейсу під час вставлення способу реалізації у підклас.

Я не вірю, що це має значення для компілятора.

EDIT: Хоча я вважаю, що це було правдою в минулому, я не думаю, що нинішні ІДЕ вже роблять це.

Підсумкові анотації параметрів методу завжди стосуються лише реалізації способу, а ніколи абоненту. Тому немає реальної причини використовувати їх у підписах методів інтерфейсу. Якщо ви не хочете дотримуватися того самого послідовного стандарту кодування, який вимагає остаточних параметрів методу, у всіх підписах методу. Тоді приємно вміти це робити.

Оновлення: Оригінальна відповідь нижче була написана без повного розуміння питання, а тому не стосується безпосередньо питання. :)Тим не менш, вона повинна бути інформативною для тих, хто хоче зрозуміти загальне використання finalключового слова.

Щодо питання, я хотів би процитувати власний коментар знизу.

Я вважаю, що ви не змушені застосовувати остаточний аргумент, щоб ви могли вирішити, чи він повинен бути остаточним чи ні у вашій власній реалізації.

Але так, це здається дивним, що ви можете оголосити це finalв інтерфейсі, але мати його не остаточним у реалізації. Було б більше сенсу, якби:

а. finalключове слово не було дозволено для аргументів методу інтерфейсу (абстрактних) (але ви можете використовувати його в реалізації), або
b. Оголошення аргументу як finalінтерфейсу змусило б його оголосити finalу впровадженні (але не вимушено для нефіналу).

Я можу подумати про дві причини, за якими підпис методу може мати finalпараметри: Beans and Objects ( Насправді, вони обидва однакові, але дещо різні контексти. )

Об'єкти:

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

finalКлючове слово гарантувало , що ми не випадково створити новий місцевий банк для приготування їжі, показуючи помилку компіляції , коли ми намагалися зробити це. Це гарантувало, що курячий бульйон додається до нашого оригінального кухонного посуду, який addChickenотримав метод Порівняйте це з тим, addVegetablesде ми втратили цвітну капусту, тому що вона додала, що в новий місцевий варильний котел замість оригінального горщика він отримав.

Квасоля: це те саме поняття, що і об'єкти (як показано вище) . Квасоля по суті є Objectв Java. Однак квасоля (JavaBeans) використовується в різних додатках як зручний спосіб зберігання та передачі певного збору пов'язаних даних. Так само, як addVegetablesміг зіпсувати процес приготування, створивши новий котел для готування StringBuilderі викинувши його з цвітною капустою, він також міг би зробити те ж саме з варом для готування JavaBean .

Я вважаю, що це може бути зайвою деталлю, оскільки вона остаточна чи ні, це деталь реалізації.

(Сортують як оголошення способів / членів в інтерфейсі загальнодоступним.)