Respuesta.

Historia de la cuestión:

El control del nivel de acceso a los datos y métodos en Java se introdujo para garantizar la encapsulación y proteger la estructura interna de las clases. Esta es una parte importante de la POO, que permite ocultar la implementación y prevenir la modificación no autorizada del estado de los objetos.

Problema:

Diferentes modificadores de acceso — public, protected, (package-private), private — limitan de manera diferente el ámbito de visibilidad de los miembros de la clase, lo que a menudo no es obvio. Un nivel seleccionado incorrectamente puede conducir a errores, una expansión no deseada de derechos y a violaciones de la encapsulación.

Solución:

Utilizar el modificador de acceso mínimo necesario para cada campo o método. Java soporta:

private — solo accesible dentro de la misma clase
(package-private) — si no se especifica el modificador, accesible solo dentro del paquete
protected — dentro del paquete y en subclases (incluso si están fuera del paquete)
public — accesible en cualquier lugar

Ejemplo de código:

public class Dog {
    private String name; // visible solo dentro de Dog
    String breed;        // package-private
    protected int age;   // visible en el paquete y en herederos
    public void bark() { // accesible desde cualquier código
        System.out.println("¡Guau!");
    }
}

Características clave:

Siempre por defecto es package-private
protected se comporta de manera diferente en Java que en C++ (¡en Java la visibilidad está en el paquete!)
private no protege contra el acceso a través de reflexión, pero no se debe contar con ello

Preguntas engañosas.

¿Puede una clase interna (inner) acceder a todos los campos private de la clase externa?

Sí, la clase interna tiene acceso total a todos los campos y métodos de la externa, incluso private. Y viceversa, la externa puede acceder a los miembros private de la clase interna si tiene su instancia.

¿Puede un miembro protected de la clase ser accesible fuera del paquete sin herencia?

No. Fuera del paquete, protected es conveniente solo para herederos. Simplemente a través de un objeto de la clase en otro paquete — no se puede.

¿Qué sucederá si la clase no se declara como public, pero se importa desde otro paquete?

Una clase con nivel package-private no puede ser importada y utilizada explícitamente fuera de su paquete. Intentar acceder a ella desde el código de otro paquete generará un error de compilación.

Errores comunes y anti-patrones

Hacer públicos los campos de la clase, violando la encapsulación
Confiar en protected como un nivel de acceso "seguro", sin considerar la visibilidad dentro del paquete
Uso de package-private, sin entender que es visible para todas las clases en el paquete

Ejemplo de la vida real

Caso negativo

Se marcan todos los campos de la clase para DTO como public para simplificar el acceso

Pros:

Rápido, no es necesario escribir getters/setters

Contras:

Violación de la encapsulación, posible modificación inesperada de los datos
Más difícil controlar el estado de los objetos

Caso positivo

Se utilizan campos private y métodos de acceso públicos