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

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

Algunas curiosidades ...

Durante mi preparación del examen de certificación de Java tuve que comenzar a analizar código y fijarme en detalles en los cuales nunca antes había ni siquiera pensado en fijarme. Muchas veces decimos que manejamos un lenguaje bien porque hemos programado un par de aplicaciones en él y con eso nos sentimos "expertos", pero de ser "experto" a conocer el lenguaje es otra cosa ... este post va dedicado a un par de curiosidades de ese tipo que encontré y la idea es que quienes se interesen traten de responder a las preguntas sin necesidad de compilar ... si, si sé, ustedes dirán ... pero cómo voy a responder si yo no soy un compilador ... pero dejenme decirles que justamente ahí está la gracia ... las primeras veces, las respuestas que damos no están ni cerca de lo correcto, pero luego aprendes y luego te basta con mirar un trozo de código y saber cuál podría ser la razón del problema ... y creanme que se los digo por experiencia propia ... yo siempre me he definido como una persona auto-didacta y nunca, mientras estudiaba, me quedaba simplemente con lo que los profesores nos entregaban en clases ... y creo que eso me ha ayudado a aprender todo lo que sé ... así es que si las primeras respuestas a las preguntas "capciosas" que acá voy a ir dejando de los distintos lenguajes en los cuales me va a tocar trabajar este año no son en un principio correctas, no importa, sigan intentando y se van a dar cuenta de que, poco a poco, van a ir ganando terreno en el lenguaje.

Bueno, después de esta breve introducción :-o ... vamos con la primera pregunta:

Observando el siguiente código, ¿qué debería imprimir?

Se trata de un ejemplo del uso de colecciones usando Generics y el tratamiento de los métodos característicos de tratamiento de colecciones: add y delete.

Dentro de las posibles respuestas están 0 y 100. Según lo que se lee se agregan y se quitan elementos a la colección que hemos creado. Se entiende que agrega un elemento y debería eliminar el elemento anterior ... y fíjense que en la primera iteración debería eliminar el número 0. La colección es un objeto HashSet que se almacena en un objeto declarado como Set ... ¿saben lo que imprime?, pero la mejor pregunta es: ¿pueden justificar la respuesta? ... la respuesta la voy a dejar stand-by y la respuesta la daré en el próximo post ... a ver si llegan algunos comentarios dando la opinión de por qué creen que imprime lo que imprime.

El código que sigue si que es curioso y ha sido uno de los que más me ha desconcertado ... jejeje, observen:

En este caso la pregunta de rigor es: ¿por qué imprime lo que imprime en la salida estándar?

La respuesta pasa por el comportamiento del null cuando se asigna a un objeto. El constructor de la clase Uno se encuentra sobrecargado y la clase Object tiene mayor prioridad, recuerden que la clase Object es la clase raíz (la clase padre de todas las clases) y por lo mismo está en el mayor nivel de jerarquía. La pregunta que debería quedar ahora es lo que se debería hacer para que imprima un "2" en la salida estándar, es decir, para que se ejecute el segundo constructor de la clase Uno.

Finalmente, una utilidad, han leído algo sobre la clase TestCase ... bueno acá hay una aplicación de esa clase ... permite trabajar con casos de prueba para ir depurando nuestros métodos ... si bien es cierto las aserciones es muy poco probable que aparezcan en la prueba de certificación no es malo saber cómo funcionan.

Para poder probar el código anterior necesitan el .jar asociado a junit, el cual lo pueden encontrar en el siguiente link.


Bueno, creo que eso sería mi primer post ... relacionado con Java, luego vendrán otros en .NET y C para ir variando un poco ... todos con algunas curiosidades y utilidades que nos ayuden a conocer más los lenguajes de programación.

Saludos a todos y que Dios los bendiga

Bye