Ejemplo de diseño de una relación de clases con herencia en Java CU00687B.

[RaGa]

Mi versión del Ejercicio propuesto en la Entrega Nº87. Ejercicio CU00687B.
(archivo adjunto CU00687B.rar, descarga estando logeado en el foro)

Diagrama de clases en archivo adjunto "DiagramaDeClases.jpg"

[toni_apr]

Hola RaGa

La estructura de clases de este ejercicio, está muy bien.
Realmente has distribuido a la perfección los atributos a sus clases tal como se pedía en el enunciado.

Y el esquema que has enviado se confirma en BlueJ al compilar tu proyecto. Bien.

El código en las clases también lo veo correcto. Y mostrando cada clase sus atributos propios y los de su clase padre. Muy bien.

Realmente este ejercicio se las traía. Te ha salido muy bien.

Y aunque has cumplido todo lo que se pide para este ejercicio, te habría quedado muy bien un menú en el main para poder añadir productos a discrección. Espero que no descartes en el futuro añadir ese menú, tu proyecto quedará perfecto.

Ah, un buen truco la clase Exibidor. Los métodos que tiene son sencillos pero facilitan adornar la salida por consola.
Por cierto el método 'mostrarEncabezadoProductoTipo' no lo has utilizado. Tal vez lo aprovecharás en otra versión futura.

Saludos.

[Alex Rodríguez]

Hola Raga, no voy a entrar a valorar el código, que entiendo implica un gran esfuerzo y por tanto un mérito para quien lo desarrolla. Me voy a centrar en el diseño. En la solución propuesta al ejercicio se ha creado una relación de herencia entre ProductoRefrigerado y ProductoCongelado

public class ProductoRefrigerado extends ProductoCongelado

Esto no es correcto porque aunque tuvieras razones como programador, la programación no debe ir en contra de la lógica del mundo real. En este caso si un producto refrigerado heradara de un producto congelado significaría que un producto refrigerado es un tipo de producto congelado, pero esto no es así (ver enunciado).

El diseño tiene un fallo grave: no existe una clase Producto, de la cual deben heredar ProductoCongelado, ProductoRefrigerado y ProductoFresco.

Esa relación de herencia sí sería correcta: un Producto congelado es un tipo de producto, un producto refrigerado es un tipo de producto, y un producto fresco es un tipo de producto.

Eso significa un fallo en el apartado a):

a) En primer lugar realizar un esquema con papel y bolígrafo donde se represente cómo se van a organizar las clases cuando escribamos el código. Estudiar los atributos de las clases y trasladar a la superclase todo atributo que pueda ser trasladado.

Al fallar el apartado a), falla todo lo demás.

Te recomiendo replantear el código teniendo esto en cuenta. Es útil ver las propuestas de otros compañeros, por ejemplo la de https://www.aprenderaprogramar.com/foros/index.php?topic=2342

Saludos

[RaGa]

Muchas gracias Tony!, muchas gracias Alex!

Correcciones Tony:

... te habría quedado muy bien un menú en el main para poder añadir productos a discreción.

Si, pienso incorporar un Menú en ejercicios siguientes. Lo había pensado para este mismo, pero no quise complicar su corrección, y centrar el foco más bien en los conceptos de herencia. Pero me interesa mucho hacer los proyectos "amigables" con el usuario.

Ah, un buen truco la clase Exibidor. Los métodos que tiene son sencillos pero facilitan adornar la salida por consola.

La clase Exibidor la había creado en el ejercicio anterior y la volví a emplear en este nuevo ejercicio, aunque solo utilizo uno de sus métodos esta vez.

Correcciones Alex:

...aunque tuvieras razones como programador, la programación no debe ir en contra de la lógica del mundo real. En este caso si un producto refrigerado heradara de un producto congelado significaría que un producto refrigerado es un tipo de producto congelado...

El diseño tiene un fallo grave: no existe una clase Producto, de la cual deben heredar ProductoCongelado, ProductoRefrigerado y ProductoFresco.

Creo que pequé de querer "ahorrar" código dejando de lado lo que dices: "la programación no debe ir en contra de la lógica del mundo real ", y el concepto de que un padre hereda a sus hijos, por más que un hijo sea casi exactamente igual a su padre.

Agradeciéndoles el trabajo que se toman en corregirme, re subo el ejercicio en archivos adjuntos para su revisación. Muchas Gracias!

[Alex Rodríguez]

Hola RaGa ahora el diseño del esquema lo veo completamente correcto. Sin embargo, dentro del código hay cosas que no parecen correctas.

Em la clase Producto tienes estos atributos:

Código: [Seleccionar]

    private String nombre;
    private String fechaDeCaducidad;
    private int nroLote;
    private String paisDeOrigen;
    private String fechaDeEnvasado;
Sin embargo esta clase sólo debería manejar los atributos comunes a todos los productos, que son fecha de caducidad y número de lote.

La información específica debe ir en las clases correspondientes, por ejemplo en la clase ProductoFresco deberías tener los atributos específicos de ProductoFresco, en la clase ProductoRefrigerado los atributos específicos de ProductoRefrigerado, etc.

También se puede hacer lo que propone el enunciado

Crear superclases intermedias (aunque no se correspondan con la descripción dada de la empresa) para agrupar atributos y métodos cuando sea posible. Esto corresponde a “realizar abstracciones” en el ámbito de la programación, que pueden o no corresponderse con el mundo real.

Te recomiendo ver con calma cómo está resuelto por otro compañero en https://www.aprenderaprogramar.com/foros/index.php?topic=2342.0 viéndolo creo que puedes mejorar tu ejercicio

Saludos

[RaGa]

Muchas gracias Alex!

Mira, analicé nuevamente como me pedías los campos de cada una de las clases, e incluso releí el enunciado del ejercicio.
Realmente no encuentro errores en cómo diseñé las clases conteniendo esos atributos (y me preocupa no encontrar el error que me marcas).
 
Si bien: fecha de caducidad y número de lote son comunes tanto a Producto Fresco, como a Producto Congelado, y a Producto Refrigerado; hay además otros campos que son también comunes a las tres clases, y por tanto (creo) deben incluirse en la clase padre Producto.
Si tanto Pais de Origen y Fecha de Envasado son comunes a los tres tipos de productos, ¿debería incluirlas como campos de una clase intermedia? ¿No sería más apropiado -siguiendo la filosofía de Herencia- incluirlas en la clase padre?.

En el ejercicio del link que me sugieres revisar las clases están planteadas de la misma manera en que lo planteé, incluyendo los mismos atributos en las mismas clases.

He quedado un poco desconcertado ciertamente y pido disculpas por extender tanto este hilo. No logro darme cuenta lo que está mal y no quisiera seguir avanzando con esta duda.

[Alex Rodríguez]

Hola RaGa, puede que me haya equivocado en algo... con tanto código y tanto ejercicio no me extrañaría...  voy a volver a mirarlo a ver

[Alex Rodríguez]

Veamos... estoy mirando el archivo CU00687B (corregido).rar

En la clase Producto tenemos

    private String nombre;
    private String fechaDeCaducidad;  -- > Común a todos los productos
    private int nroLote;  -- > Común a todos los productos
    private String paisDeOrigen; -- > Común a todos los productos
    private String fechaDeEnvasado; -- > Común a todos los productos

Por tanto tienes tú razón... me equivoqué al hacer el comentario anterior quizás lo confundí con la versión anterior o no sé por qué. Leyendo el enunciado ahora no veo razón para hacer ese comentario.

Así que perdón por el error, ¡lo siento!

Saludos

[RaGa]

No por favor Alex, nada que perdonar, al contrario, soy yo (y seguramente muchos más) los que les agradecemos a uds. dediquen diariamente su tiempo en ayudarnos en nuestro aprendizaje.

Y es más, hasta podríamos considerar este hecho como algo positivo: ¡son personas reales! desconfiaba podrían ser una especie de "algoritmo corrector imbatible" jeje (una pequeña broma  ).

Muchas gracias, sigo adelante con las lecciones.