Odpowiedź.

Historia pytania:

Kontrola poziomu dostępu do danych i metod w Javie została wprowadzona w celu zapewnienia enkapsulacji i ochrony wewnętrznej struktury klas. Jest to ważny element OOP, który umożliwia ukrycie implementacji i zapobieganie nieautoryzowanej zmianie stanu obiektów.

Problem:

Różne modyfikatory dostępu — public, protected, (package-private), private — różnie ograniczają zakres widoczności członków klasy, co często nie jest oczywiste. Nieprawidłowo wybrany poziom może prowadzić do błędów, niepożądanego rozszerzenia praw, naruszenia enkapsulacji.

Rozwiązanie:

Użyj minimalnie potrzebnego modyfikatora dostępu dla każdego pola lub metody. Java wspiera:

private — dostępny tylko wewnątrz tej samej klasy
(package-private) — jeśli modyfikator nie jest podany, dostępny tylko wewnątrz pakietu
protected — wewnątrz pakietu i w podklasach (nawet jeśli są poza pakietem)
public — dostępny wszędzie

Przykład kodu:

public class Dog {
    private String name; // widoczne tylko wewnątrz Dog
    String breed;        // package-private
    protected int age;   // widoczne w pakiecie i w dziedziczy
    public void bark() { // dostępne z dowolnego kodu
        System.out.println("Woof!");
    }
}

Kluczowe cechy:

Zawsze domyślnie wybrano package-private
protected różni się w Javie od C++ (w Javie widoczność w pakiecie!)
private nie chroni przed dostępem przez refleksję, ale nie warto na tym polegać

Pytania z pułapką.

Czy zagnieżdżona (inner) klasa ma dostęp do wszystkich prywatnych pól zewnętrznej klasy?

Tak, zagnieżdżona klasa ma pełny dostęp do wszystkich pól i metod zewnętrznej, nawet prywatnych. I odwrotnie, zewnętrzna może uzyskać dostęp do prywatnych członów zagnieżdżonej klasy, jeśli posiada jej instancję.

Czy członek klasy protected może być dostępny poza pakietem bez dziedziczenia?

Nie. Poza pakietem protected jest wygodny tylko dla dziedziczących. Po prostu tak, przez obiekt klasy w innym pakiecie — nie można.

Co się stanie, jeśli klasa nie jest zadeklarowana jako public, ale jest importowana z innego pakietu?

Klasa z poziomem package-private nie może być importowana i używana jawnie poza swoim pakietem. Próba dostępu do niej z kodu innego pakietu spowoduje błąd kompilacji.

Typowe błędy i antywzorce

Otwieranie pól klasy jako public, naruszając enkapsulację
Poleganie na protected jako na "bezpiecznym" poziomie dostępu, nie biorąc pod uwagę widoczności w pakiecie
Używanie package-private, nie rozumiejąc, że jest widoczne dla wszystkich klas w pakiecie

Przykład z życia

Negatywny przypadek

Wszystkie pola klasy dla DTO oznaczone jako public dla uproszczenia dostępu

Zalety:

Szybko, nie ma potrzeby pisania getterów/setterów

Wady:

Naruszenie enkapsulacji, możliwa nieoczekiwana modyfikacja danych
Trudniej kontrolować stan obiektów

Pozytywny przypadek

Używane są prywatne pola i publiczne metody dostępu