¿Por qué la palabra clave 'final' se usa tan poco en la industria? [cerrado]

Sospecho que la razón por la que no lo ves es porque el JDK está diseñado para extenderse (es la base desde la que se basan todos tus programas). No sería raro en absoluto que el código de la aplicación lo use. Tampoco esperaría ver mucho de eso en el código de la biblioteca (ya que las bibliotecas también están diseñadas para la extensión).

Intente ver algunos buenos proyectos de código abierto y creo que encontrará más.

A diferencia de lo que está viendo en Java, en el mundo .NET, he escuchado el argumento muchas veces de que las clases deberían ser sealed (similar a final aplicado a una clase) de manera predeterminada, y que el desarrollador debe deseleccionarlo explícitamente.

El problema con el uso de final para transmitir que algo es de solo lectura es que solo funciona con tipos primitivos como int , char , etc. ) puntero. Como resultado, cuando usa la palabra clave final en un objeto, solo está diciendo que la referencia es de solo lectura, que el objeto en sí todavía es mutable.

Se podría haber usado más si realmente hizo que el objeto fuera de solo lectura. En C ++, eso es exactamente lo que hace const y, como resultado, es una palabra clave mucho más útil y muy utilizada.

Un lugar donde utilizo la palabra clave final en gran medida es con parámetros para evitar cualquier confusión creada por cosas como esta:

public void someMethod(FancyObject myObject) {
    myObject = new FancyObject();
    myObject.setProperty(7);
}
...
public static void main(final String[] args) {
    ...
    FancyObject myObject = new FancyObject();
    someOtherObject.someMethod(myObject);
    myObject.getProperty(); // Not 7!
}

En este ejemplo, parece obvio por qué esto no funciona, pero si someMethod(FancyObject) es grande y puede surgir una confusión complicada. ¿Por qué no evitarlo?

También es parte de los estándares de codificación de Sun (u Oracle ahora supongo).

Estoy de acuerdo en que la palabra clave final mejora la legibilidad. Lo hace mucho más fácil de entender cuando un objeto es inmutable. Sin embargo, en Java es extremadamente detallado, particularmente (en mi opinión) cuando se usa en parámetros. Esto no quiere decir que las personas no deberían usarlo porque es detallado, sino que no lo usan porque es detallado.

Algún otro idioma, como scala, hace que sea mucho más fácil hacer declaraciones finales ( val ). En estos idiomas, las declaraciones finales pueden ser más comunes que las variables.

Tenga en cuenta que hay muchos usos diferentes de la palabra clave final. Su publicación cubre principalmente los artículos 2 y 3.

1. Clases finales (JLS 8.1.1.2)
2. campos finales (JLS 8.3.1.2)
3. Métodos finales (JLS 8.4.3.3)
4. Variables finales (JLS 4.12.4)

Bueno, para empezar, las convenciones del Código oficiales no favorecen ni prohíben el uso particular de% código%. Es decir, los desarrolladores de JDK son libres de elegir la forma que prefieran.

No puedo leer su mente, pero para mí, la preferencia sobre si usar final o no ha sido una cuestión de enfoque. Es cuestión de si tengo suficiente tiempo para concentrarme completamente en el código o no .

• Digamos que en uno de mis proyectos podríamos permitirnos gastar un promedio de día en unas 100 líneas de código. En este proyecto, tuve una percepción distinta de final como una basura que simplemente oscurece las cosas que ya están lo suficientemente claras en el código. Parece que los desarrolladores de JDK también caen en esa categoría.
  
  Por otro lado, fue totalmente opuesto en otro proyecto, donde pasamos un promedio de hora en 100 líneas de código. Ahí, me encontré disparando final como un arma de mascar por mi cuenta y en el código de otros, simplemente porque era la forma más rápida de detectar la intención del tipo que la escribió antes que yo y, de manera similar, la forma más rápida de comunicar mi Propio intento para el tipo que trabajará en mi código más adelante.

  

También puede proporcionar un pequeño impulso al JIT, y si bien es muy limitado, no puede dañar

El razonamiento como el de arriba es resbaladizo. Optimización prematura puede dañar; Donald Knuth llega tan lejos como para llamarlo "la raíz de todo mal" . No dejes que te atrape. Escriba el código tonto .

Recientemente descubrí la alegría de la función "Guardar acciones" en el IDE de Eclipse. Puedo forzarlo para reformatear mi código, insertar las anotaciones @Override faltantes y hacer cosas ingeniosas como eliminar paréntesis innecesarios en expresiones o poner la palabra clave final en todas partes automáticamente cada vez que golpeo ctrl + S . Activé algunos de esos disparadores y, muchacho, ¡ayuda mucho!

Resultó que muchos de esos factores desencadenantes actúan como una rápida comprobación de validez de mi código.

• Tenía la intención de anular un método pero la anotación no apareció cuando presioné ctrl + s ? - ¡Quizás jaleé los tipos de parámetros en alguna parte!
• ¿Se han eliminado algunos paréntesis del código al guardar? - tal vez esa expresión lógica es demasiado difícil para que un programador pueda moverse rápidamente. De lo contrario, ¿por qué agregaría esos paréntesis en primer lugar?
• Ese parámetro o variable local no es final . ¿Tiene tener para cambiar su valor?

Resultó que cuanto menos variables cambian, menos problemas tengo en el momento de la depuración. ¿Cuántas veces estuvo siguiendo el valor de alguna variable solo para descubrir que de alguna manera cambia de, digamos, 5 a 7? "¡¿Cómo diablos podría ser ?!" te preguntas y pasas las próximas dos horas entrando y saliendo de innumerables métodos para descubrir que has cometido un error en tu lógica. Y para solucionarlo, debe agregar una bandera más, un par de condiciones y cambiar cuidadosamente algunos valores aquí y allá.

¡Oh, odio la depuración! Cada vez que ejecuto el depurador siento que mi tiempo se está agotando y desesperadamente necesito ese tiempo para hacer que al menos algunos de mis sueños de la infancia se hagan realidad. Al diablo con la depuración! final s significa que no hay más cambios de valor misteriosos. Más final s = > partes menos endebles en mi código = > menos errores = > ¡Más tiempo para hacer cosas buenas!

En cuanto a final de clases y métodos realmente no me importa. Me encanta el polimorfismo. Polimorfismo significa reutilizar significa menos código significa menos errores. JVM hace un trabajo bastante bueno con la desvirtualización y el método de incorporación de todos modos, por lo que no veo un valor en las posibilidades de reutilización de código para obtener beneficios de rendimiento poco sólidos.

Ver todos esos final s en el código es un poco molesto al principio y también toma tiempo acostumbrarse. Algunos de mis compañeros de equipo todavía se sorprenden al ver tantas palabras clave final . Me gustaría que hubiera un ajuste en el IDE para colorear la sintaxis especial para ello. Me encantaría cambiarlo a un tono de gris (como las anotaciones) para que no se distraigan al leer el código. Eclipse actualmente tiene un color separado para return y todas las demás palabras clave, pero no para final .