Diseño de clases orientado a objetos, Calendar, SimpleDateFormat (CU00688B)

[Lorenzo31]

Buenas tardes, dejo aquí la solución del ejercicio, es el 687B pero solucionando el Calendar mucho mejor, con una interclase entre Refrigerados y Congelados ( no me di cuenta de la variable temperatura comun y sus metodos) y rectificar es lo que toca cuando se es novato.

Sin mas ahí va, solo decir que

a) Una clase EnvioDeProductos que represente un envío de productos como colección de objetos que admite el polimorfismo.

Sustituí EnvioDeProductos por Operar y ahi listo y otras cosas. Una clase mas completa.

Añado un .zip con el ejercicio porque sino aquí pegando clases...

[Mario R. Rancel]

Hola Lorenzo, has creado un código bastante completo y extenso. Recomendaciones varias:

- Una recomendación que habrás leído en otros hilos: darle nombres a las clases que sean coherentes con la orientación a objetos. No suena bien "he creado un objeto Recoger". Los nombres deben ser sustantivos como RecogedorDeDatos, OperadorDeDatos, etc. Nombres como Operar y Recoger no son buenos nombres para clases.

-  La clase Recoger la defines con atributos y métodos estáticos (static) y después la invocas directamente desde la clase con el main por ejemplo numeroMenu = Recoger.menu();

Esto aunque es posible no es coherente con la filosofía de orientación a objetos. Sería preferible que declares una clase "normal" y luego crees una instancia de dicha clase dentro de la clase con el main y trabajes con el objeto creado.

- En el diseño de clases, no veo muy lógico crear una subclase de PCongelado que agrupe a todos los tipos de productos congelados. La idea más bien sería tener tres subclases. Si vas a agruparlas en una sola clase, ¿para qué crear una relación de herencia en vez de agruparlas directamente en PCongelado?


Has manejado bien los conceptos de herencia, el uso de super, etc. por ejemplo esto es una buena reutilización de código

    public void mostrarDatos() {
        super.mostrarDatos();
        System.out.println(" su codigo de supervisor es: " + codigoSupervisor + "\n");
    }

También estás utilizando bien distintas clases y métodos del api de Java.

La clase PRefriConge está bien planteada pues agrupa aspectos comunes.

- El ejercico CU00688B pedía crear una clase envío de productos, indicas que en vez de esta clase estaría la clase Recoger -- > problema: con el diseño orientado a objetos tratamos de en la medida de lo posible representar la realidad de los problemas. No es lo mismo un EnvíoDeProductos que un Recoger, esto no se consideraría bien planteado en la programación orientada a objetos.

- Cuando ejecuto un programa si creo un producto congelado me lo muestra por pantalla al pedir mostrar, pero sin embargo si creo un producto fresco no muestra nada por pantalla (esto parece un fallo)


Saludos

[Lorenzo31]

Buenos días Mario, empiezo por el final, me parece entender que dices no muestra los productos frescos si creas uno.

Lo he verificado y si los muestra, lo que ocurre esq se imprime pegado al menu que sale de nuevo, quizá por eso no se ve bien, le voy a añadir un "\n" inicial al menu para que se separe de los datos imprimidos.

Respecto a los nombres, entendido, nombres consecuentes con lo que hace la clase, tambien lo cambio.

Creo clase EnvioDeProductos, pues comprendo que otro que venga, conceptualmente le es mas facil entender el codigo con ese nombre y creo una nueva instancia y le quito el static a esta clase, pero podrías explicarme porque es mejor crear nueva instancia que usar sus métodos en static como una clase abstracta?
Más que nada porque parece algo importante y en el futuro quisiera tenerlo claro.

Adjunto mi ejercicio con tus comentarios corregidos.

Sobre la clase PCongelado, totalmente de acuerdo, dudaba al crear el esquema si agruparlos en PCongelado los tres (Aire, Agua, Hidrogeno), y debí hacerlo pues mi planteamiento lo pedia. no lo hice por practicar Herencia y ya puesto lo correcto era tener tres clases que en una futura modificacion con mayores atributos, sería válida mientras que mi planteamiento no.

Gracias como siempre por el tiempo dedicado y las enseñanzas Mario. Lo repito mucho pero me ayudais infinito.

[Mario R. Rancel]

Hola, ahora sí he visto que muestra los productos frescos. Los nombres de clases ya podemos decir también que son ahora correctos.

creo una nueva instancia y le quito el static a esta clase, pero podrías explicarme porque es mejor crear nueva instancia que usar sus métodos en static como una clase abstracta?

Lo primero es aclarar que el concepto de clase abstracta en Java se refiere a una cosa muy concreta que se explica en la entrega CU00695B del curso y no tiene que ver con static, por tanto no debemos emplear el término abstracto excepto para referirnos a lo que en Java se entiende por abstracto (esto es un pequeño lío, pero es la terminología de java).

El motivo por el que es mejor crear una nueva instancia es para tratar de trabajar como programadores bajo el paradigma o filosofía de la orientación a objetos. Según esta filosofía los programas se conforman mediante la interacción entre objetos. Si defines una clase donde todos sus elementos son estáticos no necesitas crear un objeto para acceder a ella, te estás saliendo de la filosofía de la orientación a objetos. Todo esto tiene una razón de ser, aunque al principio quizás no es fácil entender todos los conceptos y toda la filosofía que encierra este tipo de programación. Un motivo que se suele citar es el de introducir seguridad en el código: dar acceso libre desde cualquier lugar (declarando todo static) del código es más inseguro que forzar a que se cree un objeto, lo cual introduce un mayor grado de control. Es cierto que crear objetos no nos hace buenos programadores, pero entra dentro de lo que se consideran prácticas adecuadas en programación orientada a objetos.

Todo tiene sus excepciones, hay casos en los que trabajaremos con objetos únicos o con clases static, pero no debemos verlo como una práctica habitual, sino algo a usar cuando justificadamente se considere.

Visto el código corregido, lo único que veo faltaría es eliminar la clase PCAireAguaHidro y unificarla dentro de la clase PCongelado.

Saludos!

[Lorenzo31]

Buenas noches Mario, muchas gracias por la aclaración de static no es abstracto, tomo nota.

Y sobre crear con news objetos lo entiendo, es parecido a usar getters y setters en lugar de poner publica la variable, es una forma de garantizar mayor seguridad al codigo, y operar creando objetos y llamar a funciones o metodos de los mismos.


Muchas gracias, sobre lo de unirlo a congelado si lo haré para ser consecuente con lo que de alguna manera ideé.