← Volver a actividades

Autoevaluación

Autoevaluación: Constructores y Encapsulamiento

Constructores, Modificadores de Acceso y Getters/Setters · 15 min aprox.

Respondé todas las preguntas y presioná Calificar para ver tu puntaje.

1. ¿Cuáles son las dos reglas sintácticas que identifican a un constructor en Java?

Se llama exactamente igual que la clase y no declara ningún tipo de retorno. Se llama constructor y devuelve void. Es static y se llama igual que la clase. Es public y no recibe ningún parámetro.

Correcto Incorrecto Sin responder

Respuesta correcta: Se llama exactamente igual que la clase y no declara ningún tipo de retorno.

¿Por qué? Un constructor se reconoce por dos reglas: se llama exactamente igual que la clase, mayúsculas incluidas, y no declara tipo de retorno, ni siquiera void. Ninguna de las dos tiene que ver con static ni con la cantidad de parámetros.

2. Si se escribe public void Producto(...) con un tipo de retorno explícito, Java lo trata igual que a un constructor.

Verdadero Falso

Correcto Incorrecto Sin responder

Respuesta correcta: Falso

¿Por qué? Al declarar un tipo de retorno, Java lo compila como un método común llamado igual que la clase, no como un constructor. El objeto nunca se inicializa con ese código y no hay ningún aviso del compilador: es uno de los errores más silenciosos de la lección.

3. De las cinco etapas que ejecuta la JVM al evaluar new, ¿en qué momento corre el cuerpo del constructor?

Es la primera etapa, antes de reservar memoria en el Heap. Es la cuarta etapa: corre después de reservar memoria, asignar valores por defecto y ejecutar los inicializadores de instancia. Es la última etapa, después de que la referencia ya fue devuelta a la variable. No es una etapa fija: el compilador decide el orden según el código.

Correcto Incorrecto Sin responder

Respuesta correcta: Es la cuarta etapa: corre después de reservar memoria, asignar valores por defecto y ejecutar los inicializadores de instancia.

¿Por qué? El operador new reserva memoria, asigna valores por defecto y corre los inicializadores de instancia antes de llegar al cuerpo del constructor, que es la cuarta etapa. Recién en la quinta se devuelve la referencia. El objeto ya existe en memoria cuando tu código del constructor empieza a correr.

4. Si una clase no declara ningún constructor propio, igual se puede escribir new NombreClase(), porque el compilador agrega automáticamente un constructor vacío sin parámetros.

Verdadero Falso

Correcto Incorrecto Sin responder

Respuesta correcta: Verdadero

¿Por qué? Cuando no escribís ningún constructor, el compilador te regala uno público, vacío y sin parámetros. Ese regalo desaparece apenas declarás vos mismo un solo constructor.

5. Una clase Persona declara únicamente public Persona(String nombre) { ... }. ¿Qué ocurre al intentar new Persona()?

Compila y crea un objeto con nombre en null. Error de compilación: el constructor sin argumentos ya no existe. Se ejecuta el constructor heredado de Object, sin inicializar nombre. Compila, pero lanza una excepción en tiempo de ejecución.

Correcto Incorrecto Sin responder

Respuesta correcta: Error de compilación: el constructor sin argumentos ya no existe.

¿Por qué? Apenas la clase declara un constructor propio, el constructor sin parámetros que regalaba el compilador desaparece. Si Persona solo tiene Persona(String nombre), new Persona() es un error de compilación, no un problema en tiempo de ejecución.

6. La llamada this(...) puede ir después de validar algunos parámetros dentro del constructor, siempre que se ejecute antes de asignar los atributos.

Verdadero Falso

Correcto Incorrecto Sin responder

Respuesta correcta: Falso

¿Por qué? this(...) tiene que ser la primera sentencia del constructor, sin excepción: no puede haber nada antes, ni siquiera una validación o un System.out.println.

7. ¿Qué ocurre al intentar compilar esta clase?

public class Ejemplo {
    public Ejemplo() {
        this(0);
    }

    public Ejemplo(int valor) {
        this();
    }
}

Compila, y al instanciarla se produce un desbordamiento de pila (StackOverflowError) en tiempo de ejecución. Error de compilación: Java detecta el ciclo entre Ejemplo() y Ejemplo(int). Compila sin problema: se ejecuta primero Ejemplo() y después Ejemplo(int). Compila, pero solo puede invocarse Ejemplo(int) directamente; Ejemplo() queda inutilizable.

Correcto Incorrecto Sin responder

Respuesta correcta: Error de compilación: Java detecta el ciclo entre Ejemplo() y Ejemplo(int).

¿Por qué? Ejemplo() delega en Ejemplo(int) con this(0), y Ejemplo(int) delega de vuelta en Ejemplo() con this(). Java detecta ese ciclo entre constructores en tiempo de compilación: es un error de compilación, nunca un desbordamiento en tiempo de ejecución.

8. Encapsular una clase significa declarar todos sus atributos private y generar un getter y un setter para cada uno con el IDE.

Verdadero Falso

Correcto Incorrecto Sin responder

Respuesta correcta: Falso

¿Por qué? Eso es ritual, no diseño. Encapsular significa que el objeto es dueño de su propio estado y el único responsable de mantenerlo consistente. Generar accesores para todos los campos por reflejo deja el estado tan expuesto como si fuera público, solo que con más ceremonia.

9. ¿Cuándo vale la pena que un getter o un setter exista, según el criterio de la lección?

Siempre: todo atributo private necesita su getter y su setter para poder usarse. Solo cuando hacen algo más que leer o escribir el atributo tal cual: validar, transformar o calcular. Nunca: los getters y setters son un antipatrón en cualquier clase Java. Solo cuando el atributo es final.

Correcto Incorrecto Sin responder

Respuesta correcta: Solo cuando hacen algo más que leer o escribir el atributo tal cual: validar, transformar o calcular.

¿Por qué? Un getter o setter que solo lee o escribe el atributo tal cual es, en la práctica, un campo público con más ceremonia. Los accesores valen la pena cuando hacen algo real: validan, transforman, calculan, o directamente no existen y se reemplazan por un método de dominio.

10. ¿Por qué este código rompe el encapsulamiento de Curso, a pesar de que alumnos es private?

public class Curso {
    private String[] alumnos = new String[30];

    public String[] getAlumnos() {
        return alumnos;
    }
}

Curso c = new Curso();
c.getAlumnos()[0] = "Intruso";
java.util.Arrays.fill(c.getAlumnos(), null);

getAlumnos() debería ser private también. El getter devuelve la referencia interna al array; quien la recibe puede modificarlo directamente desde afuera. El problema es que alumnos debería declararse final para no poder reasignarse. El código no compila, así que la pregunta no aplica.

Correcto Incorrecto Sin responder

Respuesta correcta: El getter devuelve la referencia interna al array; quien la recibe puede modificarlo directamente desde afuera.

¿Por qué? El atributo es private, pero el getter entrega la dirección de memoria del array interno, no una copia. Lo que protege el private es el campo, no el objeto al que apunta: quien recibe esa referencia puede sobrescribir elementos como si el array fuera suyo (y final no lo evitaría: solo impide reasignar la referencia, no modificar su contenido). La solución es devolver una copia defensiva (con un for o Arrays.copyOf) o directamente no exponer el array y ofrecer solo las operaciones que tienen sentido (como inscribir(alumno)).