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

Ya veo bartvander que pones rumbo a septiembre... aunque yo me esperaría a que salgan las calificaciones, siempre puede haber alguna sorpresa. Para quien sueñe con septiembre

PREGUNTA: ¿Esta expresión podría formar parte del código de un programa?
assert this.isEmpty() == true;

RESPUESTA: Sí, corresponde a una aserción y puede formar parte del código Java. Una aserción puede verse como un formalismo lógico para la verificación de la corrección de un programa.

PREGUNTA: ¿Una sentencia try puede carecer de catch?


RESPUESTA: Sí, si el error se va a propagar puede existir un try sin catch.

Animo a todos. Por si sirve de consuelo, tener en cuenta que los conocimientos que se han adquirido no se perderán de aquí a septiembre si es que toca volver. Y tener en cuenta que a veces las notas pueden variar incluso después de publicadas si se detectan erratas en los enunciados o solucionarios del examen, cosa que no es la primera vez que pasaría. 

MUCHA SUERTE A TODOS LOS QUE SE EXAMINAN MAÑANA!!!!!!

Espero que después del examen se acuerden y dejen alguna pregunta y respuesta por aquí para ir completando la colección.

Y alguna recomendación... para quien quiera tomarlas en cuenta.  Mantengan la calma. Conocer todo Java es imposible, no pretendan abarcarlo todo en unas pocas horas que quedan. Y en la parte práctica, traten de responder todos los apartados calculando el tiempo disponible, no se enrollen con un apartado y dejen los demás sin responder.

Pregunta planteada por bartvander:

Pongamos el enunciado completo:

Pregunta 6

Sea "c1" una clase con 6 atributos, y sea "c2" otra clase con 3 atributos, 3 de los atributos de "c1" son los de la clase "c2". Tienen los mismos métodos aunque algunos se comportan de manera diferente. ¿Qué relación de herencia es la correcta y por qué?

a) No se puede establecer herencia dado que los mismos métodos se comportan de manera diferente
b) No se puede establecer herencia dado que los atributos no son exactamente los mismos
c) "c2" es hija de "c1" dado que todos sus atributos están incluidos en "c2"
d) "c1" es hija de "c2" dado que incluye sus atributos y añade nuevos

a No es correcta porque puede haber herencia con sobreescritura de métodos.
b No es correcta. En herencia los atributos no tienen que ser exactamente los mismos
c No es correcta porque una clase hija debe tener al menos los mismos atributos que la superclase
d Puede ser ser herencia (respuesta a marcar)

bartvander: recuerda una cosa --- > Las subclases pueden sobreescribir los métodos de las superclases haciendo que el comportamiento sea distinto según se invoque sobre un objeto de la superclase o de la subclase.

Esta pregunta ha sido revisada gracias a Array, aportación de junio de 2013. Gracias! 

Si ponemos el enunciado completo creo que mejor.

Pregunta 9 ¿Qué tipo de acceso se puede emplear para sobrecargar los métodos que implementan una interfaz?

a) Pueden ser métodos con acceso public y private, pero no protected
b) Sólo pueden ser con acceso public
c) Sólo pueden ser con acceso private
d) Pueden emplear cualquier tipo de acceso de Java

RESPUESTA CORRECTA: la d)

Si revisamos las definiciones formales de sobrecarga y sobreescritura tendríamos:

Sobrecarga: Cuando más de un constructor o método tienen el mismo nombre pero distintos parámetros decimos que el constructor o método está sobrecargado. La sobrecarga de constructores o métodos permite llevar a cabo una tarea de distintas maneras (por ejemplo crear un objeto Persona con un nombre ya establecido o crearlo sin nombre establecido).

Sobreescritura: Decimos que un método está sobreescrito cuando está presente, exactamente con la misma signatura, en una subclase y en una superclase.

Inicialmente pensábamos que la respuesta era la b), pero por confusión entre sobrecarga y sobreescritura. Ahí estaba "el desliz": solo se puede sobreescribir con acceso public, en cambio la sobrecarga (mismo método con distintos parámetros) se puede hacer usando cualquier tipo de acceso.

Usando este código:

interface A {
    public void C();
}

public class B implements A{
    public void C(){}
    private void C(int b){}
}
Comprobamos que el método definido en la interfaz se puede sobrecargar con cualquier tipo de acceso.

En cambio solo se puede sobreescribir con acceso public: si usamos este código de prueba

public class PerezosoTest implements Comparable{
    public static void main (String[] Args){
        System.out.println ("Probando");
    }

    public int compareTo(Object o) {
        //Prueba
        return 1;
    } 
}

Comprobaremos que el intentar sobreescribir el método con protected o private no es permitido.

Recordar una cosa: en una interface todo método es abstracto y público sin necesidad de declararlo.

Un método de una interface no se puede sobreescribir basándonos en un tipo de acceso menos amplio que aquel que se tiene en la interfaz, que es public.

Sin embargo, sí se puede sobrecargar usando otros tipos de acceso.

Hola bartvander, trato de completar las respuestas sobre tipos de un post anterior. Viendo las preguntas, me da la impresión de que no has hecho pruebas con el compilador. Y si no haces pruebas y no escribes código, el estudio de la asignatura se te complica, porque muchas de los problemas de programación (incluso a nivel profesional) se resuelven a base de prueba y error, delante del ordenador. Está bien compaginar el estudio sobre "papel" o "libros" con estudio con el ordenador, no dedicarle todo el tiempo ni una cosa ni a otra. Pero te repito que si te pones delante del ordenador, tú mismo deberías ser capaz de resolver muchas de las dudas que te surgen.


YA RESPONDIDAS EN ANTERIOR POST

float foo = -1;  No entiendo por que es un float si no tiene el punto no es decimal.
float foo1 = 1.0; No entiendo por no es float si es decimal.


PENDIENTES DE RESPONDER

float foo2 = 42e1; Correcto no es float por que no es decimal

Yo diría que no es float porque el compilador java no admite la notación exponencial en la declaración de variables de tipo float. En realidad, si declaras foo2 como double verás que sí funciona y si lo imprimes por pantalla obtienes 420.0. Es decir, sí es decimal, lo que pasa es que el compilador no admite tratar de construir un float de esa manera (lo restringe para tipos double). No obstante, puedes forzar la construcción de foo2 a float escribiendo float foo2 = (float)42e1;
En este caso lo que hacemos es declarar que el double 42e1 debe transformarse a float, y así lo hace el compilador sin problemas.


float foo3 = 2.02f; no se porque no es float

¿Por qué dices o piensas que no es un float? Si lo pruebas en un pequeño programa verás que sí es un float. Tienes que trabajar haciendo pruebas con el ordenador delante, porque hay cosas que estudiarlas como se estudiaría otra materia es imposible.



float foo4 = 3.03d; no se porque no es float

Pues no es un float porque estás escribiendo 3.03d donde la d final significa que ese número es un double. Y si dices que es un double, no es un float. Si quieres puedes forzar la conversión a float escribiendo: float foo4 = (float)3.03d;
Pero esto es un poco enrevesado, aunque no está de más saber que poderse se puede.


float foo5 = 0x0123; No se porque es float

Vamos a ver, yo esto me lo aprendería de memoria. "Cualquier dirección de memoria escrita como 0xN, donde N representan a un valor dentro del rango de los enteros (pueden ser 1, 2, 3 ... hasta 8 dígitos), puede ser asignada a cualquier tipo numérico, sea tipo primitivo o tipo objeto. ¿Por qué? Porque el compilador en esas direcciones de memoria encuentra valores numéricos y las asimila a cualquier cosa que tú le digas (int, double, float, Integer, etc.). ¿Y por qué el compilador responde así? Pues porque los creadores de Java han querido que sea así. No le daría más vueltas. Si quieres, haz pruebas con el compilador.


double foo6 = 3.03d; no se porque no es float

Caso idéntico a uno ya explicado anteriormente.


double foo7 = 0x0123; No se porque es float

Lo que no sé yo es por qué opinas o crees que es un float, cuando estás declarando que es un double es que es un double. Si ejecutas este código en el compilador verás que te salta un error:

double foo7 = 0x0123;
float flinflanflin = foo7;

¿Por qué? Pues porque foo7 no es un float.



double foo8 = 0x012345; No se porque es float

Caso idéntico a uno ya explicado anteriormente. foo8 es un double, no un float


double foo9 = 0x012345678; No se porque es float

Caso idéntico a uno ya explicado anteriormente. foo8 es un double, no un float


double foo10 = 0x0123456789; No se porque es float

foo10 no es un float. Si fuera algo, sería un double. De cualquier manera, a mí al probarlo me da error porque me dice que 0123456789 es un número fuera del rango de los enteros.

Aniita... me estás subiendo el nivel!!!. Esta última pregunta no la veo una chorrada porque elegir entre la c) y la d) no es tan obvio... hay algunas preguntas que tengo que mirar con calma porque me mareo con solo leerlas 

ufff!

¿los foros tienen sentido? Reflexión demasiado trascendental para poder procesarla ---> nosferacento.java.lang Index out of Memory 

Y sobre lo de ceporrinos, igual podíamos formar un club... el mundo está lleno de gente como nosotros.

Veamos las cuestiones que planteas, por lo menos para tratar de ir digiriendo algunas:

float foo = -1;  No entiendo por que es un float si no tiene el punto no es decimal.


RESPUESTA: partamos de repasar los conceptos de autoboxing y unboxing en Java. Cada tipo primitivo en Java tiene su tipo equivalente objeto. Por ejemplo el primitivo int, el objeto Integer. Estos tipos objeto se denominan "tipos envoltorio".

Hay clases java como ArrayList que solo admiten objetos. ¿Se complica entonces el trabajar con ArrayList de números simples que sean int? Los creadores de Java previeron este problema y para ello crearon lo que se denomina "Autoboxing y unboxing" o "Conversión automática de tipos". El compilador de Java realiza un proceso en segundo plano por el cual cuando se espera un tipo envoltorio y se le pasa un primitivo realiza una conversión para adaptarlo (autoboxing), o al revés, cuando se espera un primitivo y se le pasa un envoltorio, transforma automáticamente el envoltorio evitando que salte un error.

Entonces, el compilador de Java en algunas ocasiones es muy exigente y nos obliga a hacer cosas de forma estricta, y en otros casos nos ayuda realizando conversiones automáticas similares a lo que hemos comentado.

¿Qué pasa cuando ejecutas esto?

public class PerezosoTest {
    public static void main (String[] Args){
        float foo = -1;     
        System.out.println ("Probando" +foo);
        }
}


Por arte de birlibirloque tú habías escrito -1 y en pantalla te sale Probando -1.0

¿Qué te está devolviendo? Un float

¿Por qué te devuelve un float? Porque el compilador de Java cuando recibe un número entero asignado a una variable float, lo transforma automáticamente.

¿Y cómo se entera uno de estas cosas? Pues haciendo pruebas como esta que te he puesto aquí arriba y dedicándole tiempo. Si los creadores de Java hubieran decidido que en vez de hacer esta conversión automática saltara un error, pues saltaría un error. Quienes no hemos sido los creadores tenemos que averiguarlo.

POSIBLE RESPUESTA PARA EL APARTADO a) PARTE PRÁCTICA EXAMEN SEPTIEMBRE 2011 TIPO A

Ojo: esto es la respuesta que daría yo. No quiere decir que sea la respuesta correcta. Se puede tener en cuenta a modo de orientación, pero no es “la respuesta exacta”.

a)   Definiremos una clase abstracta denominada Mensaje de la cual heredarán las clases Carta, Email y MovilMsg.

Mensaje la declaramos abstracta porque no vamos a instanciarla.

Definiremos otra clase denominada ProductoF, también abstracta porque no vamos a instanciarla tampoco, de la cual heredarán las clases que representarán a los distintos tipos de productos financieros: TarjetaCredito, TarjetaDebito, PlanPensiones, Seguro, FondoInversiones.

Usar una clase abstracta nos permite:

a)   Unificar los campos y métodos que van a tener en común todos los productos financieros.

b)   Obligar a que todos los productos financieros implementen los métodos abstractos que podamos definir en la clase ProductoF

c)   Valernos del polimorfismo que alcanzamos al declarar variables de tipo ProductoF.

Por ejemplo: ProductoF prod1 = new TarjetaCredito();

ProductoF prod2 = new PlanPensiones();

… etc… etc…


El tipo dinámico puede variar, pero al tener un mismo tipo estático podemos agrupar variables de tipo ProductoF en colecciones como ArrayList y realizar un tratamiento conjunto.

Los productos en sí estarán materializados en clases concretas, instanciables.

Definiremos otra clase Cliente entre cuyos campos tendremos un campo que represente la colección de productos contratados por el cliente (por tanto la clase Cliente mantiene una relación de uso con la clase ProductoF).

Otra clase será Preferencia. La definiremos como tipo enumerado y servirá para identificar los posibles tipos de preferencias de los clientes.

Finalmente la clase GestorBanco será la encargada de recibir los datos del cliente y gestionar el envío del agradecimiento a cada cliente.



Esto es más o menos una respuesta... repito que es orientativa, no la "solución oficial".

Gracias a todos y todas los que dan ánimos