Ejercicio! entrega CU00688B variables polimórficas java

[Jorge lopez]

Concepto de polimorfismo y variables polimorficas en java.
Jerarquía de tipos.

Nota: Indicaciones a seguir para el correcto funcionamiento del código.
 1: Descargar y descomprimir el archivo.rar.
 2: Crear un package con nombre: CU00688B.
 3: Copiar los 10  archivos.java dentro de dicho package.
 4: ejecutar el método main de la clase TestHerencia4 mediante el IDE de su preferencia 
Saludos!

[dongo]

Hola he estado mirando tu ejercicio y en cuanto a funcionamiento, declaración de variables, atributos métodos, los nombres, etc, esta todo bien, pero te señalare un par de cosas que veo extrañas.

Por ejemplo la clase ProdRefrigeradoOcongelado, yo creo que esta clase es totalmente innecesaria, a ver si tenemos una clase producto y después 3 tipos de productos Fresco, congelado y refrigerado, tendriamos la siguiente jerarquía:

             /- ProductoFresco
Producto |- ProductoRefrigerado
             \- Producto congelado

tu has creado la siguiente jerarquía:

             /-ProdFresco
Producto                                          /- ProdCongelado
             \-ProdRefrigeradoOcongelado
                                                      \- ProdRefrigerado

Lo primero comentarte que ni tu esquema, ni tu forma de llevarlo a cabo  están mal, pero creo que las características comunes entre un producto Refrigerado y uno congelado son tan mínimas que no merece la pena crear una clase para que solo 2 objetos hereden de ella, si hubiera la posibilidad alomejor de que fueran 40, entonces si, merecería la pena crear esta clase. Esto solo es mi opinión, pero esto también dependerá mucho de lo que quieras hacer y de lo que te pidan.

Por otro lado otra cosa que he visto es que pienso que te has complicado en la clase ListaDeProductosParaEnviar pues has creado métodos específicos para añadir cada producto, dejando a un lado la cantidad de parámetros(XDD), cuando el objetivo del ejercicio es usar el polimorfismo(capacidad de los objetos para pertenecer a múltiples tipos ).

Todo esos add de la clase ListaDeProductosParaEnviar se hubiera arreglado simplemente con un método de este tipo:

Código: [Seleccionar]

//método añadir un producto a la lista para enviar
public boolean addProducto(Producto paramProducto){
    boolean insertado;
    insertado=listaDeProdParaEnviar.add(paramProducto);
    return insertado;
}

Y esto creo que es lo mas importante que tenia el ejercicio, que al tener tres tipos de productos(ProdRefrigerado, ProdCongelado y ProdFresco), los cuales heredan de una clase padre llamada Producto, en la clase ListaDeProductosParaEnviar podríamos haberlos tratado mediante polimorfismo como si fueran Productos de forma general Y no especificando métodos para cada tipo como has echo tu.

Así que yo te recomendaría que repitieras la clase ListaDeProductosParaEnviar haciendo uso de esta capacidad polimórfica que tienen los objetos en java.

Y bueno, no se si me dejare algo detrás, pero vamos dado que como quien dice estas empezando a gatear con java, el ejercicio esta bastante bien.

Si tienes dudas o lo que sea, ya sabes. Bueno un saludo!! 

[Jorge lopez]

 Hola dongo!

Tanto el comentario de Mario Rancel (en mi anterior ejercicio CU00687B):

Pero aquí vemos que tenemos un atributo común entre refrigerados y congelados: temperatura de mantenimiento. Para evitar la duplicidad de atributos y métodos relacionados podemos crear una clase que agrupe a estas dos categorías, por ejemplo la llamaríamos ProdRefrigeradoOcongelado, y ahí dejaríamos el atributo temperatura de mantenimiento recomendada y sus métodos relacionados.

Como tu comentario:

Lo primero comentarte que ni tu esquema, ni tu forma de llevarlo a cabo  están mal, pero creo que las características comunes entre un producto Refrigerado y uno congelado son tan mínimas que no merece la pena crear una clase para que solo 2 objetos hereden de ella, si hubiera la posibilidad a lo mejor de que fueran 40, entonces si, merecería la pena crear esta clase. Esto solo es mi opinión, pero esto también dependerá mucho de lo que quieras hacer y de lo que te pidan.

Ambos me han servido de mucho provecho, aunque a simple vista estos dos comentarios parecieran contradecirse, es todo lo contrario! según lo e asimilado y con la ayuda de tu comentario, entiendo que agrupar atributos y métodos en común para diferentes clases, seria circunstancial.

Sobre lo que comentas a cerca de la clase ListaDeProductosParaEnviar y su cantidad de métodos "innecesarios"  también e asimilado el concepto de polimorfismo aplicado en esa clase, al conseguir sustituir el trabajo de todos esos métodos en un solo método tal y como me recomendaste.

Otro punto a corregir, y que se me escapo tanto a mi como a ti  es que al ejecutar el main si te fijas las fechas (packingDate y expirationDate) no aparecen  como se espera según los parámetros que se le aplican para cada producto, en su lugar devuelve la fecha exacta actual. Esto también ya lo he corregido.

y nada! darte las gracias por tu continua disposición a colaborar con los que estamos comenzando a gatear, para que en un futuro caminemos con pasos mas firmes en java

adjunto el archivo.rar con las mejoras recomendadas aplicadas.

Nota: he mantenido la clase ProdRefrigeradoOcongelado en el código, pero estoy totalmente de acuerdo con tu punto de vista:

creo que las características comunes entre un producto Refrigerado y uno congelado son tan mínimas que no merece la pena crear una clase para que solo 2 objetos hereden de ella, si hubiera la posibilidad a lo mejor de que fueran 40, entonces si, merecería la pena crear esta clase.

y lo tomare en cuenta para mis próximos códigos.

Saludos!

[dongo]

Estupendo, ahora si estas aplicando el polimorfismo correctamente en la clase ListaDeProductosParaEnviar.

Sobre si crear una clase padre cuando hay atributos en común entre varias clases, has llegado a una buena conclusión, esto como bien has concluido es circunstancial y dependerá de la forma en que te indiquen hacerlo o de la manera que tu creas mas conveniente, y creas que te resultara mas fácil, si es cierto que ahora que estas aprendiendo conviene que lo apliques siempre que tengas ocasión, para aprender a trabajar con herencia.
Como práctica y aprendizaje pues no te viene mal usar la herencia cuando tengas oportunidad. Normalmente en ejercicios de este tipo pues no se puede exigir mucho y de hay que una herencia para dos clases(ProdRefrigeradoOCongelado) este bien como didáctica.
Pero en mi opinión(ya que tengo poca experiencia profesional) normalmente la herencia 
se suele usar para crear sistemas mas complejos, o por ejemplo  la escalabilidad del código(un sistema que se prevee que va a ser ampliable)... 

te voy a contar un cuento(por supuesto inventado...) de esto que te hablo:

Imagina que te contrata la universidad de biología, y te dice, queremos un programa para manejar anfibios, que me permita tener una base de datos de anfibios, poder añadir, poder consultar, etc... y te acaban diciendo y si nos gusta, quizá te contratemos para uno de mamíferos.

Caso del Programador inexperto(No piensa, no reflexiona)

Entonces tu como programador inexperto, llegas a tu casa y piensas... Jummm, me piden un programa para manejar anfibios, y directamente empiezas a crear una clase Anfibios, creas otra clase llamada ListaAnfibios, creas los jframes(ventanas) para manejar los anfibios, y te pegas 2 meses trabajando en el programa de anfibios.
Cuando lo terminas y lo entregas resulta que te dicen a pues nos encanta, haznos ahora el de mamíferos. Y el programador inexperto se tira otros 2 meses creando un programa "exactamente igual" al anterior.

Caso del Programador inteligente(piensa, reflexiona)

Entonces tu como programador inteligente, llegas a tu casa y piensas... Jummm, me piden un programa para manejar anfibios, pero también cabe la posibilidad de que me soliciten uno para mamíferos.... Pero estos tios...quizá con el tiempo también quieras uno para peces, y para aves, y quien sabe, quizá insectos...
Y piensas, pues voy a crear una clase abstracta Animales que recoja todos los datos comunes a un animal(nombre, nombre latín, procedencia, paraje, alimentación, etc) y de aquí podré ir extendiendo todos los subreinos, anfibios, mamíferos, peces, insectos, aves, por lo que si hoy me piden para anfibios, y trabajo un poco mas, si mañana me piden mamíferos tendré la mitad del trabajo echo, solo tendré que extender de la clase Animal y listo. Este me llevará tres meses pero si me piden el de mamíferos solo me llevará medio....

El programador inexperto se tiro 1 año y medio haciendo los programas para todos los reinos animales.

Y el programador inteligente hizo todos los reinos en 6 meses.

Y nada FIN! XDD

La moraleja de esto es, que a veces pensar y reflexionar antes de liarse a picar código puede mejorar mucho el diseño de nuestra aplicación.

Y bueno esto iba por lo de la herencia XDD, como ves el programador inteligente, previno una posible escalabilidad del código y el inexperto sin embargo ni penso en eso, esta es una de las mayores funciones(escalabilidad del código) que yo le veo a la herencia, entre otras mas... que si me pongo a contar como ves me engancho y no termino...

En cambio tu de una clase ProductoRefrigeradoOCongelado, es o blanco o negro, la herencia pues como didáctica si, aunque como habrás sacado también del cuento, todo depende de quien lo coja, como lo quiera enfocar, y lo que pretenda hacer.

Yo por ejemplo si tengo 2 clases que tienen en común 20 atributos y 7 métodos... pues esta claro que voy a crear una clase padre para las dos...

Sobre tu código, bueno lo de las fechas tienes razón, estaban mal, pero vamos te aseguro que las fechas fue algo que es que ni miré XDD Bien visto!

Eso si en el método main del TestHerencia me encontrado algo raro:

Código: [Seleccionar]

while(copia.hasNext())
    {
      switch(i)
       {
         case 1: tipoDeProd = "Producto fresco"; break;
         case 2: tipoDeProd = "Producto fresco"; break;
         case 3: tipoDeProd = "Producto refrigerado"; break;
         case 4: tipoDeProd = "Producto refrigerado"; break;
         case 5: tipoDeProd = "Producto refrigerado"; break;
         case 6: tipoDeProd = "Producto congelado por agua"; break;
         case 7: tipoDeProd = "Producto congelado por agua"; break;
         case 8: tipoDeProd = "Producto congelado por aire"; break;
         case 9: tipoDeProd = "Producto congelado por aire"; break;
         case 10: tipoDeProd = "Producto congelado por nitrogeno"; break;
         default: tipoDeProd = tipoDeProd; break;
       }
      System.out.println("____________________________________________");
      System.out.println("\n" + i++ + ": " + tipoDeProd );
      System.out.println("____________________________________________");
      //System.out.println("\n\t\t" + i++);
      copia.next().verInfoDelProducto();
    }

         

Ese while con ese switch tan repetitivo que duele a la vista... y si tuvieras 3.000.000 de productos en la lista?? XDDDD

Mira te paso una alternativa con el operador "instanceof", no es muy complicado, échale el ojo y si no entiendes algo ya nos comentas.

Código: [Seleccionar]

while(copia.hasNext()){
        Producto aux=copia.next();
        if(aux instanceof ProdFresco ){
            tipoDeProd = "Producto fresco";
        }
        else if(aux instanceof ProdRefrigerado){
            tipoDeProd = "Producto refrigerado";
        }
        else if(aux instanceof PCongeladoPorAgua){
            tipoDeProd = "Producto congelado por agua";
        }
        else if(aux instanceof PCongeladoPorAire ){
            tipoDeProd = "Producto congelado por aire";
        }
         else if(aux instanceof PCongeladoPorNitrogeno ){
            tipoDeProd = "Producto congelado por nitrogeno";
        }
      System.out.println("____________________________________________");
      System.out.println("\n" + i++ + ": " + tipoDeProd );
      System.out.println("____________________________________________");
      //System.out.println("\n\t\t" + i++);
      aux.verInfoDelProducto();
    }

Y nada, pos a seguir para adelante.

Un saludo!

[Jorge lopez]

 Pensar antes de actuar! como tu bien dices he ilustras en tu cuento (inventado  ) aplicar este concepto antes  de comenzar a diseñar un código (programa, app, ect...) nos hará el trabajo mas fácil a la hora de extender un proyecto. Pulgar arriba (like) para tu cuento inventado 

En cuanto al switch en el main: cuando lo inserte al código, lo contemple y me pregunte: no habrá alguna otra forma mas genérica para esto  ?? trate de hacer algo mas eficiente por el mismo motivo que tu planteas (si fuese una cantidad muy grande de productos?).

Ahora que me sugieres el operador "instanceof" también he podido usar algo mas eficiente que el switch dada las circunstancias, como lo es el método "contains()" tal y como se muestra en el siguiente fragmento de código:

Código: [Seleccionar]

    while(copia.hasNext())
    {
      Producto producto = copia.next();
      if(producto.toString().contains("ProdFresco"))
      {
        tipoDeProd = "Producto fresco";
      }
      else if(producto.toString().contains("ProdRefrigerado"))
      {
        tipoDeProd = "Producto refrigerado";
      }
      else if(producto.toString().contains("PCongeladoPorAgua"))
      {
        tipoDeProd = "Producto congelado por agua";
      }
      else if(producto.toString().contains("PCongeladoPorAire"))
      {
        tipoDeProd = "Producto congelado por aire";
      }
      else if(producto.toString().contains("PCongeladoPorNitrogeno"))
      {
        tipoDeProd = "Producto congelado por nitrogeno";
      }
      else{}
      System.out.println("____________________________________________");
      System.out.println("\n" + i++ + ": " + tipoDeProd );
      System.out.println("____________________________________________");
      producto.verInfoDelProducto();
    }Aun así, si me tocara elegir elegiria usar "instanceof"

Nuevamente: muchas gracias por tu aporte dongo

Saludos!

[ZSCFCP]

Buenas.

Una cosa quería decir de la utilización de IF anidados preguntando con "instanceof".
Ya que me he dado un buen susto en mi ejecución y ya entendí porqué.

Hay que tener en su uso en esta practica muy presente, que el orden en el que se pregunte por las clases SI QUE INFLUYE.

Es decir, si pregunto en el primer IF p.ej. por Producto Fresco:

 "Producto tmp = it.next();
            if (tmp instanceof PFresco) {"

y PFresco está jerarquicamente por encima de PRefriguerado, aunque mi primera iteración (primer elemento de mi lista) contenga un PRefrigerado, VA A ENTRAR por el primer IF y no va a llegar al que pregunta por PRefrigerado. Dado que creo que "instanceof" lo que te comprueba es si "tmp" puede instanciar un PFresco, es decir, si cumple con sus requisitos y, efectivamente, "tmp" en ese primer elemento de la lista, ademas de poder instanciar un PRefrigerado, TAMBIEN puede instanciar a su padre PFresco. Por lo que el primer IF del ejemplo se cumple y entra.

No se si logré explicarme. Si no lo hice, o estoy equivocado contesten. Gracias.

[toni_apr]

Hola ZSCFCP
Te has explicado muy bien. Es más, creo que otros usuarios tomarán tu observación en cuenta a la hora de codificar si no quieren obtener resultados inesperados.

Primero para clarificar conceptos, en el caso que nos ocupa no es un IF anidado.
If anidado es aquel que entre el if inicial y el else final aparece otro if con su else final, independientemente de los else if que tenga en medio.
Ejemplo if anidado:
if (condicion1) {
    if (condicion2) {
        // sentencias condicion2 verdadera
    }  // fin condicion2
    // mas sentencias condicion1
}  // fin condicion1
En este ejemplo, para que la condición2 se evalúe, tiene que ser cierta la condicion1.

Otra forma de exponer tu observación sería.
Para evaluar la clase de un objeto con instanceOf, en las primeras condiciones del if se debe hacer la comparación con las clases padres o superclases y terminar con las clases hijas o subclases.

Saludos