¿Por qué declarar que un argumento de función es definitivo?

Actualmente estoy trabajando en mi camino a través del libro "Enséñate desarrollo de aplicaciones de Android en 24 horas" publicado por Sams. Soy relativamente nuevo en Java, Android o de otra manera. Tengo una base muy sólida en ActionScript 3, que tiene suficientes similitudes con Java que el lenguaje en sí no es difícil de entender, pero todavía tengo algunas preguntas sobre la lógica detrás de algunas de las muestras de código en el libro. Por ejemplo, he aquí una función que viene con el código de ejemplo para la Hora 9:¿Por qué declarar que un argumento de función es definitivo?

private void processScores(final TableLayout scoreTable, 
     XmlResourceParser scores) throws IOException, XmlPullParserException{

En esta función de firma, los autores han declarado el argumento scoreTable como definitiva. Estoy un poco desconcertado sobre por qué lo hicieron. No se me ocurriría siquiera intentar asignar un nuevo valor al argumento de función scoreTable (se considera una mala práctica en ActionScript). Además, no he visto a nadie hacer esto en ninguna de las Java del mundo real que he examinado o transferido a AS3.

¿Hay algo específico sobre el desarrollo de Android que hace que sea necesario a veces declarar ciertos argumentos de funciones como definitivo?

¿Por qué el objeto TableLayout se declara final, pero no el XmlResourceParser?

Fuente

2011-02-08 scriptocalypse

DUPE - http://stackoverflow.com/questions/4162531/making-java-method-arguments-as-final – Robino

Existen dos razones principales por las que quizás desee marcar un argumento final. Primero, si planea usar el argumento en una clase interna anónima, debe marcarlo final para poder hacer referencia a él en esa clase. Este es en realidad un caso de uso bastante común para marcar argumentos finales.

La otra razón común para marcar argumentos final es evitar sobrescribirlos accidentalmente. Si realmente no desea cambiar los argumentos, entonces quizás debería marcarfinal para que si lo hace, obtendrá el error en tiempo de compilación en lugar de descubrir en tiempo de ejecución que su código tiene un error .

Fuente

2011-02-08 06:11:12 templatetypedef

Gracias, definitivamente no conozco este requisito con respecto a las clases internas anónimas. Entonces, ¿sería seguro inferir basado en el hecho de que solo el objeto TableLayout se declara final y que esta función lo usa estrictamente como protección contra la codificación descuidada? ¿Por qué sería más especial en este caso que XmlResourceParser? ¿O son solo preguntas a las que los autores del libro podrían conocer las respuestas? – scriptocalypse

@ scriptocalypse- Sabes, no estoy seguro. Supongo que es para el caso anónimo de clase interna, ya que de lo contrario tienes razón y tiene más sentido marcarlos como finales. No puedo hablar por los autores, sin embargo; ¿Tal vez podrías contactarte con ellos o con el editor? – templatetypedef

En realidad, el "caso de clase interno anónimo" en sí mismo es una muy buena razón. En Android, a menudo uso las clases 'OnClickListener' y' AsyncTask' y la capacidad de reutilizar estas variables directamente dentro de ellas es útil. Otro enlace para revisión: http://developer.android.com/guide/practices/design/performance.html#myths. –

¿Por qué declarar que un argumento de función es definitivo?

Respuesta

Cuestiones relacionadas