Inicializadores (Inicializadores de Instancia)
Continuando con el post anterior sobre bloques estáticos, pero ahora toca definir los usos, ventajas y desventajas de los inicializadores tambíen conocidos como "inicializadores de instancia", como se puede deducir estos bloques están dedicados para colocar bloques de código para inicializar variables que pertenezcan a la instancia.
Los inicializadores de instancia son bloques de código que pertenecen a la instancia, y se declaran dentro de la clase entre llaves como a continuación se muestra en el siguiente código:
Salida:
Ejemplo1
com.ejemplos.inicializadores.Ejemplo1
class java.lang.Object
Constructor
Como se puede observar en la salida resultante del ejemplo anterior los inicializadores estáticos se ejecutan antes de la ejecución del constructor, por lo tanto estos inicializadores solo se ejecutan cuando se va crear una instancia, por lo cual se les llama inicializadores de instancia, cabe destacar que si la clase tiene varios constructores, el o los inicializador(es) se ejecutaran independientemente de que constructor se utilice para crear una instancia de la clase, veamos el siguiente ejemplo:
Salida:
Ejemplo2
com.ejemplos.inicializadores.Ejemplo2
Constructor
Ejemplo2
com.ejemplos.inicializadores.Ejemplo2
Constructor con mensaje
Al igual que los inicializadores estáticos, los inicializadores de instancia ofrecen la ventaja de poder realizar calculos para la inicialización de variables y manejar excepciones si se presentan durante la inicialización como a continuación se presenta el siguiente ejemplo:
Salida:
Valor 0 es invalido
0
Un último ejemplo muestra el uso de inicializadores de instancia en claes anónimas, y es que se puede tener la necesidad de inicializar alguna variable y como las clases anónimas no permiten definir constructores implicitamente, un inicializador de instancia es de mucha utilidad:
Salida:
Introduce un numero:
4
Numero introducido: 4
Ya para finalizar:
Usos comunes:
1.- Inicialización de variables o constantes de forma eager.
2.- Realizar calculos y/o asignaciones de variables de instancia.
3.- Colocar código que se necesite ejecutar al crear una instancia de una clase anónima.
Ventajas:
1.-Puedes ejecutar asignaciones a constantes y variables de instancia que requieran la ejecución de algún calculo sin la necesidad de crear una instancia.
2.-Si el código que utilizas para inicializar una constante o variable estática causa excepciones, las puedes manejar en bloques try-catch sin la necesidad de usar metodos estáticos o de instancia.
3.-En esta ocasión a diferencia de los inicializadores estáticos, los inicializadores de instancia pueden invocar a "super" y "this" por pertenecer a una instancia.
Limitaciones o desventajas:
1.-El tamaño de los inicializadores de instancia no debe exceder los 64kb.
2.-No se pueden lanzar excepciones checadas * (checa la sección de comentarios el de @jpaul)
3.-No se puede regresar ningun valor o tipo.
Y como siempre si en algo me equivoco o algo me falto pues no duden en comentar.
Saludos.
- Cid's blog
- Inicie sesión o regístrese para enviar comentarios
Re: inicializadores
He aquí una “aplicación”.
De este código, tenemos el siguiente método:
Si lo cambiamos para utilizar inicializadores no estáticos, quedaría de la siguiente manera:
¿Y las variables, apá? ...
~~~
Buen ejemplo
Me perdí un poco porque creí que el uso estaba en las lambdas, pero despues vi el segundo código que es en donde los aplicas y mandas a llamar a setRepeats y start.
Esta claro que no solo se usan para inicializar variables, si no para realizar tareas que inicialicen algún entorno que necesite el objeto.
Gracias por el ejemplo.
Saludos.
Orden
Más precisamente:
~~~
correcto
Salida:
Re: excepciones checadas
Sí es posible. Sin embargo, todos los contructores de la clase deben incluir tales excepciones en la clausula
Si revisamos el bytecode con el comando "
Encontraremos que el compilador hace un merge del código de los inicializadores no estáticos y de cada constructor, según corresponda.
~~~
Muy bueno
No se si corregir o no el post original por aquellos que no leen los comentarios hace tiempo vi como interpretar el bytecode y tampoco hice mucho caso pero bueno por aquí dejo un link que les sea útil a los demas para entender lo que coloco @jpaul
bytecode
¿Confusas?
Adicionalmente, cuando éstas construcciones son pasadas por alguna herramienta de análisis estático de software, ésta podría quejarse amargamente. He aquí dos ejemplos de lo anterior:
PMD
Esta herramienta tiene la siguiente regla:
Es decir, que se trata de algo confuso.
SonarQube
Esta herramienta tiene la siguiente regla:
Es decir, que muchos desarrolladores se podrían confundir. No especifica si principiantes o avanzados. Se recomienda sustituir esta construcción por su equivalente. Después de todo, esto mismo hace el compilador.
¿Raras? Sí, es cierto. Intento recordar ... ninguna API que las contenga viene a mi mente. Pero, -el meollo del asunto-, ¿son confusas estas construcciones? Ojalá la comunidad pudiera dar su opinión al respecto.
Notas
~~~
sí lo son
Respecto de lo último que dices: no sabes ai alguna API las contiene, porque no aparece a nivel API. Si no tienes los fuentes de una biblioteca, no puedes saber si usan eso en su código o no, porque el compilador no lo conserva tal cual sino que lo refactoriza a constructores o pasa la inicialización a los campos correspondientes.
En mi opinión, sí son confusas, por varias razones. Imagina que te integras a un equipo que lleva rato trabajando en un proyecto:
De entrada, si no conoces bien la especificación completa del lenguaje, cuando te topes con ese código vas a pasar un buen rato rascándote la cabeza preguntándote qué hace, o vas a decidir que ese código es intocable y ps mejor le das la vuelta a ver cómo.
Si navegando en un IDE llegas a un método que usa un campo, y quieres saber cómo se inicializa ese campo, y vas a su declaración, te muestra que es null. Luego ves que no hay un setter. Y si el IDE no te muestra en la vista de estructura de manera clara los inicializadores de instancia, vas a terminar ejecutando la aplicación con debugger para ver dónde carajos se inicializa ese valor, lo cual te puede tomar bastante más tiempo que un simple análisis estático del código; en IntelliJ IDEA por ejempo dice "class initializer" y te muestra los campos inicializados, pero en Eclipse sólo salen bloques que dicen {...} y ya.
Aunque conozcas el lenguaje lo suficientemente bien, y encuentres estos bloques, si la clase es compleja y tiene varios cientos de líneas de código, y tienes que estar reacomodando esos bloques para que más o menos quede más legible el código... cuando llegues a ese punto, llegarás pronto a la conclusión de que lo mejor es un refactoring para eliminar dichos bloques, porque no ayudan en nada a la legibilidad del código. Y debes explicar eso en el mensaje del commit.
Lo que dice PMD se entendería incluso mejor así: it is rarely used and therefore confusing. Es decir, lo confuso viene de lo poco común de esa estructura; casi nadie la usa en producción (la evitan porque no ayuda en nada a la legibilidad del código y realmente hay maneras más limpias de lograr lo que puedes lograr con su uso), por lo tanto casi no lo ves en código productivo, y por lo mismo casi nadie de se acuerda de su existencia, si es que de entrada lo conocieron leyendo un libro o estudiando para su certificación (otra muestra de lo poco útil que son las certificaciones).
¿Por qué no ayuda en nada a la legibilidad? Porque su sintaxis es muy irregular, inconsistente con el resto del lenguaje. Y hoy en día que los programadores en vez de especializarse tanto en un lenguaje, prefieren conocer varios (lo cual me parece mejor para todos, honestamente), aunque no sea todos a fondo, o se especialicen un poco más en uno que no sea Java, no ayuda en nada esta estructura. Alguien que venga de Groovy por ejemplo lo ve y puede pensar que es un closure que no sirve para nada porque no fue asignado a nada y por lo tanto nunca se va a ejecutar y entonces termina borrando ese código así nomás.
Te lo pongo así de fácil: cuando yo vi este post la primera vez, me le quedé viendo un buen rato al código, y la verdad no me acordaba de estas cosas. Decidí que seguramente era código válido y se iba a ejecutar cada bloque de manera secuencial cada vez que se creara una nueva instancia, como si fueran parte del constructor, pero no sabía si antes o después del constructor. CASI le atino, y eso porque medio me acordé del inicializador estático... tiene más sentido que se ejecute antes, pero no me quedaba claro. Yo, con todos mis años de programar en Java, me tuve que poner a adivinar qué carajos haría ese código. ¿Hay algo más confuso que eso?
Si
De hecho lo que menciona @ezamudio es correcto me puse a escarbar el uso de estas cosas porque cuando lei los manuales de la certificación pues los mencionaban sin decir los usos prácticos que es lo que siempre se pregunta la persona que toma el curso ¿Y esto para que me va servir ?, y como bien dicen jamás he oido a alguna persona que lleve varios años programando en Java utilizarlos, es más algunos ni los conocen, pero no se si soy terco pero ¿ para que los crearon si son tan confusos y no muy utilizados ?, bueno a los estáticos si les he visto una que otra vez pero a los de instancia no les he visto ni he oido que alguien los utilice, más que yo cuando daba cursos de Java, y en ejemplos de "hola mundo".
Pues haber quien aporta más al tema y nos dice si los a utilizado.
Saludos.
Dejo algunas otras ligas
porque es difícil
Diseñar un lenguaje es bastante difícil. Probablemente hubo una larga discusión respecto si meter esta funcionalidad o no, y al final decidieron dejarla en caso que alguien la llegue a necesitar porque alguien presentó un caso hipotético hipercomplicado donde era necesario (o al menos muy muy conveniente) tener esta estructura disponible.
Esa es la manera en que un lenguaje termina volviéndose complicadísimo; le meten y le meten y le meten cosas nomás porque sí...
Ok
Rescatando un punto a favor, el uso en clases anónimas sería ese caso hipotético pues si necesitas inicializar una variable que pertenezca a la clase anónima y manejar un try-catch no puedes definir un nuevo constructor más que el que ya tiene por default no ? y en su lugar usas el inicializador de instancia para ello o estoy equivocado ?
de acuerdo
En clases anónimas puede ser bastante útil; tal vez por eso lo dejaron. Pero entonces, debería sólo ser válido en clases anónimas...
en cuanto al try-catch, pues esa es la bronca de tener excepciones "checadas". Algo que claramente fue un error de diseño y que prácticamente todos los otros lenguajes para la JVM (y algunos de otras plataformas como .NET) dejaron atrás.
Si, los agregaron en la v1.2
Si, los agregaron en la v1.2 de java cuando se aceptaron también las clases anónimas y sí, son raros en ciertos tipos de código, en swing por ejemplo eran muy comunes, por ejemplo crear una ventana con un text field, un botón y un action listener se vería así:
Que es mucho más breve que el completo sin usar clases anónimas.
Alguna vez los vi algo parecido
Digo que alguna vez vi algo parecido pero en este caso no son inicializadores,
El siguieente fragmento de código originaría error:
Aqui las llaves de bloque de código sirven para definir un espacio "local" para un mismo nombre de variable y no cause error, pero no tienen que ver con los inicializadores porque esos pertenecen a la instancia y en este ejemplo pertenecen a un ambito local a la estructura case del switch.
bloques
Esos son simples bloques de código dentro de un método. Sirven precisamente para lo que dices: creas un nuevo scope donde puedes declarar cosas nuevas y no serán visibles fuera de ese bloque.