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

Hola Dan

Creo que tienes que recapitular lo que se ha dicho en este hilo .
En un mensaje previo te motrábamos esta cita

Forma 2 (trabajando con objetos):

Recibir un objeto y crear un nuevo objeto cuyos atributos sean iguales a los del objeto recibido:

    public void setSalonCasa (SalonCasa objetoSalon) {
        salonCasa = new SalonCasa();
        salonCasa.setNumeroDeTelevisores(objetoSalon.getNumeroDeTelevisores);
        salonCasa.setTipoSalon(objetoSalon.getTipoSalon);
    }

que tú aplicas mal en tu clase Casa.

Dan, si es posible, me gustaría que te plantearas explicarle a un colega imaginario que es lo que hace tu método setSalonCasa(SalonCasa objetoSalon) y que es lo que hace el mismo método de la cita anterior.

Después quiero que te digas a ti mismo que hace este método set en la clase Main que no recibe parámetros
    casita.setSalonCasa();

Cuando tengas respuestas a estas preguntas, volvemos a contactar.
Y si tienes dudas, plantéalas aquí y lo solucionamos. No codifiques por codificar sin entender lo que haces.

Saludos

Hola Lorenzo

Respuestas correctas.

La documentación sobre el API de Java es una biblioteca gigantesca. Tiene todo lo que puesdas imaginar y más.

Gracias a ella podemos aprovechar el código eficiente de los desarrolladores de Java para nuestros proyectos.

Saludos

Hola calderas

Respuestas correctas. OK

Saludos

Hola Lorenzo

Las excepciones se suelen usar para controlar mediante código alternativo situaciones que el compilador no puede resolver por sí solo.
Un ejemplo típico es, la división por cero.

Tú siempre puedes usar los recursos de que dispones a tu buen entender. En este caso capturar la excepción particular que se da en tu código. Intentas leer un String más allá de su tamaño.

También puedes codificar sabiendo que ese 'error' ocurrirá con certeza.
Cosa que has hecho en el segundo ejercicio.

También has de saber que se codifica creando excepciones personalizadas. Por ejemplo una excepción que salte cuando un int esté fuera de un rango dado

Por lo tanto las excepciones trabajan para nosotros, no al revés.

Saludos

Hola Alex

Gacias por tus comentarios. He de decirte que tu escrito no tiene derperdicio para mí.

Tengo claro que dos objetos idénticos cambian al modificar cualquiera de ellos. Para mí son dos puntos de vista (los dos objetos) de un paquete de información único.

Se que la nombrada 'referencia' que da el método toString() no sobreescrito, es una referencia que no podemos controlar, que cambia en cada ejecución.
Para mí es solo una forma visual de comprobar la identidad entre objetos.
Se me hacía más lioso crear una tabla con las relaciones de identidad de cada objeto con el resto de ellos.

Tu clase Test es clarificadora y ejemplarizante. También veo coherencia en la salida mostrada.

RESPUESTA:

A veces se piensa erróneamente que los tipos primitivos pasan por valor y los objetos por referencia, pero esto no es así. Todo parámetro pasa por valor.

La confusión radica en que cuando pasamos un tipo primitivo, este no es modificable dentro del método. En cambio, al pasar un objeto, sí se pueden producir modificaciones dentro del método. Pero la realidad es que cuando pasamos el parámetro no pasamos el objeto en sí, sino una referencia al objeto, y esta referencia es la que pasa por valor y funciona como una copia dentro del método, resultando que los cambios dentro del método no son conocidos luego fuera de él.

La cita anterior, es maná para mí. Desaloja casi todas las dudas que me planteaba pasar objetos como parámetros.

Y finalmente

Esto también parece coherente: el método usa como parámetro una copia local de la referencia. Las modificaciones a la referencia no permanecen porque la copia se destruye posteriormente. En cambio, si usamos la referencia para manipular el objeto, dichos cambios sí permanecen porque a través de la copia hemos accedido a modificar el objeto en sí.

En esta cita muestras la diferencia entre 'hacer modificaciones a la referencia' que ha llegado como copia del original, en el método  probarAsignar(Agente agX), y  'usar la propia referencia para modificar el objeto' en el método probarModificar(Agente agX). Cambios estos últimos que si trascienden, aunque esta referencia desaparezca al terminar el método.

He de decirte que no me había planteado (por ignorarlo) usar el parámetro recibido para modificar el objeto original.
Yo simplemente partía de la premisa de que un método set modifica su atributo y  nada más.


Mis conclusiones después de tus aportaciones son:

Los objetos idénticos manipulan el mismo objeto. Cualquier cambio en uno afeca al resto de idénticos.

Los cambios hechos en el parámetro que recibe un método son responsabilidad del programador. Es decir si usa el parámetro para otra cosa que no sea transmitir los datos a los que apunta, allá el programador con sus consecuencias.

Los cambios hechos a un objeto después de haberlo enviado como parámetro a un método. No afectan a los cambios que realizó la copia del objeto dentro del método.
Esta última observación, es la que me planteaba dudas. Y aquí se han desvanecido.

Ejem. Líneas de código sueltas sobre la cuestión:

    personaOriginal.setNombre("Victor");
    objetoPadre.setPersona(personaOriginal);
    ...
    public void setPersona(Persona persona1) {
        persona = persona1;
    }
    ...
    personaOriginal.getNombre() -> devuelve -> "Victor"
    objetoPadre.getPersona.getNombre() -> devuelve -> "Victor"
    ...
    personaOriginal.setNombre("Zenon");
    ...
    personaOriginal.getNombre() -> devuelve -> "Zenon"
    objetoPadre.getPersona.getNombre() -> devuelve -> "Victor"


Creo que no he dicho nada erróneo. Si he hecho suposiciones incorrectas apreciaré que me rectifiques.

Saludos y gracias.

Hola Dan

Tus comentarios son adecuados.

Y tal como dices los atributos que no se usan se podrían eliminar por inútiles.

Saludos

Hola Dan

Ejercicio correcto.

Esto cada vez es más fácil

Saludos

Hola Dan

La corrección de tu clase Casa está bien.
Aunque los métodos set de los atributos salonCasa y cocina en lugar de recibir objetos, reciben una cadena de texto y un número

Tu solución es válida, pero como te comentaba Alex, hemos de trabajar con objetos. Java manipula objetos.

En el enlace que te indicaba Alex está esta forma de codificar el método set

Forma 2 (trabajando con objetos):

Recibir un objeto y crear un nuevo objeto cuyos atributos sean iguales a los del objeto recibido:

    public void setSalonCasa (SalonCasa objetoSalon) {
        salonCasa = new SalonCasa();
   salonCasa.setNumeroDeTelevisores(objetoSalon.getNumeroDeTelevisores);
   salonCasa.setTipoSalon(objetoSalon.getTipoSalon);
    }

Respecto a la respuesta de System.out.println de los métodos get de objetos como Cocina o SalonCasa, es la misma que te dará si pides el contenido de los objetos mismos, pues getSalonCada() devuelve un objeto de tipo SalonCasa.

Cuando pides el valor de un primitivo, para Java es una cosa muy sencilla pues la dirección de esa variable contiene el dato que quieres saber.
En cambio la dirección de un objeto da a un paquete que hay que descifrar y en lugar del objeto te muestra su dirección, ese galimatías con un @ en medio.

Más adelante veremos como codificar para que Java nos muestre eso que tú esperabas ver.

Saludos

Hola Lorenzo

Ejercicio correcto.

Saludos

Hola Lorenzo

Ejercicio correcto.

Está bien que tus programas controlen lo que introduce el usuario.
Aunque parezca mentira, los programas bien hechos incorporan mucho código para chequear las acciones de quien utiliza el programa.

Apunte para mejorar el código:
La línea:
   if(texto.substring(0,1).equals("a") || texto.substring(0,1).equals("A"))
se puede simplificar utilizando el método equalsIgnoreCase(String) que da la misma respuesta para mayúsculas que para minúsculas. Ejem.
    if(texto.substring(0,1).equalsIgnoreCase("a"))

Saludos