Encapsulación: getters, setters y modificadores de acceso

El problema: un objeto que nadie protege

En Clases y objetos la primera versión de Alumno dejaba sus atributos sin ningún modificador:

public class Alumno {
    String nombre;
    double nota;
}

Con eso, cualquier línea de cualquier parte del programa puede escribir:

Alumno a = new Alumno();
a.nota = -50;
a.nota = 12345;
a.nombre = null;

Nada de eso tiene sentido para un alumno real, y la clase Alumno no puede hacer absolutamente nada al respecto. El objeto queda en un estado inválido y el error se descubre mucho después, en otro archivo, cuando alguien intenta calcular un promedio y le sale un número absurdo.

La encapsulación resuelve esto invirtiendo quién manda: en vez de que el resto del programa escriba directamente en los atributos, la clase expone un conjunto controlado de métodos y se guarda para sí la única llave que toca los datos.

Los cuatro modificadores de acceso

Java tiene cuatro niveles de visibilidad. Se escriben delante del atributo o del método:

La regla práctica cabe en una línea: atributos private, métodos que quieres que se usen desde afuera public.

public class Alumno {
    private String nombre;
    private double nota;
}

A partir de ese private, la línea a.nota = -50; escrita desde main ya no compila. El compilador dice algo como nota has private access in Alumno — y eso es una victoria, no un obstáculo: el error apareció al compilar, en la línea exacta que lo causa, en vez de convertirse en un número raro tres pantallas más adelante.

Getters: leer sin poder escribir

Un getter es un método public que devuelve el valor de un atributo private. La convención de nombres en Java es get + el nombre del atributo en CamelCase:

public class Alumno {
    private String nombre;
    private double nota;

    public String getNombre() {
        return nombre;
    }

    public double getNota() {
        return nota;
    }
}

Cada getter no recibe parámetros (() vacío), devuelve el tipo del atributo, y su cuerpo es un único return. Desde afuera se usa así:

Alumno a = new Alumno("Ana", 8.5);
System.out.println(a.getNombre() + " sacó " + a.getNota());

Setters: escribir bajo condiciones

Un setter es el camino de vuelta: un método public que recibe un valor nuevo y lo asigna al atributo, pero solo si pasa las validaciones que la clase decida. La convención es set + el nombre, no devuelve nada (void) y recibe exactamente un parámetro del tipo del atributo:

public void setNota(double nuevaNota) {
    if (nuevaNota < 0 || nuevaNota > 10) {
        System.out.println("Nota inválida: " + nuevaNota);
        return;
    }
    this.nota = nuevaNota;
}

Aquí está la diferencia real con un atributo público: a.nota = -50 no tenía forma de fallar; a.setNota(-50) tiene un lugar donde poner el if. Ese if es toda la razón de existir del setter.

La clase completa

public class Alumno {
    private String nombre;
    private double nota;

    public Alumno(String nombre, double nota) {
        this.nombre = nombre;
        setNota(nota);
    }

    public String getNombre() {
        return nombre;
    }

    public double getNota() {
        return nota;
    }

    public void setNota(double nuevaNota) {
        if (nuevaNota >= 0 && nuevaNota <= 10) {
            this.nota = nuevaNota;
        }
    }

    public boolean isAprobado() {
        return nota >= 6;
    }
}

Fíjate en dos detalles que suelen pasarse por alto:

1. El constructor llama a setNota(nota) en vez de asignar directo. Si la validación vive en el setter, dejar que el constructor la esquive abre justamente el agujero que estabas tapando: new Alumno("Ana", -50) volvería a crear un objeto inválido.
2. isAprobado() no tiene ningún atributo detrás. No todo método public es el getter de algo: este calcula un dato a partir del estado interno. Guardar un atributo aprobado además de nota sería peor, porque habría que acordarse de mantenerlo sincronizado cada vez que la nota cambie.

No todo atributo necesita los dos

Escribir mecánicamente un getter y un setter para cada atributo es el error más común al aprender encapsulación. La pregunta correcta es “¿qué necesita el resto del programa hacer con este dato?”:

Pon a prueba

public class Cuenta {
    private String titular;
    private double saldo;

    public Cuenta(String titular, double saldo) {
        this.titular = titular;
        this.saldo = saldo;
    }

    public String getTitular() {
        return titular;
    }

    public double getSaldo() {
        return saldo;
    }

    public void setSaldo(double nuevoSaldo) {
        if (nuevoSaldo >= 0) {
            this.saldo = nuevoSaldo;
        }
    }
}

public class Producto {
   double precio;

  public double () {
      return precio;
  }

  public  setPrecio(double precio) {
      if (precio >= 0) {
          .precio = precio;
      }
  }
}

Alumno a = new Alumno("Ana", -3);
System.out.println(a.getNota());
System.out.println(a.isAprobado());
a.setNota(7.5);
System.out.println(a.isAprobado());

Siguiente paso

Ya sabes construir una clase que protege sus propios datos. El paso siguiente es que una clase pueda partir de otra en vez de escribirse desde cero, reutilizando sus atributos y métodos y cambiando solo lo que la diferencia — ver Herencia y @Override.