Ejercicio crear un diseño orientado a objetos con herencia Java CU00688B

[RaGa]

Mi versión del Ejercicio propuesto en la Entrega Nº88. Ejercicio CU00688B.

He ampliado un poco más el ejercicio respecto de lo que se pedía. Espero sea aceptada esta licencia que me he tomado. 

[Mario R. Rancel]

Hola RaGa has hecho un código amplio en el que se ven buenas ideas como la clase GestionadorEntradasTeclado y VisualizadorMenues que tienen nombres muy descriptivos.

En general todas las clases están bien nombradas excepto dos: Lista y ListaDeProducto

Veo dos problemas con el nombre de la clase Lista:

-Es muy similar a un nombre reservado de Java: List, lo que la hace confusa.

- No describe qué es lo que hace la clase (sus responsabilidades) (¿es una lista de cualquier cosa se preguntaría alguien que la viera sin ver el código?)

Si la clase Lista representa una lista de productos debería llamarse ListaDeProductos.


Hay una cuestión del diseño que no acabo de entender.


En la clase ProductoCongeladoPorAgua tienes un atributo private int salinidadDelAgua; y en la clase ListaDeProducto tienes repetido este atributo, y así también con otros atributos...

A no ser que se pueda justificar con motivos de peso, la repetición de información en distintas partes del código se considera reflejo de un mal diseño.

La clase ListaDeProducto básicamente lo que permite es pedir los datos de productos. Aparentemente no hay necesidad de almacenar los atributos que almacena esta clase, porque estos ya pueden ser almacenados en las distintas clases que representan a los productos.

Pienso que deberías renombrar la clase ListaDeProducto como PreparadorDeProductos ó GestorDatosProductos, y dicha clase se encargaría de pedir los datos de los productos y devolver un objeto del tipo procedente (por ejemplo ProductoCongeladoPorAgua) con los datos recibidos.

La clase ListaDeEnvio tampoco tiene un nombre claro ni se le ve una funcionalidad clara. Si es simplemente para añadir un atributo, parece más lógico hacerlo en la superclase y en caso de no existir valor para dicho atributo mantenerlo vacio o como "Sin cliente".

Es una idea, porque realmente no conozco cuál ha sido tu forma de pensar a la hora de crear este esquema. Sería bueno que dieras una explicación de qué representa cada clase según tu lógica.

Saludos

[RaGa]

Muchas gracias Mario por las correcciones y por el aliento.

Veamos entonces...

La clase ListaDeEnvio tampoco tiene un nombre claro ni se le ve una funcionalidad clara. Si es simplemente para añadir un atributo, parece más lógico hacerlo en la superclase y en caso de no existir valor para dicho atributo mantenerlo vacio o como "Sin cliente"

Estoy totalmente de acuerdo!
En mi anterior versión había hecho la siguiente organización de herencias:

ListaDeProducto --> Lista <--- ListaDeEnvio

pensando que al haber aunque sea un campo diferente, debía (a los fines didácticos) armar una nueva clase hija. Pero ahora me doy cuenta con lo que me dices, que a la hora del buen diseño debo incluir ese campo en una misma clase, y luego sus instancias lo utilizarán o no.

La clase ListaDeProducto contiene solo un método cuya función es crear un producto de cualquier tipo, y tienes toda la razón en las observaciones que me haces sobre la misma. En esta nueva versión del ejercicio que les envío esta clase se renombró. Ya no es hija de nadie y se llama PreparadorDeProductos, siendo sus atributos ahora atributos de clase y no de instancia.

Volviendo entonces a la clase ListaDeEnvio: al haber incluído entonces el campo "extra" en la clase padre de la organización original, lo que me dices tu :

Si la clase Lista representa una lista de productos debería llamarse ListaDeProductos

ahora en la nueva versión lo que antes era la clase Lista se llama ListaDeProducto (no hereda a nadie, e incluye un campo que no siempre se utilizará). Desaparece la clase ListaDeEnvio.

Espero haber sido claro en los cambios 

Pongo nuevamente a disposicion el ejercicio para su corrección. Muchas gracias!

[Mario R. Rancel]

Hola, ahora el diseño sí se ve mucho mejor armado y los nombres de clase mucho más coherentes. Creo que el ejercicio lo puedes dar por resuelto, el programa funciona perfectamente. De todas formas te voy a comentar todo lo que he visto.

La clase Producto la veo correcta, también ProductoFresco, ProductoRefrigeradoCongelado, ProductoRefrigerado, ProductoCongelado, ProductoCongeladoPorAgua, ProductoCongeladoPorNitrogeno, GestionadorEntradasTeclado, VisualizadorMenues, PreparadorDeProductos.

En la clase ListaDeProducto usas

        for (Producto tmp:miLista){
            System.out.println("Producto Nº: "+posicion);
            System.out.println(tmp.mostrarProducto());
            posicion++;
        }

Normalmente si necesitamos un índice (como posicion) usamos un for normal, el for extendido es más habitual cuando no necesitamos índice o cuando no sabemos el número de elementos en una colección. De todas formas se puede hacer como lo has hecho.

En ProductoCongeladoPorAire has utilizado como atributo un array  private int[] composicionDelAire; considerando que los distintos campos se corresponden con un componente:

nitrogeno = composicionDelAire[0];
oxigeno = composicionDelAire[1];
co2 = composicionDelAire[2];

Si ves otros ejercicios resueltos otros compañeros suelen definir tres int en lugar de un array, pero como tú lo has hecho también está bien y sirve para ver distintas formas de trabajar, es bueno saber aplicar distintos recursos.

En la clase EnviosADomicilio se ve algo extraño. Los atributos son:


    ListaDeProducto listaProductosPedidos;
    ArrayList<ListaDeProducto> miListaDeEnvios;


El nombre de la clase parece dar a entender que la clase representa un envío a domicilio, aunque en la descripción pone

 * clase EnviosADomicilio
 * Esta clase sirve para crear y manipular los pedidos de envío a domicilio realizados por los clientes.

Creo que el diseño mejoraría si por un lado tienes una clase Envio que represente un envío, y por otro lado una clase ListaDeEnvios si consideras que te es necesaria, y por otro lado una clase GestorDeEnvios si consideras que es necesaria. Parece que en esta clase has mezclado varias cosas, y cada clase debe representar algo concreto y tener unas tareas concretas. Es algo interesante tener en cuenta para futuros programas.

Saludos!

[RaGa]

Muchas gracias Mario por tus correcciones. Tomo nota de las observaciones que me has hecho.
Seguimos adelante!