Respuesta.

En Java, para gestionar el acceso a campos, métodos y clases se utilizan modificadores de acceso: private, default (package-private), protected, public.

Historia de la cuestión:

Las versiones tempranas de Java utilizaban una estricta encapsulación de objetos. Para mayor flexibilidad, se introdujeron diferentes niveles de acceso para soportar tanto el cierre total como la extensibilidad (herencia y acceso dentro del paquete).

Problema:

La elección incorrecta del modificador puede llevar a violaciones de la encapsulación, problemas con la herencia, imposibilidad de testear o incluso a errores de seguridad, si los datos se vuelven públicos por error.

Solución:

Utiliza el modificador más restringido que permita tu arquitectura. Los campos suelen ser private, accesibles a través de getter/setter. Los métodos se hacen public solo si son parte de la API, y para la extensión — protected.

Ejemplo de código:

public class Person {
    private String name; // campo privado
    protected int age; // accesible en el paquete y en los descendientes
    String email; // package-private
    public String getName() { return name; }
}

Características clave:

private — accesible solo dentro de la clase
package-private (sin modificador) — accesible desde todas las clases en un mismo paquete
protected — además, accesible para los descendientes incluso de otros paquetes
public — accesible para todos

Preguntas capciosas.

¿Se puede aplicar un modificador de acceso a variables locales?

No. Los modificadores de acceso se aplican solo a clases, métodos y campos/clases internas, pero no a variables locales.

¿Se puede hacer una clase dentro de un método con el modificador public?

No. Una clase local no puede ser declarada con un modificador de acceso, siempre tiene un ámbito dentro del método.

¿Está disponible un miembro protected para una clase hija en otro paquete?

Sí, los miembros protected son accesibles para los descendientes, incluso si están en otros paquetes, pero no para clases normales en otro paquete.

Errores típicos y anti-patrones

Uso de campos public (violación de la encapsulación)
package-private "accidental" (modificador olvidado)
Exposición excesiva de métodos protected sin necesidad
Abuso de campos public static para transmitir información entre partes de la aplicación

Ejemplo de la vida real

Caso negativo

Todos los campos de la clase se declaran accidentalmente como public — se accede a ellos directamente desde otras clases, es difícil rastrear el lugar de los cambios.

Ventajas:

Rápido y fácil acceder a los datos

Desventajas:

Complejidad en el control de acceso. No hay lógica de comprobación/validación
Fácil de dañar los datos

Caso positivo

Todos los campos son privados, y los métodos públicos controlan el acceso con validación, solo las partes necesarias se hacen protected para la extensión en descendientes.