Mostrar Mensajes
501
Aprender a programar desde cero / Re:Ejercicio! entrega CU00687B
« en: 27 de Agosto 2014, 12:16 »
Hola Sniper, te comento cómo podría ser un enfoque-respuesta del ejercicio que en parte coincide con el tuyo pero en otra parte no:
Hay tres tipos de productos (frescos, refrigerados, congelados) y llevan como información común fecha de caducidad y número de lote.
Los atributos y métodos relacionados con esta información común los agrupamos en una superclase denominada Producto.
A su vez de acuerdo con la descripción del ejercicio podemos identificar que hay más atributos comunes a estos tres tipos de productos, en concreto la fecha de envasado y el país de origen. Por tanto esto también es común y lo trasladaríamos a la superclase Producto, que constaría de estos atributos:
fecha de caducidad, número de lote, fecha de envasado y país de origen.
Ahora tenemos atributos que sólo aparecen en una clase concreta como:
Productos refrigerados: código del organismo de supervisión alimentaria, temperatura de mantenimiento recomendada.
Productos congelados: temperatura de mantenimiento recomendada.
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.
Nos quedan los productos congelados: cada clase de producto congelado tiene sus atributos propios y no hay atributos comunes (puesto que la temperatura de mantenimiento recomendada la hemos trasladado a ProdRefrigeradoOcongelado. Si la clase queda "vacía" podríamos pensar en no contemplarla en el esquema, pero en este caso lo más lógico es sí hacerlo porque así es como mejor describimos la estructura de funcionamiento de la empresa y como mejor podemos dejar organizado el código para ampliarlo en el futuro.
El esquema de herencia queda de la siguiente manera:
En la cima de la jerarquía: clase Producto
Subclases de la anterior: ProductoFresco y ProdRefrigeradoOcongelado.
Subclases de ProdRefrigeradoOcongelado: ProductoRefrigerado y ProductoCongelado.
Subclases de ProductoCongelado: ProdCongeladoPorAire, ProdCongeladoPorAgua, ProdCongeladoPorNitrogeno.
Sobre la duda que planteas:
Respuesta: al crear un diseño tienes que tener en cuenta diversos factores (entre ellos la repetición de código, pero también otros como la mantenibilidad del código, representación de la estructura de trabajo de la empresa en código, etc.). Atendiendo a esto, aunque la clase ProdFresco quede sin contenido propio, sí sería conveniente mantenerla en el código, de cara al futuro, y de cara a poder trabajar representando la realidad de la empresa: por ejemplo si quieres crear una colección de objetos y que quede claro que son productos frescos, usarías esta clase aunque no tenga atributos y métodos propios.
Fallos o cosas extrañas que veo en tu diseño: tienes una clase denominada AbstraccionProd cuya única subclase es Producto. La herencia normalmente se utiliza cuando varias subclases comparten características de una superclase. Normalmente no tendremos una única clase como heredera de una superclase (a no ser que fuera con vistas a ampliabilidad futura del programa). ¿Por qué has creado una clase AbstraccionProd en lugar de tener simplemente Producto como superclase? A priori no se le ve lógica (igual sí podría dársele una explicación, pero yo no se la veo).
Todo lo anterior trata de reflejar cuestiones a mejorar o sobre las que reflexionar, pero en conjunto tu esquema es bueno y tu código es bueno (haces buen uso de herencia, super, etc.)
Me he alargado un poco, y eso que no he entrado a hablar del caballo blanco de napoleón...
Saludos,
Hay tres tipos de productos (frescos, refrigerados, congelados) y llevan como información común fecha de caducidad y número de lote.
Los atributos y métodos relacionados con esta información común los agrupamos en una superclase denominada Producto.
A su vez de acuerdo con la descripción del ejercicio podemos identificar que hay más atributos comunes a estos tres tipos de productos, en concreto la fecha de envasado y el país de origen. Por tanto esto también es común y lo trasladaríamos a la superclase Producto, que constaría de estos atributos:
fecha de caducidad, número de lote, fecha de envasado y país de origen.
Ahora tenemos atributos que sólo aparecen en una clase concreta como:
Productos refrigerados: código del organismo de supervisión alimentaria, temperatura de mantenimiento recomendada.
Productos congelados: temperatura de mantenimiento recomendada.
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.
Nos quedan los productos congelados: cada clase de producto congelado tiene sus atributos propios y no hay atributos comunes (puesto que la temperatura de mantenimiento recomendada la hemos trasladado a ProdRefrigeradoOcongelado. Si la clase queda "vacía" podríamos pensar en no contemplarla en el esquema, pero en este caso lo más lógico es sí hacerlo porque así es como mejor describimos la estructura de funcionamiento de la empresa y como mejor podemos dejar organizado el código para ampliarlo en el futuro.
El esquema de herencia queda de la siguiente manera:
En la cima de la jerarquía: clase Producto
Subclases de la anterior: ProductoFresco y ProdRefrigeradoOcongelado.
Subclases de ProdRefrigeradoOcongelado: ProductoRefrigerado y ProductoCongelado.
Subclases de ProductoCongelado: ProdCongeladoPorAire, ProdCongeladoPorAgua, ProdCongeladoPorNitrogeno.
Sobre la duda que planteas:
Código: [Seleccionar]
Hola!
me ha surgido la siguiente situación en el desarrollo del código de este ejercicio:
Todos los atributos en común entre las clases, los e movido a una super clase, por lo que tengo clases con atributos y métodos propios y clases con atributos y métodos heredados.
Como consecuencia de esto, la clase ProdFresco se ha quedado sin atributos y métodos propios y hereda estos de su super clase.
Si observamos las clases Producto y ProdFresco, se puede apreciar que prácticamente han quedado idénticas, por tanto "no habría" ningún inconveniente en usar una u otra en la clase con el main para crear lo que seria un objeto tipo ProdFresco.
Una posible solución para hacer a la clase ProdFresco, única y diferente a su super clase, seria agregarle un atributo en especifico, por ejemp: float pesoNeto; pero esto difiere con lo requerido en el enunciado del ejercicio, donde este pide que la clase ProdFresco contenga los atributos heredados de la super clase Producto + 2 atributos en especifico (4 atributos en total)
Mis dudas son: tomando en cuenta la situación de igualdad (parentesco) alcanzada entre las clases Producto y ProdFresco, es necesaria la clase ProdFresco?
Se podría considerar como repetición de código en package al tener 2 clases "idénticas"?
debo hacer que ambas clases sean semejantes pero con diferencias, o pueden coexistir tal y como están?
De que color era el caballo blanco de napoleón bonaparte?
Ups! esa ultima duda la pueden omitir creo que ya la tengo clara Jejejeje
Gracias por leer estas dudas, Saludos!
Respuesta: al crear un diseño tienes que tener en cuenta diversos factores (entre ellos la repetición de código, pero también otros como la mantenibilidad del código, representación de la estructura de trabajo de la empresa en código, etc.). Atendiendo a esto, aunque la clase ProdFresco quede sin contenido propio, sí sería conveniente mantenerla en el código, de cara al futuro, y de cara a poder trabajar representando la realidad de la empresa: por ejemplo si quieres crear una colección de objetos y que quede claro que son productos frescos, usarías esta clase aunque no tenga atributos y métodos propios.
Fallos o cosas extrañas que veo en tu diseño: tienes una clase denominada AbstraccionProd cuya única subclase es Producto. La herencia normalmente se utiliza cuando varias subclases comparten características de una superclase. Normalmente no tendremos una única clase como heredera de una superclase (a no ser que fuera con vistas a ampliabilidad futura del programa). ¿Por qué has creado una clase AbstraccionProd en lugar de tener simplemente Producto como superclase? A priori no se le ve lógica (igual sí podría dársele una explicación, pero yo no se la veo).
Todo lo anterior trata de reflejar cuestiones a mejorar o sobre las que reflexionar, pero en conjunto tu esquema es bueno y tu código es bueno (haces buen uso de herencia, super, etc.)
Me he alargado un poco, y eso que no he entrado a hablar del caballo blanco de napoleón...
Saludos,
RSS