Foros aprenderaprogramar.com
Didáctica y divulgación de la programación

Hola

Documento muy interesante.

Al leerlo me ha hecho recordar otros escritos donde se recomendaba crear estructuras de clases que resistan el paso del tiempo, que permitan la ampliación de la estructura sin desmontarla.

Esto hace que mis comentarios en hilos precedentes sean inadecuados.
Me refiero a la creación de estructuras de clases organizadas por atributos comunes descartando la clasificación de los objetos en el mundo real (que es lo que en definitiva queremos meter en nuestra estructura de clases)

Erróneamente creia que la compactación de clases y atributos tenía un valor positivo.

Así pues, descarto la compactación y abogo por la modularidad y reutilización en la creación de una estructura de clases.

Saludos

Hola Dan

No sé si has empezado la codificación como dices al final. Aprovecho para hacer mis comentarios a tu esquema/diagrama.

Respecto a tu esquema.
En tu mensaje das razones para hacer tus cambios
1º ProductoFresco no tiene atributos porque los hereda todos de Producto.
Tiene su lógica, viendo los nombres, si, ProductoFresco es un nivel inferior a Producto. Pero en el enunciado no se pide crear la clase Producto.
Yo creo que si a tu clase Producto le cambias el nombre por ProductoFresco y eleminas la clase sin parámetros, tu estructura de clases se mantiene.
Este cambio hará que el resto del productos hereden de ProductoFresco (cosa que no sucede en el mundo real). Pero yo pienso que mientras nuestro proyecto discrimine cada objeto de los demás tendrá una estructura consistente.
Nuestra relación de herencia se basa en los atributos compartidos, no en el nombre que damos a las clases. Tal como interpreto yo en esta parte del enunciado

b) 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.

2º Y siguiendo la premisa anterior yo conservaría a la clase ProductoRefrigerado subclase de ProductoCongelado (atendiéndome siempre a los atributos compartidos)

Lo anterior es opinión mía, la herencia la deciden los atributos no la vida real.

Saludos

Hola fedegaray

Ejercicio correcto. Bien

¿Es posible crear un método en la clase Circulo para establecer el valor de numeroPi? ¿Por qué?

Supongo que no has visto esta pregunta en el enunciado.

Como ya sabrás no se puede cambiar el valor del atributo PI porque se lo ha declarado constante al usar la palabra clave 'final' en su declaración.

Saludos

Hola Lorenzo

Como veo que estás preparado. Voy al ataqueeee.

Todo el código que has enviado, lo he visto siempre muy bien.
Has usado control de excepciones, has creado clases con métodos estáticos que se usan sin instanciar.
Y tu código por decirlo de alguna manera, es ligero, no resulta empalagoso. Es fácil de leer y de seguir. Esto último seguramente gracias a tu experiencia codificando y codificando.

En este ejercicio también aportas cosas nuevas.
Con dos clases (Recoger y EntradaDatos) tienes solucionada la 'recogida' de datos.

Todo esto era para ver si te pillo desprevenido.


Mis comentarios:
Hacer una adaptación del ejercicio anterior, está bien, pero hay que seguir las nuevas condiciones.

Si a tu clase Producto le cambias el nombre y le pones ProductoFresco, tu estructura de clases se mantiene y además el atributo (boolean frescoOno) no parece ser necesario -yo por lo menos no se la veo-.

En el ejercicio anterior no me di cuenta, pero la clase PRefrigerado tiene un atributo igual que el de la clase PCongelado. Para evitar esa duplicidad, hacemos que PRefrigerado herede de PCongelado.

La idea de gestinonar los tres tipos de congelados con la misma clase, es buena. Dices que has simplificado la información de esos productos.
En una de las clases simplificas tres atributos numéricos, en otra dos un String y un valor numérico y en la tercera otro numérico.
Eso es una buena simplificación y una buena abstracción.

Si, esto es una práctica. Pero con los productos congelados en clases individuales y con todos sus atributos este ejercicio sería un buen ejemplo de herencia de clases.

Eso es todo. Se que en otro momento, a este ejercicio o a otro como este le meterás caña y harás una virguería.

Hasta entonces, mis saludos.

PD: Adjunto clase de mi cosecha.
import java.util.Calendar;
/**
 * Detalles de la clase.
 * @author (Toni)
 * @version (0)<br>
 * La clase devuelve con el metodo <b>in</b> una fecha de tipo Calendar aportando dicha fecha en formato String<br>
 * Y con el metodo <b>out</b> devuelve una fecha en formato String aportando la fecha de tipo Calendar
 */
public class Fecha {   
/**
 * @param ddmmaa <br>Este String debe recibir una fecha valida en los formatos: <br>
 * <b>dia/mes/anno</b>, o <b>dia mes anno</b>, o <b>dia-mes</b>, o <b>dia</b>, o una cadena vacia <br>
 * con cualquier caracter separador no numerico entre dia mes y anno
 * @return Y devuelve una fecha de tipo Calendar
 */
    public static Calendar in(String ddmmaa) { //dd-mm-aa  dd/mm/aa
        Calendar fecha1 = Calendar.getInstance();
        String dd="",mm="",aa="";
        int d=0,m=0,a=0;
        char c = ' ';
        ddmmaa = ddmmaa.trim() + " ";
        if (ddmmaa.equals(" ")) {
            // se tomara la fecha de hoy
        } else {
            for (int i = 0; i < ddmmaa.length(); i++) {
                c = ddmmaa.charAt(i);
                if (c==48 || c==49 || c==50 || c==51 || c==52 || c==53 || c==54 || c==55 || c==56 || c==57) {  // solo dígitos del 0 al 9
                    if (d == 0) {        // tomar día
                        dd = dd + c;
                    } else if (m == 0) { // tomar mes
                        mm = mm + c;
                    } else {             // tomar año
                        aa = aa + c;
                    }
                } else    {  // ha aparecido un caracter no dígito
                    if (d == 0) { // tomar día
                        if (!dd.isEmpty()) d = Integer.valueOf(dd);
                    } else if (m == 0) { // tomar mes
                        if (!mm.isEmpty()) m = Integer.valueOf(mm);
                    } else { // tomar año
                        if (!aa.isEmpty()) a = Integer.valueOf(aa);
                    }
                }
            }
        }
//        System.out.println("dd -" + dd + "- mm -" + mm + "- aa -" + aa + "-");
        Calendar fechaHoy = Calendar.getInstance();
        if (a == 0) { // si no hay año se tomam el actual
            a = fechaHoy.get(Calendar.YEAR);
        } else if(a < 1000) { // si el año tiene dos cifras, se le suma 2000
            a = (a % 100) + 2000;
        }
        if (m == 0) { // si no hay mes se toma el actual
            m = fechaHoy.get(Calendar.MONTH);
        } else {
            m = m - 1;
        }
        if (d == 0) { // si tampoco hay dia, se toma el de hoy
            d = fechaHoy.get(Calendar.DATE);
        }
        fecha1.set (a,m,d);
        return fecha1;
    }
/**
 * @return
 * El String devuelto tiene el formato <b>dia/mes/anno</b> tras recibir una fecha de tipo Calendar
 */
    public static String out(Calendar fecha1) {
        int d=0,m=0,a=0;
        d = fecha1.get(Calendar.DATE);
        m = fecha1.get(Calendar.MONTH);
        a = fecha1.get(Calendar.YEAR);
        return d + "/" + (m+1) + "/" + a;
    }
} // Fin de la clase Fecha


Hola Lorenzo

Si. En tu código muestras los datos propios de la clase y los de la padre. Es correcto.

Y no me refiero al nombre que das a los métodos, sino a que los cambios que te propongo tienen dos ventajas:

1ª El mismo nombre en todas las clases. Evita recordar nombres diferentes para diferentes clases.

2ª Al llamar al método para mostrar sus datos, es el propio método el que llama al método padre para mostrar todos los datos siguiendo el árbol de herencia. Esta ventaja es más evidente cuando el árbol de herencia tiene más de un grado/nivel como el actual.

Efectivamente funciona perfectamente, le cambie el int de tamaño al for por un listaProductos.size() y perfecto, por lo que habia leido solo array guarda objetos de diferentes clases, ArrayList tambien lo hace o es que leí mal y LinkedList TreeSet etc tb lo hacen?

Limitar el fin del for con el tamaño de la lista listaProductos.size() es ideal. Respeté la variable 'indice' para no trastocar demasiado tu código.


Ya sabes que la principal diferencia entre array y ArrayList es que:

array puede contener tanto primitivos como objetos, pero solo un tipo cada vez, o un conjunto de primitivos, o uno de objetos, es decir todos los elementos del mismo tipo.

Y ArrayList solo puede contener objetos, no primitivos y también objetos del mismo tipo.

El ArrayList del ejemplo solo guarda objetos de un tipo, el tipo 'Producto'. Es gracias a la herencia, que Java puede distinguir que subclase de 'Producto' está manipulando, ya sea PFresco o PCongelado, etc.

Ya hemos visto en ejercicios anteriores sobre polimorfismo (CU00678B), que se pueden guardar objetos de distinto tipo sin relación de herencia en una colección, cuando todos los objetos pertenecen a la misma interface.


En cuanto a los métodos estáticos en la clase del main.
Me lo has puesto muy fácil, todos esos métodos empiezan por el prefijo 'recoger'.
Pues es una buena idea colocarlos en una clase aparte 'Recoger' tal vez, y dentro de ella los métodos pierden el prefijo 'recoger' y los llamas desde el main por ejemplo así:
    Recoger.menu();
    Recoger.año(boolean envaseOCaducidad);
etc. tal como haces con la clase EntradaDatos.

Si solo fueran dos o tres métodos, tal vez no haría falta, pero ahora tienes unos cuantos y como resultado la clase del main parece más ligera.

Aprovecho la ocasión para apuntar.
BlueJ acepta la 'ñ' en el código, pero no sé otros IDEs o sistemas. De la misma forma que no usamos acentos en el código, es mejor no usar los acentos ni eñes y usar palabras que no incorporen esos signos de puntuación.

Saludos

Hola Lorenzo

Iba a comentar tu mensaje previo, pero al ver tu nueva versión, me tomo mi tiempo para mi nuevo comentario

Saludos y hasta pronto

Hola Dan

Aquí tienes un enlace al mismo ejercicio hecho por otro usuario del foro.
Si quieres hacer tu propia versión para este ejercicio, estudia el código y adáptalo a tu gusto.

https://www.aprenderaprogramar.com/foros/index.php?topic=2229.msg10737#msg10737

Saludos

Hola Dan

Ejercicio correcto. OK

En las preguntas del ejercicio:

¿Qué tipo de datos almacena el array? ¿Qué tipo de datos almacena el ArrayList?

Se pregunta sobre 'el array' y 'el ArrayList' del ejercicio actual, no a 'cualquier array o ArrayList' en el lenguaje de Java.

En la lección CU00669B se explica que un array puede contener tanto primitivos como objetos de cualquier tipo como:
int, double, Integer, Double, Persona, Taxi, etc.

En cambio un ArrayList solo puede contener objetos como:
Integer, Double, Persona, Taxi, etc.

Está bien que juegues con el código probando cosas. Se aprende así.
Pero también se aprende teniendo en cuenta las enseñanzas que recibimos en las clases teóricas.

Saludos

Hola Dan

Ejercicio correcto. Y el main con su menú. OK

La respuesta:

No. Porque el static no se puede declarar en un método. Solo cabecera. Lo unico valido es el final.

Es cierta. Tal como dices no se puede declarar una variable static en un método.

Pero la pregunta era si se puede crear un método (setter) para modificar el valor de numeroPi.
Y la respuesta sigue siendo 'No' porque la palabra clave 'final' convierte el valor en 'constante' que por definición no se puede modificar.

Saludos

Hola Alberto

Tu ejercicio con el bucle for está bien.

Aunque me pregunto porque creas el contador 'a' si ya tienes el contador del bucle for 'i'
Por otra parte la siguiente instrucción
    a = (0 + a);
no tiene ninguna utilidad
    a++;
esta sí

Este ejercicio es bastante sencillo. Quiero proponerte que lo reformes, para quitar código y variables innecesarias. Y ya puestos conseguir una salida del tipo:

Letra 1: a
Letra 2: v
Letra 3: e

Saludos