kapselung

Encapsulation (Kapselung)

Kurz: Das Prinzip, die internen Daten eines Objekts vor direktem Zugriff von außen zu schützen und stattdessen nur über definierte Methoden (Getter/Setter) zugänglich zu machen.

Genauer: Statt ein Feld direkt öffentlich zu machen, wird es privat gehalten (siehe Zugriffsmodifizierer) und der Zugriff über kontrollierte Methoden geregelt — so lässt sich z. B. verhindern, dass ein Alter-Feld auf einen negativen Wert gesetzt wird, weil der Setter das vorher prüfen kann. Kapselung ist eines der vier Grundprinzipien der OOP und macht Code robuster gegen fehlerhafte Nutzung von außen.

Im Detail

Der Kerngedanke: Ein Objekt soll für seinen eigenen internen Zustand verantwortlich sein und garantieren können, dass dieser Zustand immer gültig bleibt — das geht nur, wenn Außenstehende diesen Zustand nicht einfach an der Kontrolllogik vorbei direkt verändern können.

class Konto {
    private saldo: Zahl
 
    einzahlen(betrag) {
        wenn betrag <= 0:
            fehler("Betrag muss positiv sein")
        saldo = saldo + betrag
    }
 
    abheben(betrag) {
        wenn betrag > saldo:
            fehler("Nicht genug Guthaben")
        saldo = saldo - betrag
    }
}

Wäre saldo stattdessen ein öffentliches Feld, könnte jeder Aufrufer es direkt auf einen beliebigen (auch ungültigen, z. B. negativen) Wert setzen, ohne dass die Konto-Klasse das verhindern oder auch nur bemerken könnte. Mit Kapselung ist einzahlen()/abheben() der EINZIGE Weg, den Saldo zu ändern — die Klasse hat die volle Kontrolle über ihre eigenen Invarianten (Regeln, die immer gelten müssen).

Ein oft übersehener Zusatznutzen: Kapselung erlaubt es, die interne Umsetzung später zu ändern, ohne den Code anzupassen, der die Klasse von außen nutzt — solange die öffentliche Schnittstelle (die Methodensignaturen) gleich bleibt. Man könnte saldo z. B. später intern in Cent statt in Euro speichern, ohne dass Aufrufer von einzahlen()/abheben() davon überhaupt etwas mitbekommen.

Ein häufiger Anfängerfehler, der Kapselung faktisch aushebelt: ein privates Feld zwar formal privat zu halten, aber einen Getter zurückzugeben, der eine VERÄNDERBARE Referenz auf ein internes Objekt (z. B. eine Liste) direkt herausgibt — der Aufrufer kann diese Liste dann trotzdem von außen verändern, obwohl sie technisch nie direkt zugewiesen wurde. Sauberer ist es, entweder eine Kopie zurückzugeben oder eine unveränderliche (“immutable”) Sicht auf die Daten.

Siehe auch: Modifiers, OOP, Objects