¿Puede el uso excesivo del daño final más que el bien?

¿Por qué las personas son tan enfáticas en hacer que todas las variables dentro de una clase sean "definitivas"? No creo que haya ningún beneficio real al agregar variables locales finales a las privadas, o realmente utilizar el final para cualquier cosa que no sean constantes y pasar variables a clases internas anónimas.¿Puede el uso excesivo del daño final más que el bien?

No estoy buscando comenzar ningún tipo de guerra de llama, honestamente quiero saber por qué esto es tan importante para algunas personas. ¿Me estoy perdiendo de algo?

Fuente

2010-02-10 Tim Michalski

"Use final liberally" - http://www.javapractices.com/topic/TopicAction.do?Id=23 – Nate

Tiene respuestas que señalan los beneficios, quiero preguntar dónde cree que podría dañar ? – Thilo

¿Qué es una "variable local privada"? ¿Te refieres a un campo privado o una variable local? Las personas pueden tener opiniones diferentes sobre los dos casos, y su pregunta no aclara de qué está hablando, o si se refiere a ambos. –

Intención. Otras personas que modifiquen su código no cambiarán los valores que no deberían cambiar.
Las optimizaciones del compilador se pueden realizar si el compilador sabe que el valor de un campo nunca cambiará.

Además, si todas las variables en una clase es final (como se refiere en su puesto), entonces usted tiene una clase inmutable (siempre y cuando no exponer referencias a las propiedades mutables), que es una excelente manera de lograr la seguridad de hilo.

Fuente

2010-02-10 05:32:08 danben

¿Realmente ayuda con las optimizaciones? Si una variable no se cambia después de la inicialización, el compilador determinará si la variable está marcada como final o no. –

Sí, Michael, también he oído esto. dónde aprendiste esto? Parece que no puedo encontrar ningún documento que descomponga estas optimizaciones del compilador. –

Si agrega un valor final a todas las variables, incluso a las variables de método locales, porque cree que la referencia a la que apunta la variable no se debe sobrescribir, ¿no es eso un poco sobreprotector? Los malos codificadores harán cosas malas, los buenos codificadores hacen cosas buenas. No hay nada que evite que un codificador incorrecto sea estúpido y sobrescriba una referencia de objeto. El uso excesivo de "final" no detiene eso, de hecho, probablemente adormece a la gente a la importancia real de usar el final. Este es mi punto, supongo. –

Marca que no estoy esperando que ese valor cambie, que es documentación gratuita. La práctica es porque claramente comunica la intención de esa variable y obliga al compilador a verificar eso. Más allá de eso, permite al compilador realizar optimizaciones.

Fuente

2010-02-10 05:31:23

¿Quiere decir que no espera que cambie la referencia de la variable? ¿Son estas clases privadas o variables locales? –

Cualquier cosa: cuando alguien lee el código, puede ver que el valor (o referencia) que estoy asignando en esa línea es lo que le estoy asignando en esa línea mientras dure el alcance. En cuanto a hacer campos de miembros de clase 'final', obliga a establecer esas variables en cada constructor, que es una buena protección contra errores de lógica. –

Sí, soy bueno con el uso final para hacer una clase inmutable. Una buena característica en realidad. Lo que tengo dificultades es cuando alguien usa variables finales dentro de un método. BigDecimal myMethod privado (dinero final BigDecimal) { final MyCalc calc = new MyCalc(); return calc.doubleMyMoney (dinero); } No veo la necesidad de hacer MyCalc definitivo. ¿Esto realmente ayuda a la recolección de basura? ¿Hace que el código sea más eficiente? –

Creo que el uso de los valores finales sobre internos de una clase es excesivo, a menos que la clase probablemente se herede. La única ventaja es alrededor de las optimizaciones del compilador, que seguramente se beneficiarán.

Fuente

2010-02-10 05:33:36 sangupta

Cuando dices "excesivo", ¿qué quieres decir? Es decir, ¿de qué es demasiado? – danben

personas están mencionando las optimizaciones del compilador, pero he escuchado que con los avances recientes en el compilador, la palabra clave final no ayuda al optimizador. No he podido encontrar documentación oficial sobre esto, así que no estoy seguro de dónde está obteniendo este rumor. –

Cada variable de clase individual (que hace una clase inmutable) y cada variable local dentro de los métodos. Muchas de las líneas de código en una clase comienzan con "final". Encuentro esto muy difícil de leer y estoy luchando con los beneficios. –

Es importante porque la inmutabilidad es importante, especialmente cuando se trata de un modelo de memoria compartida. Si algo es inmutable, entonces es seguro para los subprocesos, eso lo convierte en un buen argumento para seguir como una mejor práctica.

http://www.artima.com/intv/blochP.html

Fuente

2010-02-10 05:34:18 Jon

Sí, pero eso es irrelevante para las variables locales y los parámetros porque solo son visibles para el hilo actual. –

A veces es necesario que sea definitivo, a veces no, depende de la situación. Una mejor práctica siempre tiene excepciones a la regla. – Jon

Clases internas anónimas es la única vez que NECESITA que sean definitivas. – Robin

Un proyecto que estoy trabajando actualmente en la instalación es de manera que cada vez que se presiona "Guardar" en Eclipse, se añade el modificador final a cada variable o campo que no se cambió en el código. Y aún no ha lastimado a nadie.

Fuente

2010-02-10 06:07:36 Bozho

@Bozho: ¿Eclipse lo hace de manera predeterminada o necesita algún complemento? ¿Sabes si hay algo similar para IntelliJ IDEA? – SyntaxT3rr0r

@WizardOfOdds: no, es un generador de hormigas, que a su vez llama a una tarea personalizada de la plataforma de comercio electrónico que estamos utilizando. – Bozho

Uno de los beneficios de la programación concurrente que no se ha mencionado todavía:

campos finales están garantizados para ser inicializado cuando se haya completado la ejecución del constructor.

Fuente

2010-02-10 10:27:08 starblue

Este es un punto CRUCIAL. No puedo votar lo suficiente. –

Hay muchas buenas razones para usar el final, como se indica en otra parte. Un lugar donde no vale la pena, IMO, está en los parámetros de un método. Estrictamente hablando, la palabra clave agrega valor aquí, pero el valor no es lo suficientemente alto como para soportar la sintaxis fea. Prefiero expresar ese tipo de información a través de pruebas unitarias.

Fuente

2010-02-10 15:12:10

La desventaja, es que

annoy it is hard 
annoy to read 
annoy code or anything 
annoy else when it all 
annoy starts in the 
annoy same way

Aparte del uso racional para crear constantes y la prevención de la subclasificación/primordial, que es una preferencia personal en la mayoría de los casos, ya que muchos creen que los beneficios de la "muestra la intención del programador" son superado por la legibilidad del código real. Muchos prefieren un poco menos de verbosidad.

En cuanto a las optimizaciones, esa es una mala razón para usarlo (meaningless in many cases). Es la peor forma de micro optimización y en los días de JIT no sirve para nada.

Sugeriría usarlo si lo prefiere, no lo haga si usted es lo que prefiere. Como todo se reducirá a argumentos religiosos en muchos casos, no te preocupes por eso.

Fuente

2010-02-10 19:19:55 Robin

¿Puede el uso excesivo del daño final más que el bien?

Respuesta

Cuestiones relacionadas