Fecha y hora actual: Viernes 18 Oct 2019 13:34
Índice del Foro

Foros de programación informática, diseño gráfico y Web

En esta comunidad intentaremos dar soporte de programación a todos los niveles, desde principiantes a profesionales de la informática, desarrollo de programas, programación web y mucho más.

Lección 79: Casteo

Responder al Tema

Índice del Foro > Programación en general > Lección 79: Casteo

Autor Mensaje
Kyshuo Ayame
Moderador Global


Registrado: 07 Ene 2011
Mensajes: 1044

Mensaje Publicado: Lunes 14 Ene 2013 19:07

Título del mensaje: Lección 79: Casteo

Responder citando

Casteo

Dada la Herencia y con ella el Principio de Reemplazabilidad surge ahora una nueva y necesaria herramienta: el casteo. Esta herramienta nos permite “ver” a un objeto de una clase “como si fuera” instancia de otra. Por ejemplo, nosotros podemos ver un objeto Trabajador como si fuera un objeto Persona (en efecto lo es porque la herencia justamente lo permite gracias a la reemplazabilidad), o viceversa, podemos ver a un objeto Persona como si fuera un objeto Trabajador o un objeto Empleado. También podemos ver a un objeto Trabajador como si fuera un objeto Object. Ahora bien, esto es posible gracias a la herencia, por tanto no puedo intentar ver a un objeto de tipo Persona como si fuera de tipo ListaPersonas porque esas clases no están asociadas por la herencia en ningún momento. Para usar el casteo debe haber herencia, sino no es así tendremos un error en tiempo de compilación diciendo que son tipos incompatibles.

Para poder ver entonces cómo se usa el casteo tenemos que ver unas definiciones sencillas. Como verán, siempre a medida que avanzamos, la teoría se vuelve pesada y sumamente importante.

Información estática: Es la información que indica el tipo al que pertenece una referencia según como ha sido declarada. Por ejemplo, si yo declaro

Código:
  1. Trabajador t= new


la información estática nos dirá que t es de tipo Trabajador, sin importar de qué hagamos new luego. Otro ejemplo es este:

Código:
  1. Persona p2= new Trabajador("Mengano", "02", 58, 20, 21.5);


La información estática de la referencia p2 dirá que es de tipo Persona.
Entonces, la información estática siempre dice el tipo para el cual ha sido declarada la referencia. Por eso se dice estática, porque es la declarada y así se mantiene siempre, es decir no cambia. Esto concepto de estática difiere con el concepto de miembros estáticos de una clase, ya que estos sí podían cambiar pero existían incluso aunque no hubieran objetos de esa clase.


Información dinámica: La información dinámica dice a qué tipo de objeto está apuntando una referencia en un momento dado. Esta información puede ir variando a lo largo del programa en tiempo de ejecución y es por eso que se la llama dinámica. Por ejemplo, en esta línea

Código:
  1. Persona p2= new Trabajador("Mengano", "02", 58, 20, 21.5);


tenemos una referencia de tipo Persona llamada p2, pero la inicializamos mediante new Trabajador. La información estática dice que es de tipo Persona porque así fue declarada, pero la información dinámica dice que está apuntando a algo de tipo Trabajador. El objeto creado en memoria es realmente de tipo Trabajador porque así fue instanciado y por tanto contiene todas las operaciones y atributos de un Trabajador. Sin embargo, al estar siendo visto como algo de tipo Persona, no podemos invocar a nada que esté declarado en la clase Trabajador. NetBeans no nos dejará, y si lo hiciéramos a la fuerza tendríamos un error en tiempo de compilación.
Para cambiar esto debemos castear la referencia p2 para que su información dinámica apunte a algo de tipo Trabajador si es que queremos utilizar algo definido en esta clase. Veamos entonces los dos tipos de casteo que tenemos disponibles:


Casteo hacia arriba (up-cast): El casteo hacia arriba indica que vamos a ver a un objeto de una clase como un objeto de su super-clase o de alguna de las clases que están más arriba aún en la jerarquía de clases. Por ejemplo, si tengo un objeto Proveedor puedo querer verlo como un objeto Persona porque esta clase está arriba de la clase Proveedor en la jerarquía dada por la herencia, o incluso como un objeto Object. Es decir, si tengo una instancia de una clase puedo verla como instancia de cualquiera de sus superclases, esto es lo que expliqué con el principio de reemplazabilidad. Veamos un ejemplo:

Código:
  1. Trabajador t= new Trabajador("Mengano", "02", 58, 20, 21.5);
  2.  
  3. Persona p= t;


Allí tengo una referencia t de tipo Trabajador instanciada como hemos hecho siempre. Luego más abajo me declaré una referencia p de tipo Persona a la cual inicialicé igualándola a la referencia t. Esto es aplicar directamente el principio de reemplazabilidad. Nuestra referencia tendrá como información estática que es de tipo Persona pero como información dinámica que es de tipo Trabajador.

Dado que Java no admite la herencia múltiple, toda clase tiene a lo sumo una super-clase, por tanto el up-cast puede hacerse implícitamente tal como yo lo he hecho. Esto significa que no tengo por qué indicar hacia qué clase estoy casteando pero puedo hacerlo de todos modos:

Código:
  1. Trabajador t= new Trabajador("Mengano", "02", 58, 20, 21.5);
  2.  
  3. Persona p= (Persona)t;


Como pueden ver allí, puse entre paréntesis el nombre de la clase Persona, indicando que quiero que t sea visto como algo de tipo Persona. Esto ya quedaba claro antes, pero puedo hacerlo explícito si quiero, simplemente encerrando entre paréntesis el nombre de la clase para la cual quiero que apunte mi referencia.
En este ejemplo:

Código:
  1. Object o= (Persona)t;


¿Cuál es la información estática y cuál la dinámica de la referencia o?


Casteo hacia abajo (down-cast): Con el up-cast podríamos ver un objeto de una clase como objeto de su super-clase o de cualquiera de las clases que están por encima en la jerarquía de clases. Con el down-cast podemos ver a un objeto de una clase como objeto de cualquiera de sus clases derivadas, sin embargo, como una clase puede tener múltiples clases derivadas, debemos hacer el casteo de forma explícita. Por ejemplo, la clase Persona tiene dos clases derivadas, Proveedor y Trabajador. Si yo tengo un objeto que está siendo visto como objeto de tipo Persona y quiero verlo como objeto de tipo Trabajador tengo que hacer el casteo explícito hacia la clase Trabajador ya que también podría querer ser visto como Proveedor:

Código:
  1. Persona p2= new Trabajador("Mengano", "02", 58, 20, 21.5);
  2. Trabajador t2= (Trabajador)p2;


Allí he inicializado a la referencia t2 con la referencia p2 pero indicando que antes p2 fuera vista como algo de tipo Trabajador; noten los paréntesis que indican que p2 es casteada a tipo Trabajador ya que encerrado en ellos está el nombre de la clase Trabajador. Esto es muy importante y hay que tener mucho cuidado. El up-cast es casi a prueba de errores, pero el down-cast no.

Supongan las siguientes líneas:

Código:
  1. Persona p2= new Trabajador("Mengano", "02", 58, 20, 21.5);
  2. Proveedor prov= (Proveedor)p2;


Tengo mi referencia p2 de tipo Persona, y luego instancio una referencia prov de tipo Proveedor según mi referencia p2 casteando esta hacia el tipo Proveedor. Esto es posible porque Proveedor hereda de Persona y por tanto podemos hacerlo. Sin embargo, al ejecutar ese código nos encontraremos con un error en tiempo de ejecución que nos dirá:

Exception in thread "main" java.lang.ClassCastException: Persona cannot be cast to Trabajador

Allí se nos indica que Persona no puede ser casteado a Trabajador. ¿Por qué? Pues porque en este caso concreto, nuestra referencia p2 de tipo Persona fue instanciada como algo de tipo Trabajador (su información dinámica así lo dicta), por tanto no podemos ver a algo de tipo Trabajador como de tipo Proveedor porque no se relacionan entre ellas. Si nuestra variable de tipo Persona fuera en realidad un objeto de tipo Proveedor no pasaría nada, pero ahora en realidad es de tipo Trabajador, por eso el fallo. Hay que tener muchísimo cuidado con esto.

Otro ejemplo incompatible sería este:

Código:
  1. Persona pe= new Persona("Perengano","03",32);
  2. Trabajdor t= (Trabajador)pe;


Según nuestra herencia, técnicamente una referencia de tipo Persona puede ser vista como algo de tipo Trabajador, sin embargo al ejecutar ese código tendremos el mismo error de antes. Esto es porque la referencia pe apunta realmente a algo que fue creado mediante new Persona, por tanto no existen para ese objeto atributos ni operaciones de la clase Trabajador, así que el casteo es incompatible.

¿Cómo puedo saber entonces realmente a qué está apuntando una referencia? Es posible que en un código largo y complejo uno ya no sepa bien a qué está apuntando una referencia en realidad, ya que puedo estar viéndola de tantas maneras que uno se termina perdiendo. Por ejemplo, dada una referencia a un objeto Persona, podría ser en realidad una referencia Proveedor o una Trabajador. Sería bueno poder determinar realmente a cuál de las tres clases corresponde para invocar a las operaciones necesarias; en efecto eso es posible.


Operador instanceof:

Dada una referencia, instanceof (instancia de) puede decirnos si es realmente un objeto de una clase dada o bien, si no lo es. Este operador es un booleano que retorna TRUE si una referencia es realmente un objeto de la clase dada, o FALSE en caso contrario. Su sintaxis es la siguiente:

Código:
  1. nombreDeLaReferencia instanceof nombreDeLaClase


Se indica a la izquierda del operador el nombre de la referencia en cuestión, y a la derecha el nombre de la clase de la cual quiero saber si es instancia real. Por ejemplo, para esta declaración:

Código:
  1. Persona p2= new Trabajador("Mengano", "02", 58, 20, 21.5);


Podríamos, más adelante, querer saber si p2 es un objeto Proveedor o no. Simplemente se escribiría así:

Código:
  1. p2 instanceof Proveedor


En ese caso nos arrojaría FALSE ya que p2 en realidad es un objeto de tipo Trabajador, es decir, lo que se creó en memoria es algo de tipo Trabajador con todos sus atributos.
El operador instanceof suele ser usado en los if, por ejemplo así:

Código:
  1. if(p2 instanceof Persona){
  2. . . .
  3. }else if(p2 instanceof Proveedor){
  4. . . .
  5. }else if(p2 instanceof Trabajador){
  6. . . .
  7. }


Con esta herramienta no podemos equivocarnos en el down-cast. Es conveniente siempre, antes de castear, preguntar a qué está apuntando realmente una referencia.


Ejemplo de casteo hacia abajo:

En nuestro pequeño sistema que hemos implementado para aprender herencia, tenemos una lista encadenada que puede contener objetos de tipo Persona, Trabajador y Proveedor ya que así fue estipulado. Sin embargo, dentro de la clase ListaPersonas hemos tratado a todos los objetos que recibe como objetos de tipo Persona, pero sabemos que en realidad también recibe objetos de los otros dos tipos. Agregaremos tres variables de tipo entero, una para contabilizar cuantos objetos Persona se han agregado a la lista, otra para contabilizar los Proveedores y otra para los Trabajadores. Dado que solo nos interesa agregar objetos, trabajaremos con la operación AgregarPersona.

Primero nos declaramos en ListaPersonas los tres atributos:

Código:
  1. private int cantPersonas=0, cantProveedores=0,
  2. cantTrabajadores=0;


Las he declarado como privadas ya que quiero que solo sean modificables desde dentro de ListaPersonas. También las inicialicé en 0 porque en principio no existe en la lista ningún objeto de ninguna clase.

Agregaremos ahora tres operaciones selectoras para obtener los valores de estas variables:

Código:
  1. public int getCantPersonas() {
  2. return cantPersonas;
  3. }
  4.  
  5. public int getCantProveedores() {
  6. return cantProveedores;
  7. }
  8.  
  9. public int getCantTrabajadores() {
  10. return cantTrabajadores;
  11. }


Ahora vamos a la operación AgregarPersona, la cual nos queda así:

Código:
  1. public void AgregarPersona(Persona p){
  2. NodoLista aux;
  3.  
  4. if(this.EsVaciaListaPersonas()){
  5. this.nodo= new NodoLista();
  6. this.nodo.persona= p;
  7. this.nodo.siguiente= null;
  8.  
  9. }else{
  10. aux= this.nodo;
  11. this.nodo= new NodoLista();
  12. this.nodo.persona= p;
  13. this.nodo.siguiente= aux;
  14. }
  15.  
  16. if(p instanceof Proveedor)
  17. cantProveedores+=1;
  18. else if(p instanceof Trabajador)
  19. cantTrabajadores+=1;
  20. else if(p instanceof Persona)
  21. cantPersonas+=1;
  22. }


Lo único que he agregado son las últimas seis líneas correspondientes a los if que preguntan de qué es instancia realmente p. Como ven no es nada complejo, simplemente si es instancia de tal o cual clase aumento el contador que representa la cantidad de objetos de esa clase y ya. Algo super importante es el orden el que pregunto, es decir, he iniciado preguntando desde abajo hacia arriba, comenzando por Proveedor y Trabajador y subiendo. Es lo más conveniente. Traten de cambiar el orden, por ejemplo, preguntando si p es instancia de Persona ya en el primer if.

He modificado la clase principal apenas para verificar el funcionamiento del nuevo código:

Código:
  1. public class Herencia01 {
  2. public static void main(String[] args){
  3. Proveedor p= new Proveedor("Fulano","01",23,"Hnos S.A.");
  4. Trabajador t= new Trabajador("Mengano", "02", 58, 20, 21.5);
  5. Persona pe= new Persona("Perengano","03",32);
  6.  
  7. ListaPersonas l= new ListaPersonas();
  8.  
  9. for(int i= 0; i<3; i++){
  10. l.AgregarPersona(p);
  11. l.AgregarPersona(t);
  12. l.AgregarPersona(pe);
  13. }
  14. l.AgregarPersona(t);
  15. l.ListarListaPersonas();
  16.  
  17. System.out.println("PERSONAS= "+l.getCantPersonas()+"\n"
  18. + "PROVEEDORES= "+l.getCantProveedores()+"\n"
  19. + "TRABAJADORES= "+l.getCantTrabajadores());
  20. }
  21. }




Despachar un método:

El despacho de un método significa invocar al método asociado a una operación dada, o sea, ejecutarlo. No hay nada más que eso en esta definición. ¿Por qué la hago? Simplemente porque hace falta aclarar una cosa.

Si pensamos en nuestras tres clases (Persona, Proveedor y Trabajador) tenemos una operación definida en la clase Persona llamada getNombre y luego la redefinimos para Proveedor de una manera y para Trabajador de otra. Dado un objeto de la clase Persona, Java sabe que tiene que invocar al método de esa clase para esa operación; dado un objeto de la clase Trabajador Java aplica lo mismo y de igual modo para un objeto de la clase Proveedor. Ahora bien, dado todo esto de la herencia y el casteo, si nosotros tenemos un objeto Trabajador visto como un objeto Persona:

Código:
  1. Trabajador t= new Trabajador("Mengano", "02", 58, 20, 21.5);
  2. pe= t;


Al invocar a getNombre mediante pe.getNombre Java llamará al método de la clase Trabajador ya que en realidad pe está apuntando a un objeto Trabajador aunque nosotros lo estamos viendo como un objeto Persona.

Entonces cuando una operación tiene más de un método asociado (en este caso la operación getNombre tiene tres métodos asociados, uno en cada clase) Java utiliza la información dinámica de un objeto para decidir a cuál método debe invocar. Típicamente termina invocando al método de la clase de la cual es instancia real el objeto en cuestión. Dicho más claramente, nuestra referencia pe es de tipo Persona pero en realidad está apuntando a un Trabajador, por tanto Java sabrá eso y llamará al método de esa clase.


Algunas notas:

  • En lenguajes como C# existe el concepto de operación virtual. Una operación virtual es aquella que permite su redefinición en las clases derivadas. Para esto, dicha operación se declara con la palabra reservada virtual. Para redefinir una operación virtual en una clase derivada se hace mediante la palabra reservada override.
  • En Java no hace falta utilizar una palabra reservada para permitir la redefinición de operaciones siendo además posible redefinirlas todas, por este motivo se dice que en Java todas las operaciones son virtuales.
  • Podemos encadenar el llamado a constructores de una misma clase. Suponiendo que, dentro de un constructor de una clase A queremos invocar a otro constructor de esa misma clase podemos hacerlo mediante el uso de this(argumentos). Para eso dicho llamado debe ser la primera instrucción del constructor en el que estamos.
  • La clase Object es la raíz de la taxonomía de clases en Java, es decir, es la clase de más “arriba” en la jerarquía de clases ya que no hereda de nadie. Toda clase hereda, directa o indirectamente, de Object. Aplicando el principio de reemplazabilidad llegamos a que entonces todo objeto es de tipo Object.
  • Cada vez que se invoca a un constructor de una clase, en algún momento se invocará a un constructor de su clase base (lo hayamos escrito explícitamente o no – si no lo hacemos se invocará al constructor por defecto). Esto es porque para crear un objeto de una clase primero deben instanciarse todos los miembros de sus clases antecesoras (las de más arriba en la jerarquía de clases). Podría entonces pensarse erróneamente en que se están creando varios objetos, pero no es así, en realidad se crea el objeto básico y luego se va expandiendo agregando los atributos y operaciones necesarios. Por ejemplo, para crear un objeto Trabajador, PRIMERO se invoca al constructor de Persona, pero para crear a un objeto Persona PRIMERO se invoca al constructor de Object, por tanto, terminará ejecutándose el constructor de Object, luego el de Persona y luego el de Trabajador. En cada ejecución se van agregando atributos y operaciones.
    El constructor de Object inicializa lo básico indispensable, luego el constructor de Persona agrega los atributos y operaciones definidos en esa clase, luego el de Trabajador agrega además lo definido en la clase Trabajador, por tanto el objeto final tiene todo lo definido en Trabajador heredando lo que corresponde.
  • Dado lo anterior entonces determinamos que los constructores se invocan de abajo hacia arriba (siguiendo la herencia) hasta llegar a Object, pero luego se ejecutan de arriba hacia abajo en el orden inverso al que fueron llamados. Así primero se ejecuta el constructor de Object y luego los demás.
  • A pesar de que se considera que en Java todas las operaciones son virtuales (redefinibles en clases derivadas), podemos especificar que no lo sean, es decir, que no queremos que les adjudiquen otro método en las clases derivadas. Para esto anteponemos la palabra final luego del modificador de acceso

    Código:
    1. public final int miFuncion(. . .){. . .}


    Literalmente estamos declarando una operación constante, por eso la palabra final.
  • Así como podemos indicar si queremos que una operación sea redefinible o no, podemos indicar si queremos que una clase NO pueda ser heredada. Para esto usamos la palabra final luego del modificador de acceso de la clase:

    Código:
    1. public final class MiClase{. . .}


    Con esto, la clase MiClase no podrá ser heredada por nadie.


----------------------------------------------------------------

Ejercicios:

Ejercicio 1

Parte a) ¿Cuál es la sintaxis del casteo?
Parte b) Si una clase B hereda de una clase A, entonces un objeto de tipo B es también un objeto de tipo A. Esto se conoce como el principio de reemplazabilidad, ya que si por ejemplo un método espera un parámetro de tipo A, podemos llamar al método con un parámetro de tipo B, ya que si B hereda de A, entonces los objetos de B son objetos de A.

Siguiendo el ejemplo anterior, cuando se crea un objeto de tipo B éste puede ser visto como de tipo A mediante el denominado “casteo hacia arriba”. Describa qué entiende usted por “casteo hacia arriba” y de un ejemplo.
Parte c) Siguiendo con el ejemplo de la Parte b), si se tiene una referencia que fue declarada como de tipo A, pero en realidad apunta a un objeto de tipo B, entonces sólo se podrá acceder a los atributos y métodos de la clase A, pero no de la clase B (ya que ni siquiera compilará). ¿Qué se debe hacer para poder acceder a los atributos y métodos de la clase B?
Parte d) Los términos “casteo hacia arriba” y “casteo hacia abajo” vienen de que en la representación gráfica (o de pizarrón) usual de la herencia, se dibuja la clase heredada debajo y la clase base encima. Por tanto, “castear hacia arriba” significa acceder a parte de los atributos y métodos de un objeto, no a todos ellos, sino sólo a aquellos que lo permita la clase a la cual se está casteando. Cuando se “castea hacia abajo” es porque se quiere poder acceder a todos los atributos y métodos definidos para un objeto. La pregunta es: ¿Porqué castear hacia arriba no da problemas, mientras que castear hacia abajo puede resultar en un error en tiempo de ejecución?

Ejercicio 2

Suponga que una clase A tiene los métodos met1() y met2(). Suponga también que la clase B, que hereda de la clase A, tiene los métodos met3() y met4(). Indique cuáles de los siguientes fragmentos de código compilan correctamente y cuáles no, y porqué. Cada fragmento es independiente de los otros. Luego de contestar en papel, codifíquelo en Java, compílelo y ejecútelo:




Ejercicio 3

Parte a) El operador instanceof permite consultar si una referencia apunta a un objeto de cierta clase. La sintaxis es:

Código:
  1. if (<ref> instanceof <clase>)


donde <ref> es una referencia a un objeto y <clase> es una clase, y se quiere saber si el objeto es de ese tipo o no. Este operador es muy importante al momento de hacer un casteo hacia abajo. ¿Por qué?

Parte c) Si tuviera una operación en la clase ListaPersonas que, dado el id, me retorne el objeto Persona al cual corresponde ¿tendría que usar luego instanceof para trabajar con él? ¿Por qué?

===================================

Hasta la próxima.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
sr floyd
Usuario Activo


Registrado: 05 Sep 2011
Mensajes: 196

Mensaje Publicado: Lunes 10 Feb 2014 23:35

Título del mensaje: Lección 79: Casteo

Responder citando

Tengo la duda de la utilidad del casteo a pesar de la claridad teórica con que se expone en la lección; Debe ser debido a la idea arraigada de que si necesito un objeto de cierta clase, simplemente lo defino de dicha clase, pero como digo es una idea arraigada ¿es el casteo una herramienta recurrente en la POO? Excelente lección Kyshuo!!

Volver arriba
Ver perfil del usuario Enviar mensaje privado MSN Messenger
Kyshuo Ayame
Moderador Global


Registrado: 07 Ene 2011
Mensajes: 1044

Mensaje Publicado: Martes 11 Feb 2014 02:58

Título del mensaje: Lección 79: Casteo

Responder citando

El casteo se utiliza constantemente ya que la herencia es casi la base de la POO actual. En la medida en que sigas avanzando y haciendo tus propios proyectos te darás cuenta de esto, sobretodo cuando trabajemos con tablas (JTable), listas (JList y JComboBox).

Volver arriba
Ver perfil del usuario Enviar mensaje privado
jlrods
Usuario Inquieto


Registrado: 03 May 2014
Mensajes: 60

Mensaje Publicado: Martes 25 Ago 2015 10:58

Título del mensaje: Lección 79: Casteo

Responder citando

Hola Kyshuo, excelente leccion como siempre.

Estuve realizando los ejercicios de esta leccion. Con respecto al segundo tuve tres repuestas incorrectas (que no voy a dar detalle para que en un futuro otros puedan trabajar por su cuenta). Al revisar estos ejercicios, codificarlos y correrlos en el IDE puede llegar a estas conclusiones:

Siguiendo el hilo del ejercico, si A es la super clase y B hereda A "NO" se puede:

1) Instaciar un objeto como de la superclase y luego referenciar un objeto de la subclase casteando hacia abajo al primer objeto creado (que fue instanciado como de la superclase).

2) Declarar una referencia de la subclase e instanciarlo como un objeto de la superclase.

3) Declarar una referencia e instanciarla como un objeto de la superclase y luego castear para abajo.

Suena algo confuso. Tuve que revisar la clase por segunda vez y creo que tiene sentido. Por lo que veo de estos ejemplos y lo que comentas en la leccion, al instanciar un objeto como de la superclase el casteo para abajo es errado ya que la informacion dinamica no dispone de ninguno de los atributos de la subclase... Esta correctamente formulado?

Aun no veo comprendo el segundo punto, por que no se puede declarar de una clase e instancar el objeto como de la superclase?

Gracias y saludos.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
WhiteSkull
CoAdmin


Registrado: 20 Mar 2009
Mensajes: 3136
Ubicación: y*width+x

Mensaje Publicado: Martes 25 Ago 2015 12:30

Título del mensaje: Lección 79: Casteo

Responder citando

Es casteo es necesario, ya que aunque hereden de un objeto en común, su derivado normalmente ocupa más en memoria, puesto que hereda del anterior más lo definido y agregado en la clase derivada. Es como si quisieras meter el pie en un calzado más pequeño del que sueles usar, entonces no te cabrá el pie y se producirá un "desbordamiento de memoria". Haciendo el cast le indicamos al sistema (máquina virtual si es en Java), que el objeto puede prescindir de ciertos elementos (agregados) para que pueda encajar dentro del espacio del objeto donde lo trasvasamos.

En otros casos de cast descrito por el compañero, el problema no será ya de espacio, si no de invocar elementos que no tiene la clase base, ya que la derivada, como antes mencioné, es la base más lo que agregamos. Entonces se podría llamar funciones o elementos que no están definidos, pero de todas formas la práctica más común es el casteo hacia arriba.

Luego lo siguiente me imagino que será la reflexión Guiño

Volver arriba
Ver perfil del usuario Enviar mensaje privado Visitar sitio web del autor
Alfonso Lara
Usuario Iniciado


Registrado: 07 May 2019
Mensajes: 13

Mensaje Publicado: Viernes 31 May 2019 23:33

Título del mensaje: Lección 79: Casteo

Responder citando

Excelente Lección, me la leí con toda la calma para asegurarme de entender cada detalle y eso creo que logré luego de confirmar con los ejercicios y el IDE. En verdad invaluable documento. Mil Gracias profesor Kyshuo.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
Responder al Tema
Mostrar mensajes anteriores:   
Ir a:  
Todas las horas están en GMT + 2 Horas

Temas relacionados

Tema Autor Foros Respuestas Publicado
El foro no contiene ningún mensaje nuevo

Lección 101: Lectura/Escritura de archivos de t...

Kyshuo Ayame Programación en general 3 Sábado 26 Oct 2013 03:04 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 100: JMasterMind

Kyshuo Ayame Programación en general 7 Lunes 02 Sep 2013 20:29 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 99: JBuscaminas - GUI - Mouse Event

Kyshuo Ayame Programación en general 2 Lunes 19 Ago 2013 16:55 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 98: JBuscaMinas - Lógica

Kyshuo Ayame Programación en general 7 Martes 06 Ago 2013 18:23 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 97: JCalculadora

Kyshuo Ayame Programación en general 10 Lunes 29 Jul 2013 17:46 Ver último mensaje
Panel de Control
No puede crear mensajes, No puede responder temas, No puede editar sus mensajes, No puede borrar sus mensajes, No puede votar en encuestas,