Antwoord.

Achtergrond:

Toegangscontrole tot data en methoden in Java is geïntroduceerd om encapsulatie te waarborgen en de interne werking van klassen te beschermen. Dit is een belangrijk aspect van OOP, dat het mogelijk maakt om de implementatie te verbergen en ongeoorloofde wijzigingen van de status van objecten te voorkomen.

Probleem:

Verschillende toegangsmodifiers — public, protected, (package-private), private — beperken op verschillende manieren de zichtbaarheid van de leden van een klasse, wat vaak niet vanzelfsprekend is. Een verkeerd gekozen niveau kan leiden tot bugs, ongewenste uitbreiding van rechten, en schending van encapsulatie.

Oplossing:

Gebruik de minimaal noodzakelijke toegangsmodifier voor elk veld of elke methode. Java ondersteunt:

private — alleen toegankelijk binnen dezelfde klasse
(package-private) — als de modifier niet is opgegeven, alleen toegankelijk binnen het pakket
protected — binnen het pakket en in subklassen (ook als ze buiten het pakket zijn)
public — overal toegankelijk

Voorbeeldcode:

public class Dog {
    private String name; // alleen zichtbaar binnen Dog
    String breed;        // package-private
    protected int age;   // zichtbaar in het pakket en in afgeleiden klassen
    public void bark() { // toegankelijk vanuit elke code
        System.out.println("Woef!");
    }
}

Belangrijke kenmerken:

Standaard is package-private gekozen
protected is anders in Java dan in C++ (in Java zichtbaarheid is in het pakket!)
private biedt geen bescherming tegen toegang via reflectie, maar je moet hier niet op vertrouwen

Valstrikvragen.

Kan een interne (inner) klasse toegang krijgen tot alle private velden van de externe klasse?

Ja, een interne klasse heeft volledige toegang tot alle velden en methoden van de externe klasse, zelfs private. En omgekeerd, de externe klasse kan toegang krijgen tot de private leden van de interne klasse, mits het een instantie ervan heeft.

Kan een protected-lid van een klasse bereikbaar zijn buiten het pakket zonder overerving?

Nee. Buiten het pakket is protected alleen handig voor afgeleiden klassen. Gewoonlijk, via een object van de klasse in een ander pakket — dat kan niet.

Wat gebeurt er als een klasse niet als public is gedeclareerd, maar geïmporteerd wordt uit een ander pakket?

Een klasse met package-private niveau kan niet expliciet buiten zijn pakket worden geïmporteerd en gebruikt. Pogingen om er vanuit de code van een ander pakket naar te verwijzen, zullen een compilatiefout veroorzaken.

Veelvoorkomende fouten en antipatterns

Klassenvelden als public openen, wat de encapsulatie schendt
Vertrouwen op protected als een "veilige" toegangsmodificator, zonder rekening te houden met zichtbaarheid binnen het pakket
Gebruik van package-private, niet begrijpen dat het zichtbaar is voor alle klassen in het pakket

Voorbeeld uit het leven

Negatieve case

Alle velden van de klasse voor DTO zijn als public gemarkeerd om de toegang te vereenvoudigen

Voordelen:

Snel, geen noodzaak om getters/setters te schrijven

Nadelen:

Schending van encapsulatie, onverwachte wijziging van gegevens is mogelijk
Moeilijker om de status van objecten te controleren

Positieve case

Gebruik van private velden en publieke toegangsmethoden