Antwort.

Geschichte der Frage:

Die Kontrolle des Zugriffslevels auf Daten und Methoden in Java wurde zur Sicherstellung der Kapselung und zum Schutz der inneren Struktur von Klassen eingeführt. Dies ist ein wichtiger Teil der OOP, der es ermöglicht, die Implementierung zu verbergen und eine unbefugte Modifikation des Zustands von Objekten zu verhindern.

Problem:

Verschiedene Zugriffsmodifikatoren — public, protected, (package-private), private — beschränken das Sichtbarkeitsfeld der Klassenmitglieder unterschiedlich, was oft nicht offensichtlich ist. Ein falsch gewähltes Niveau kann zu Fehlern, unerwünschter Erweiterung der Berechtigungen und Verletzung der Kapselung führen.

Lösung:

Verwenden Sie den minimal notwendigen Zugriffsmodifikator für jedes Feld oder jede Methode. Java unterstützt:

private — nur innerhalb derselben Klasse zugänglich
(package-private) — wenn der Modifikator nicht angegeben ist, nur innerhalb des Pakets zugänglich
protected — innerhalb des Pakets und in Unterklassen (auch wenn sie außerhalb des Pakets sind)
public — überall zugänglich

Beispielcode:

public class Dog {
    private String name; // nur innerhalb von Dog sichtbar
    String breed;        // package-private
    protected int age;   // sichtbar im Paket und in Erben
    public void bark() { // von jedem Code zugänglich
        System.out.println("Woof!");
    }
}

Schlüsselfunktionen:

Standardmäßig wird package-private gewählt
protected unterscheidet sich in Java von C++ (in Java Sichtbarkeit im Paket!)
private schützt nicht vor Zugriff über Reflexion, man sollte sich jedoch nicht darauf verlassen.

Fangfragen.

Kann eine innere Klasse auf alle privaten Felder der äußeren Klasse zugreifen?

Ja, der inneren Klasse sind alle Felder und Methoden der äußeren Klasse, sogar private, vollständig zugänglich. Umgekehrt kann die äußere Klasse auf private Mitglieder der inneren Klasse zugreifen, wenn sie deren Instanz hat.

Kann ein geschütztes Klassenmitglied außerhalb des Pakets ohne Vererbung zugänglich sein?

Nein. Protected ist außerhalb des Pakets nur für Nachfolger nützlich. Einfach so, über ein Objekt der Klasse in einem anderen Paket — das geht nicht.

Was passiert, wenn die Klasse nicht als public deklariert ist, aber aus einem anderen Paket importiert wird?

Eine Klasse mit package-private Level kann nicht importiert und außerhalb ihres Pakets explizit verwendet werden. Ein Versuch, von Code eines anderen Pakets darauf zuzugreifen, führt zu einem Kompilierungsfehler.

Typische Fehler und Antimuster

Klassenfelder als public öffnen und damit die Kapselung verletzen
Sich auf protected als auf ein "sicheres" Zugriffslevel verlassen, ohne die Sichtbarkeit innerhalb des Pakets zu berücksichtigen
Verwendung von package-private, ohne zu verstehen, dass es allen Klassen im Paket sichtbar ist.

Beispiel aus dem Leben

Negativer Fall

Alle Felder der Klasse für DTO sind public markiert, um den Zugriff zu erleichtern.

Vorteile:

Schnell, keine Notwendigkeit, Getter/Setter zu schreiben

Nachteile:

Verletzung der Kapselung, unerwartete Datenveränderung möglich
Schwieriger, den Zustand von Objekten zu kontrollieren.

Positiver Fall

Es werden private Felder und öffentliche Zugriffsmethoden verwendet.