Argumentos finais nos métodos de interface - qual é o objetivo?

Em Java, é perfeitamente legal definir finalargumentos nos métodos de interface e não obedecer isso na classe de implementação, por exemplo:

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

No exemplo acima, bare bazpossui as finaldefinições opostas na classe VS a interface.

Da mesma maneira, nenhuma finalrestrição é imposta quando um método de classe estende outro, abstractou não.

Embora finaltenha algum valor prático dentro do corpo do método de classe, há algum ponto em especificar finalparâmetros de método de interface?

Parece que não faz sentido. De acordo com a Java Language Specification 4.12.4 :

Declarar uma variável final pode servir como documentação útil de que seu valor não será alterado e pode ajudar a evitar erros de programação.

No entanto, um finalmodificador em um parâmetro de método não é mencionado nas regras para correspondência de assinaturas de métodos substituídos e não tem efeito no chamador, apenas no corpo de uma implementação. Além disso, conforme observado por Robin em um comentário, o finalmodificador em um parâmetro de método não afeta o código de bytes gerado. (Isso não é verdade para outros usos de final.)

Alguns IDEs copiarão a assinatura do método abstract / interface ao inserir um método de implementação em uma subclasse.

Não acredito que faça alguma diferença para o compilador.

Edição: Embora eu acredite que isso era verdade no passado, eu não acho que os IDEs atuais façam isso mais.

As anotações finais dos parâmetros do método sempre são relevantes apenas para a implementação do método, nunca para o responsável pela chamada. Portanto, não há motivo real para usá-los nas assinaturas de métodos de interface. A menos que você queira seguir o mesmo padrão de codificação consistente, que requer parâmetros finais do método, em todas as assinaturas do método. Então é bom poder fazer isso.

Atualização: A resposta original abaixo foi escrita sem o entendimento completo da pergunta e, portanto, não a aborda diretamente. :)No entanto, deve ser informativa para quem deseja entender o uso geral da finalpalavra-chave.

Quanto à questão, gostaria de citar meu próprio comentário abaixo.

Acredito que você não seja forçado a implementar a finalidade de um argumento para deixá-lo livre para decidir se deve ser final ou não em sua própria implementação.

Mas sim, parece bastante estranho que você possa declará-lo finalna interface, mas não final na implementação. Teria feito mais sentido se:

uma. finala palavra-chave não era permitida para argumentos do método de interface (abstrato) (mas você pode usá-la na implementação) ou
b. declarar um argumento como finalna interface o forçaria a ser declarado finalna implementação (mas não forçado para não finais).

Posso pensar em duas razões pelas quais uma assinatura de método pode ter finalparâmetros: Beans e Objetos (na verdade, ambos são a mesma razão, mas contextos ligeiramente diferentes ) .

Objetos:

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

A finalpalavra-chave garantiu que não criaríamos acidentalmente uma nova panela local , mostrando um erro de compilação quando tentamos fazê-lo. Isso garantiu que o caldo de galinha fosse adicionado à panela original que o addChickenmétodo obteve. Compare isso com o local addVegetablesonde perdemos a couve-flor, porque ela foi adicionada a uma nova panela de cozinha local, em vez da panela original.

Feijão: é o mesmo conceito que objetos (como mostrado acima) . Beans são essencialmente Objects em Java. No entanto, os beans (JavaBeans) são usados ​​em vários aplicativos como uma maneira conveniente de armazenar e transmitir uma coleção definida de dados relacionados. Assim como addVegetablespoderia atrapalhar o processo de criação, criando uma nova panela StringBuildere jogando-a fora com a couve-flor, também poderia fazer o mesmo com uma panela JavaBean .

Acredito que possa ser um detalhe supérfluo, pois se é final ou não, é um detalhe de implementação.

(Mais ou menos como declarar métodos / membros em uma interface como pública.)