No puedo entender dónde la finalpalabra clave es realmente útil cuando se usa en los parámetros del método.

Si excluimos el uso de clases anónimas, legibilidad y declaración de intenciones, me parece casi inútil.

Hacer cumplir que algunos datos permanezcan constantes no es tan fuerte como parece.

• Si el parámetro es primitivo, no tendrá efecto ya que el parámetro se pasa al método como un valor y cambiarlo no tendrá ningún efecto fuera del alcance.

• Si estamos pasando un parámetro por referencia, entonces la referencia en sí es una variable local y si la referencia se cambia desde dentro del método, eso no tendría ningún efecto desde fuera del alcance del método.

Considere el ejemplo de prueba simple a continuación. Esta prueba pasa aunque el método cambió el valor de la referencia que se le dio, no tiene ningún efecto.

public void testNullify() {
    Collection<Integer> c  = new ArrayList<Integer>();      
    nullify(c);
    assertNotNull(c);       
    final Collection<Integer> c1 = c;
    assertTrue(c1.equals(c));
    change(c);
    assertTrue(c1.equals(c));
}

private void change(Collection<Integer> c) {
    c = new ArrayList<Integer>();
}

public void nullify(Collection<?> t) {
    t = null;
}

Detener la reasignación de una variable

Si bien estas respuestas son intelectualmente interesantes, no he leído la respuesta simple y breve:

Use la palabra clave final cuando desee que el compilador evite que una variable se reasigne a un objeto diferente.

Si la variable es una variable estática, una variable miembro, una variable local o una variable de argumento / parámetro, el efecto es completamente el mismo.

Ejemplo

Veamos el efecto en acción.

Considere este método simple, donde las dos variables ( arg y x ) pueden ser reasignadas a diferentes objetos.

// Example use of this method: 
//   this.doSomething( "tiger" );
void doSomething( String arg ) {
  String x = arg;   // Both variables now point to the same String object.
  x = "elephant";   // This variable now points to a different String object.
  arg = "giraffe";  // Ditto. Now neither variable points to the original passed String.
}

Marque la variable local como final . Esto da como resultado un error del compilador.

void doSomething( String arg ) {
  final String x = arg;  // Mark variable as 'final'.
  x = "elephant";  // Compiler error: The final local variable x cannot be assigned. 
  arg = "giraffe";  
}

En su lugar, marquemos la variable del parámetro como final . Esto también resulta en un error del compilador.

void doSomething( final String arg ) {  // Mark argument as 'final'.
  String x = arg;   
  x = "elephant"; 
  arg = "giraffe";  // Compiler error: The passed argument variable arg cannot be re-assigned to another object.
}

Moraleja de la historia:

Si desea asegurarse de que una variable siempre apunte al mismo objeto, marque la variable como final .

Nunca reasigne argumentos

Como buena práctica de programación (en cualquier lenguaje), nunca debe reasignar una variable de parámetro / argumento a un objeto que no sea el objeto pasado por el método de llamada. En los ejemplos anteriores, nunca se debe escribir la línea arg =. Como los humanos cometen errores y los programadores son humanos, solicitemos ayuda al compilador. Marque cada variable de parámetro / argumento como 'final' para que el compilador pueda encontrar y marcar tales reasignaciones.

En retrospectiva

Como se señaló en otras respuestas ... Dado el objetivo de diseño original de Java de ayudar a los programadores a evitar errores tontos, como leer más allá del final de una matriz, Java debería haber sido diseñado para aplicar automáticamente todas las variables de parámetro / argumento como 'final'. En otras palabras, los argumentos no deben ser variables . Pero la retrospectiva es una visión 20/20, y los diseñadores de Java tenían las manos ocupadas en ese momento.

Entonces, ¿siempre agregar finala todos los argumentos?

¿Debemos agregar finala todos y cada uno de los parámetros del método que se declara?

• En teoría sí.
• En la práctica, no.
  ➥ Agregue finalsolo cuando el código del método es largo o complicado, donde el argumento puede confundirse con una variable local o miembro y posiblemente reasignarse.

Si acepta la práctica de no reasignar nunca un argumento, estará inclinado a agregar un finala cada uno. Pero esto es tedioso y hace que la declaración sea un poco más difícil de leer.

Para el código simple corto donde el argumento es obviamente un argumento, y no una variable local ni una variable miembro, no me molesto en agregar el final. Si el código es bastante obvio, sin posibilidad de que yo ni ningún otro programador realice tareas de mantenimiento o refactorice accidentalmente confundiendo la variable de argumento como algo más que un argumento, entonces no se moleste. En mi propio trabajo, agrego finalsolo código más largo o más involucrado donde un argumento puede confundirse con una variable local o miembro.

Otro caso agregado para la integridad

public class MyClass {
    private int x;
    //getters and setters
}

void doSomething( final MyClass arg ) {  // Mark argument as 'final'.

   arg =  new MyClass();  // Compiler error: The passed argument variable arg  cannot be re-assigned to another object.

   arg.setX(20); // allowed
  // We can re-assign properties of argument which is marked as final
 }

A veces es bueno ser explícito (para facilitar la lectura) que la variable no cambia. Aquí hay un ejemplo simple donde usar finalpuede ahorrar algunos posibles dolores de cabeza:

public void setTest(String test) {
    test = test;
}

Si olvida la palabra clave 'this' en un setter, entonces la variable que desea establecer no se establece. Sin embargo, si usó la finalpalabra clave en el parámetro, el error se detectaría en el momento de la compilación.

Sí, excluyendo clases anónimas, legibilidad y declaración de intenciones es casi inútil. Sin embargo, ¿son inútiles esas tres cosas?

Personalmente, tiendo a no usar finalpara variables y parámetros locales a menos que esté usando la variable en una clase interna anónima, pero ciertamente puedo ver el punto de aquellos que quieren dejar en claro que el valor del parámetro en sí no cambiará (incluso si el objeto al que hace referencia cambia su contenido). Para aquellos que encuentran que eso aumenta la legibilidad, creo que es algo completamente razonable.

Su punto sería más importante si alguien eran en realidad afirmando que se mantenga constante de datos de una manera que no lo hace - pero no puedo recordar haber visto ninguna de dichas reivindicaciones. ¿Estás sugiriendo que hay un cuerpo significativo de desarrolladores que sugiere que finaltiene más efecto de lo que realmente tiene?

EDITAR: Realmente debería haber resumido todo esto con una referencia de Monty Python; la pregunta parece algo similar a preguntar "¿Qué han hecho los romanos por nosotros?"

Déjame explicarte un poco sobre el único caso en el que tienes que usar el final, que Jon ya mencionó:

Si crea una clase interna anónima en su método y usa una variable local (como un parámetro de método) dentro de esa clase, entonces el compilador lo obliga a hacer que el parámetro sea final:

public Iterator<Integer> createIntegerIterator(final int from, final int to)
{
    return new Iterator<Integer>(){
        int index = from;
        public Integer next()
        {
            return index++;
        }
        public boolean hasNext()
        {
            return index <= to;
        }
        // remove method omitted
    };
}

Aquí los parámetros fromy todeben ser finales para que puedan usarse dentro de la clase anónima.

La razón de este requisito es esta: las variables locales viven en la pila, por lo tanto, existen solo mientras se ejecuta el método. Sin embargo, la instancia de clase anónima se devuelve del método, por lo que puede vivir mucho más tiempo. No puede preservar la pila, porque es necesaria para las llamadas de método posteriores.

Entonces, lo que Java hace es colocar copias de esas variables locales como variables de instancia ocultas en la clase anónima (puede verlas si examina el código de bytes). Pero si no fueran finales, uno podría esperar que la clase anónima y el método vean los cambios que el otro hace a la variable. Para mantener la ilusión de que solo hay una variable en lugar de dos copias, tiene que ser final.

Yo uso final todo el tiempo en los parámetros.

¿Agrega eso tanto? Realmente no.

¿Lo apagaría? No.

La razón: encontré 3 errores en los que la gente había escrito código descuidado y no había podido establecer una variable miembro en los accesores. Todos los errores resultaron difíciles de encontrar.

Me gustaría ver que esto sea el predeterminado en una futura versión de Java. El paso por valor / referencia hace tropezar a un montón de programadores junior.

Una cosa más ... mis métodos tienden a tener un número bajo de parámetros, por lo que el texto adicional en una declaración de método no es un problema.

Usar final en un parámetro de método no tiene nada que ver con lo que sucede con el argumento en el lado del llamante. Solo tiene la intención de marcarlo como que no cambia dentro de ese método. Cuando trato de adoptar un estilo de programación más funcional, veo el valor en eso.

Personalmente, no uso final en los parámetros del método, porque agrega demasiado desorden a las listas de parámetros. Prefiero hacer cumplir que los parámetros del método no se cambien a través de algo como Checkstyle.

Para las variables locales que uso final siempre que sea posible, incluso dejo que Eclipse lo haga automáticamente en mi configuración para proyectos personales.

Ciertamente me gustaría algo más fuerte como C / C ++ const.

Como Java pasa copias de los argumentos, siento que la relevancia de esto finales bastante limitada. Supongo que el hábito proviene de la era de C ++, donde podría prohibir que se cambie el contenido de referencia haciendo un const char const *. Siento que este tipo de cosas te hace creer que el desarrollador es inherentemente estúpido como un maldito y necesita estar protegido contra todos los personajes que escribe. Con toda humildad, puedo decir que escribo muy pocos errores aunque omito final(a menos que no quiera que alguien anule mis métodos y clases). Tal vez solo soy un desarrollador de la vieja escuela.

Nunca uso final en una lista de parámetros, solo agrega desorden como han dicho los encuestados anteriores. También en Eclipse puede configurar la asignación de parámetros para generar un error, por lo que usar final en una lista de parámetros me parece bastante redundante. Curiosamente, cuando habilité la configuración de Eclipse para la asignación de parámetros que generaba un error, captó este código (así es como recuerdo el flujo, no el código real):

private String getString(String A, int i, String B, String C)
{
    if (i > 0)
        A += B;

    if (i > 100)
        A += C;

    return A;
}

Jugando al abogado del diablo, ¿qué tiene de malo hacer esto?

Respuesta corta: finalayuda un poco, pero ... usa la programación defensiva en el lado del cliente.

De hecho, el problema finales que solo impone que la referencia no se modifique, permitiendo alegremente que los miembros del objeto a los que se hace referencia muten, sin que el llamante lo sepa. Por lo tanto, la mejor práctica a este respecto es la programación defensiva en el lado de la persona que llama, creando instancias profundamente inmutables o copias profundas de objetos que están en peligro de ser asaltados por API sin escrúpulos.

Una razón adicional para agregar declaraciones finales a los parámetros es que ayuda a identificar las variables que necesitan ser renombradas como parte de una refactorización de "Método de extracción". Descubrí que agregar el final a cada parámetro antes de comenzar una refactorización de métodos grandes me dice rápidamente si hay algún problema que deba abordar antes de continuar.

Sin embargo, generalmente los elimino como superfluos al final de la refactorización.

Seguimiento de lo que postea Michel. Yo mismo hice otro ejemplo para explicarlo. Espero que pueda ayudar.

public static void main(String[] args){
    MyParam myParam = thisIsWhy(new MyObj());
    myParam.setArgNewName();

    System.out.println(myParam.showObjName());
}

public static MyParam thisIsWhy(final MyObj obj){
    MyParam myParam = new MyParam() {
        @Override
        public void setArgNewName() {
            obj.name = "afterSet";
        }

        @Override
        public String showObjName(){
            return obj.name;
        }
    };

    return myParam;
}

public static class MyObj{
    String name = "beforeSet";
    public MyObj() {
    }
}

public abstract static class MyParam{
    public abstract void setArgNewName();
    public abstract String showObjName();
}

Del código anterior, en el método thisIsWhy () , en realidad no asignamos el [argumento MyObj obj] a una referencia real en MyParam. En cambio, solo usamos el [argumento MyObj obj] en el método dentro de MyParam.

Pero después de que terminemos el método thisIsWhy () , ¿ debería existir el argumento (objeto) MyObj?

Parece que debería, porque podemos ver en main todavía llamamos al método showObjName () y necesita llegar a obj . MyParam todavía usa / alcanza el argumento del método, ¡incluso el método ya fue devuelto!

Cómo Java realmente logra esto es generar una copia también es una referencia oculta del argumento MyObj obj dentro del objeto MyParam (pero no es un campo formal en MyParam para que no podamos verlo)

Como llamamos "showObjName", usará esa referencia para obtener el valor correspondiente.

Pero si no pusimos el argumento final, lo que lleva a una situación, podemos reasignar una nueva memoria (objeto) al argumento MyObj obj .

¡Técnicamente no hay choque en absoluto! Si se nos permite hacer eso, a continuación será la situación:

1. Ahora tenemos un punto oculto [MyObj obj] a una [Memoria A en el montón] ahora en vivo en el objeto MyParam.
2. También tenemos otro [MyObj obj] que es el punto de argumento para que una [Memoria B en el montón] ahora viva en el método thisIsWhy.

Sin choque, pero "¡¡¡CONFUSENTE !!" Porque todos usan el mismo "nombre de referencia" que es "obj" .

Para evitar esto, configúrelo como "final" para evitar que el programador haga el código "propenso a errores".