Ocultamiento de atributos (Field hide another field)

Parece ambiguedad, pero no lo es, se trata del concepto de ocultamiento de atributos; el tema de este post es justamente ese: ¿cómo se deben considerar los atributos que tienen el mismo nombre en cierta jerarquía de clases?

Observemos el siguiente ejemplo (clic sobre la imagen para ampliarla):
Dos preguntas al respecto:

• ¿Qué será lo que imprime en la salida estándar? y
• ¿Por qué genera esa salida?

La salida es: 0, 2 y 1 que corresponden a los valores del atributo 'i' de cada objeto que fue creado (c, ca y cv).

Lo interesante acá es que estos objetos fueron declarados de una forma y fueron creados de otra; la verdad es que no quedaba más opción porque no se pueden crear objetos de una clase abstracta y menos de una interfaz >:o ... entonces se crean los tres objetos a partir de la clase CCar. Esta clase hereda de una clase e implementa una interfaz y, tanto en la clase abstracta como en la interfaz, cuentan con un atributo llamado 'i'. Por lo tanto, el atributo 'i' que va considerar será tomando en cuenta la forma en la que se declaró el objeto. Ahora, de forma natural, surge la pregunta de si este comportamiento se aplica de la misma forma cuando se trata de métodos .... pero eso será lo que revisaré en el siguiente post.

Eso es todo por ahora, fin de la transmisión ... que Dios los bendiga.

Bye

Respuestas a las interrogantes ....

Tal y como lo mencionaba en el post anterior, voy a dar respuesta a las interrogantes que deje pendientes :-) ...

En primer lugar estaba preguntando qué deberíamos hacer para poder imprimir el contenido del arreglo; bueno la respuesta pasa por considerar la siguiente variante del código:


Acá vemos que se ha considerado el argumento como un arreglo de objetos, que en este caso si nos fijamos en la línea 22 estoy haciendo uso de los argumentos variables, luego se va a entender que dentro del método el argumento "objList" se trata como un arreglo de dos elementos (y cada uno de ellos es un arreglo de String), luego los elementos de "objList" se moldean a String[], lo cual no deja de ser peligroso, porque no se sabe con certeza que van a ser arreglos de String ... ahi deberíamos tratar la posible excepción (ClassCastException) que se generaría en caso de que no se pueda convertir, suponiendo por ejemplo, que llamamos al método usando elementos del tipo Integer[] por ejemplo ... pero bueno, ese no es el tema relevante acá :-p jejeje

Finalmente, en la línea 17 se recorre el arreglo que se encuentra dentro del arreglo y recién ahí podemos acceder a los elementos como String que están dentro del arreglo ... insisto, quizás estoy tratando muy "relajadamente" el tema de la conversión ... pero sólo quería responder a la pregunta de cómo acceder a los elementos del arreglo ...

La segunda pregunta que había planteado era qué era lo que sucedía si se eliminan los [] en la recepción del argumento dentro del método printMeThat ... la respuesta acá es más o menos la que están imaginando (porque la están imaginando verdad? :-p jejeje) ahi se trata el arreglo como un objeto simple y de todas formas va a imprimir la referencia del arreglo y si agregamos el código que propuse antes el resultado sería EXACTAMENTE el mismo, es decir, imprime el contenido de los arreglos (los valores de los String que están dentro de los arreglos).

Bueno, esperando haberme explicado y agradeciendo a los que hayan leído hasta este punto, me despido

Bye

Argumentos variables ...

Acá va algo relacionado con los "famosos" argumentos variables. La sintaxis que utiliza los "..." luego del tipo de datos y antes del nombre de la variable es una de las reglas de oro para trabajar con los argumentos variables. Además se debe agregar otra regla que dice relación con que el argumento variable SIEMPRE debe ser el último de la lista de argumentos de un método. Si revisamos la siguiente figura:
notamos las consideraciones e interpretaciones que se van a tener respecto del trabajo con argumentos variables en los métodos.

Ahora bien, analizando la posible respuesta a la pregunta que se plantea al prinicipio y que es el objetivo de este post :-) jejeje, puedo decir que:

Dado que dentro de las alternativas se contempla un posible error de compilación se hace necesario analizar las líneas candidatas de ser causantes de un error de compilación. En el caso de la línea 6 no hay problema de sintaxis porque de acuerdo a las reglas ya revisadas se está definiendo un argumento variable. La línea 7 delclara y crea un arreglo declarado como Object y creado como String lo que no genera problema porque la regla dice que la forma en la cual se declara el objeto (la clase usada en la línea de declaración antes del nombre de la variable) debe ser de mayor jerarquía de la forma en la que se crea (lo que va después del operador new). Finalmente, la línea 4 no presenta problema de sintaxis dado que se está usando una manera resumida de recorrer el arreglo (que se está recibiendo como argumento); esta forma de recorrer el arreglo va dejando en el objeto "obj" los elementos que se encuentran dentro del arreglo "objList" que es considerado como 0 o más arreglos de objetos.

Dado el análisis anterior queda por ver si el programa genera alguna salida y si esa salida coincide con la expuesta en la alternativa D. En la línea 8 se realiza la llamada al método printMeThat usando el arreglo de objetos "sArray", por su parte, en la línea 3 el argumento "objList" está capacitado para recibir 0 o más arreglos de objetos por lo que los valores de la variable "obj" que se está declarando en la línea 4 son elementos del tipo Arrays de objetos y es eso lo que intenta imprimir y es por esa razón que va a imprimir la referencia del objeto (el arreglo en este caso) y no el contenido. Luego la alternativa correcta es la alternativa E.

Ahora, como siempre, vienen las inquietudes "extras" las que voy a dejar planteadas para responderlas en el siguiente post:

• ¿Qué cambios se deben incluir para poder imprimir el contenido del arreglo?
• ¿Qué sucede si se quitan los [] de la declaración del argumento en la línea 3?.

Pensemos un poco en eso y en el siguiente post van las respuestas ;-)

Bye

Bloques estáticos, variables estáticas, métodos estáticos ...

Variables estáticas, bloques estáticos ... en general, miembros estáticos de una clase, qué son y cómo se comportan ... veamos algo de esto ...

Técnicamente, los elementos estáticos (atributos, métodos) se denominan elementos de clase, porque son comunes a todos los elementos de la clase. Eso es lo que sucede con la variable x que se encuentra definida en la clase de la figura. Esta variable tiene asignado un valor y ese valor es 5 y es válido para TODAS LAS INSTANCIAS de la clase que se vayan a crear, es conveniente hacer notar que NO ES UNA CONSTANTE (debería tener el calificador final para que sea), es muy útil hacer esa distinción ;-)

Esta es una pregunta típica del examen de certidicación y apunta a demostrar el conocimiento de los elementos estáticos de una clase.

Vamos ahora al análisis de la pregunta para obtener la respuesta correcta:

Dado que, una de las alternativas, contempla la posibilidad de que haya un error en tiempo de ejeución se debe revisar si existe algún error en la lógica de programación .... debido a que sólo se crea un objeto anónimo (línea 13) y luego se imprime el valor de un atributo de clase y desde un método estático (regla de oro de los atributos estáticos) no se produce error en las únicas dos líneas con las que que cuenta el método main.

Analizando ahora la posible respuesta se tiene que en la línea 13 se crea un objeto anónimo lo que hace que se cargue el bloque estático definido dentro de la clase donde asigna 10 al valor del atributo de clase "x" y cuando termina de ejecutarse el bloque de inicialización (definido entre las líneas 8 y 10) eso hace que el valor del atributo sea 20. Luego, en la línea 14 se imprime en la salida estándar el valor del atributo de clase "x" y, por las razones que se acaban de explicar, imprime un 20. Por lo tanto, la alternativa correcta es C; ¿respuesta definitiva? .... SI, respuesta definitiva.

Como siempre, mi inquietud va más allá de conocer la respuesta correcta; así es que comienzo a plantearme las siguientes preguntas:

¿Qué salida genera si se elimina el bloque de inicialización? La respuesta acá es más o menos obvia, dado que simplemente se va a quedar con el valor asignado dentro del bloque estático, es decir, un 10.

Ahora, considerando nuevamente el bloque de inicialización ¿qué sucedería si la línea que imprime el valor de x se crea antes de crear el objeto anónimo? ... la respuesta es 10 ... ¿por qué? la razón es porque el bloque de inicialización se ejecuta cuando se crea una instancia de la clase y hasta ese momento sólo se ha ejecutado el bloque estático (una vez que se ha cargado la clase).

Bueno, creo que eso nos introduce un poco a averiguar un poco más acerca de los elementos estáticos de una clase ...

Saludos a todos los que se dieron la lata de leer hasta este punto :-)

Bye

Pregunta simple ...

Bueno, llevaba algunos meses alejada de este blog; pero ahora he regresado para mantenerlo como se debe; así es que sin más preambulos, vamos con la primera pregunta.

Miren este simple ejemplo ... la pregunta de siempre es si compilará o no y en caso de que la respuesta sea negativa, entonces cuáles son las causas de los errores. Para algunos la respuesta puede resultar muy, pero muy obvia, pero lo importante como siempre es saber justificar la respuesta.

Analizando el código tenemos:

La clase A se encuentra definida dentro de un package llamado "certification" y la clase tiene una visibildad por 'default' que es distinta a la visibilidad 'public'. Esa clase compila sin ningún problema.

Luego en la clase B se importa la clase A desde su package y se define la clase B como una sub-clase de A ... pero acá está el problema, al tratar de compilar nos encontramos con que no se puede tener acceso a la clase A (aunque la hayamos importado) porque la visibilidad de la clase A es por default, es decir, a nivel de package ... y la clase B se encuentra en otro package, por lo tanto, no tiene acceso a la clase A.

La pregunta ahora es: ¿cómo se puede solucionar el problema?

Entonces, qué podemos decir ahora si intentamos con el siguiente código:

La clase C importa a la clase A, pero la va a utilizar sólo para crear objetos de esa clase, ¿será válido el acceso ahora?

La respuesta sigue siendo la misma ... no se puede acceder a la clase A, la clase C está definida dentro de un package distinto y la clase A tiene acceso por default.

Qué es lo relevante de estos simples ejemplos es la visibilidad de las clases, muchas veces me he encontrado con personas que piensan que el no incluir una visibilidad a la clase se asume que es público, pero NOOOOO, no es lo mismo. Sin embargo, hay una excepción a esa regla y tiene que ver con las interfaces ... pero eso lo dejaré para un próximo post.

Bueno, eso es todo por ahora, un abrazo a todos los que pasan por acá.

Saludos

Una pregunta interesante

Hoy estaba preparando una guía de ejercicios para mi curso de Programación Orientada a Objetos y dentro de mis inventos elaboré el código que se encuentra en la figura (clic para ampliar la imagen)



Primero, se puede preguntar si es válido el tratar de ejecutar el código de la figura de la izquieda.

Luego, se puede preguntar si es válido el código de la imagen anterior y responder luego por lo que imprime y, como siempre, la pregunta más interesante de todas ... ¿podemos justificar la respuesta?

Responder a este tipo de preguntas justifica el conocimiento REAL que se tiene de los conceptos de OO aplicados a un lenguaje de programación.

Saludos

Ranking de los lenguajes de programación

Miren este link de los índices de popularidad de los lenguajes de programación.

Ahora, ya que Java está en el inicio de la lista :-o jeje, miren este código (clic en la imagen para ampliarla ;-) ):

¿Qué se supone que debería imprimir? y la pregunta más importante e interesante es ¿por qué imprime eso?

La respuesta apunta por entender la forma de operar de los métodos de clase respecto de la forma de los métodos de instancia. Agregguemos a eso las declaraciones en distintos niveles de la jerarquía de clases.

Lo otro interesante es probar realizando los siguientes cambios:

• Quitando el 'static' del methodA(Base b) y
  
• Cambiando: Derived d = new Derived(); por: Base d = new Derived();

¿Cambia en algo la salida?, independiente de si cambia o no, ¿podemos justificar la salida?

En el próximo post va la explicación ... mientras tanto, tratemos de entender el comportamiento de los métodos de clase.

Bye