que - private final java
¿Por qué uno marcaría las variables locales y los parámetros del método como "finales" en Java? (12)
En Java, puede calificar variables locales y parámetros de método con la palabra clave final.
public static void foo(final int x) {
final String qwerty = "bar";
}
Si lo hace, no podrá reasignar x y qwerty en el cuerpo del método.
Esta práctica empuja su código en la dirección de la inmutabilidad que generalmente se considera un plus. Pero, también tiende a saturar el código con "final" apareciendo en todas partes. ¿Cuál es su opinión sobre la palabra clave final para las variables locales y los parámetros del método en Java?
¿Por qué querrías? Usted escribió el método, por lo que cualquiera que lo modifique siempre podría eliminar la palabra clave final de qwerty y reasignarla. En cuanto a la firma del método, el mismo razonamiento, aunque no estoy seguro de lo que haría con las subclases de su clase ... pueden heredar el parámetro final e, incluso si anulan el método, no podrán des-finalizar x. Pruébalo y descubre si funcionaría.
El único beneficio real, entonces, es si haces que el parámetro sea inmutable y se transfiera a los niños. De lo contrario, estás abarrotando tu código sin ninguna razón particularmente buena. Si no va a obligar a nadie a seguir sus reglas, es mejor que solo deje un buen comentario como por qué no debe cambiar ese parámetro o variable en lugar de dar si el modificador final.
Editar
En respuesta a un comentario, agregaré que si está viendo problemas de rendimiento, hacer que las variables locales y los parámetros sean definitivos puede permitir que el compilador optimice mejor su código. Sin embargo, desde la perspectiva de la inmutabilidad de su código, respaldo mi declaración original.
Aunque crea un poco de desorden, vale la pena ponerlo final . Ides eg eclipse puede poner automáticamente el final si lo configura para hacerlo.
Debe intentar hacer esto, siempre que sea apropiado. Además de servir para avisarte cuando intentas "accidentalmente" modificar un valor, proporciona información al compilador que puede conducir a una mejor optimización del archivo de clase. Este es uno de los puntos en el libro, "Hardcore Java" por Robert Simmons, Jr. De hecho, el libro pasa todo su segundo capítulo sobre el uso de final para promover optimizaciones y prevenir errores de lógica. Las herramientas de análisis estático como el PMD y el SA integrado de Eclipse marcan este tipo de casos por este motivo.
Debido a la naturaleza (ocasionalmente) confusa del comportamiento de " pasar por referencia " de Java, definitivamente estoy de acuerdo con finalizar las var de los parámetros.
La finalización de las var locales parece un poco exagerada IMO.
Dejo que Eclipse lo haga por mí cuando se usan en una clase anónima, que está aumentando debido a mi uso de Google Collection API.
En el caso de variables locales, tiendo a evitar esto. Causa confusión visual, y generalmente es innecesario: una función debe ser lo suficientemente corta o enfocarse en un solo impacto para que pueda ver rápidamente que está modificando algo que no debería ser.
En el caso de los números mágicos, los pondría como un campo privado constante de todos modos en lugar de en el código.
Solo uso final en situaciones donde es necesario (por ejemplo, pasar valores a clases anónimas).
Hacer que las variables locales y los parámetros del método sean final es esencial si desea pasar esos parámetros a clases anónimas, como crear instancias de un subproceso anónimo y querer acceder a esos parámetros en el cuerpo del método run ().
Aparte de eso, no estoy seguro de los beneficios de rendimiento con un mejor rendimiento a través de la optimización del compilador. Depende de la implementación específica del compilador si desea optimizarlo ...
Será bueno saber si alguna estadística de rendimiento usa el final ...
Hacer un parámetro final garantiza que el valor utilizado en cualquier ubicación del método se refiere al valor pasado. De lo contrario, debe analizar mentalmente todo el código que se encuentra sobre una ubicación determinada para saber qué valor tiene el parámetro en ese punto.
Por lo tanto, no usar final hace que tu código sea menos legible y fácil de mantener, todo por sí mismo :)
Las variables locales finales dependen del intento, y es menos importante en mi punto de vista. Depende de lo que ocurra.
Lo hacemos aquí para las variables locales si creemos que no serán reasignadas o no deberían ser reasignadas.
Los parámetros no son definitivos ya que tenemos un Checkstyle-Check que verifica la reasignación de parámetros. Por supuesto, nadie querría volver a asignar una variable de parámetro.
Mi opinión personal es que es una pérdida de tiempo. Creo que el desorden visual y la verbosidad añadida no valen la pena.
Nunca he estado en una situación en la que haya reasignado (recuerde, esto no hace que los objetos sean inmutables, todo lo que significa es que no puede reasignar otra referencia a una variable) una variable errónea.
Pero, por supuesto, es todo preferencia personal ;-)
Sí, hazlo.
Se trata de la legibilidad. Es más fácil razonar sobre los posibles estados del programa cuando sabe que las variables se asignan una vez y solo una vez.
Una alternativa decente es activar la advertencia IDE cuando se asigna un parámetro, o cuando una variable (que no sea una variable de bucle) se asigna más de una vez.
final tiene tres buenas razones:
- las variables de instancia establecidas por el constructor solo se vuelven inmutables
- los métodos que no deben anularse se convierten en definitivos, utilícelos con motivos reales, no de forma predeterminada
- las variables locales o los parámetros que se utilizarán en clases anónimas dentro de un método deben ser finales
Al igual que los métodos, las variables locales y los parámetros no necesitan declararse finales. Como otros dijeron antes, esto hace que el código se vuelva menos legible con muy poco esfuerzo para la optimización del rendimiento del compilador, esta no es una razón real para la mayoría de los fragmentos de código.