Kapselung OOP Grundlagen – Sichtbarkeit, Information Hiding, private, protected, public
Dieser Beitrag ist eine Begriffserklärung zur Kapselung in der OOP – inklusive Prüfungsfragen und Tags.
In a Nutshell
Kapselung verbirgt interne Zustände und Implementierungsdetails eines Objekts, nur wohldefinierte Schnittstellen sind nach außen sichtbar. Ziel ist robuste, wartbare und sichere Software durch klare Zuständigkeitsgrenzen.
Kompakte Fachbeschreibung
Kapselung ist ein zentrales OOP Prinzip, das Daten und Verhalten zu einer Einheit bündelt und den direkten Zugriff auf interne Repräsentationen einschränkt. Technisch wird sie über Sichtbarkeitsmodifizierer wie private, protected, public, package sichtbar, sowie über Zugriffsmethoden und Properties umgesetzt. Information Hiding reduziert Kopplung, erhöht Kohäsion und erlaubt die Änderung der Implementierung ohne Auswirkungen auf Konsumenten. Invarianten werden innerhalb des Objekts gewahrt, Ein- und Ausgaben werden validiert. Mutabilität wird bewusst gesteuert, unveränderliche Objekte eliminieren ganze Klassen von Fehlern.
Prüfungsrelevante Stichpunkte
- Information Hiding schützt interne Repräsentation, reduziert Kopplung
- Sichtbarkeitsmodifizierer private, protected, public, package steuern Zugriff
- Getter und Setter sind kein Selbstzweck, nur bereitstellen wenn fachlich nötig
- IHK relevant, Begriffe Kapselung, Abstraktion, Kohäsion, Kopplung sauber voneinander abgrenzen
- Unveränderliche Objekte erhöhen Thread Sicherheit und Testbarkeit in der Praxis
- Validierung, Invarianten und das Law of Demeter verhindern unsichere Zustandsmanipulation
- Wirtschaftlichkeit durch geringere Wartungskosten und leichteres Refactoring
- Dokumentationspflicht, öffentliche Schnittstellen, Vorbedingungen, Nachbedingungen
Kernkomponenten
- Sprachelemente für Sichtbarkeit, private, protected, public, package
- Eigenschaften und Methoden, gezielte Exposition statt vollständiger Offenlegung
- Invarianten, fachliche Regeln die stets gelten müssen
- Verträge, Vorbedingungen und Nachbedingungen an der öffentlichen API
- Mutabilitätskonzept, veränderlich, unveränderlich, Copy on Write
- Zugriffskontrolle und Validierung, Eingaben prüfen, Zustandsänderungen atomar
- Prozess Schritt, Refactoring zum Verbergen von Datenfeldern und internen Collections
- Architektur Element, Modulgrenzen, Package Boundaries, Bounded Contexts
- Sicherheits Aspekt, Minimierung der Angriffsfläche und von Injection Punkten
- Test Verfahren, Black Box Tests der API und Property Based Tests für Invarianten
Praxisbeispiel
// Beispiel, Java ähnliche Syntax
class BankAccount {
private String iban
private int balanceInCents
public BankAccount(String iban) {
if (iban == null) throw new IllegalArgumentException("IBAN erforderlich")
this.iban = iban
this.balanceInCents = 0
}
public int balance() {
return balanceInCents
}
public void deposit(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positiver Betrag")
balanceInCents += cents
}
public void withdraw(int cents) {
if (cents <= 0) throw new IllegalArgumentException("positiver Betrag")
if (cents > balanceInCents) throw new IllegalStateException("Überziehung nicht erlaubt")
balanceInCents -= cents
}
}
Erklärung: Felder sind privat, nur fachlich sinnvolle Operationen sind öffentlich, Invarianten werden geprüft.
Vorteile und Nachteile
Vorteile
- Geringere Kopplung, höhere Kohäsion
- Bessere Wartbarkeit, leichtere Parallelisierung
- Klare Verantwortlichkeiten, verbesserte Sicherheit durch Eingabekontrollen
Nachteile
- Möglicher Mehraufwand durch Boilerplate
- Zu starke Abschottung kann Testbarkeit erschweren
- Falsche Getter Setter inflation können Kapselung unterlaufen
Typische Prüfungsfragen (mit Kurzantwort)
-
Unterschied Kapselung vs. Abstraktion? Kapselung verbirgt Implementierungsdetails hinter einer Schnittstelle, Abstraktion reduziert die sichtbare Komplexität auf relevante Eigenschaften.
-
Sichtbarkeitsstufen und Nutzung? private nur innerhalb der Klasse, package nur innerhalb des Pakets, protected Klasse und Unterklassen, public global sichtbar.
-
Öffentliche Felder problematisch? Sie umgehen Validierung, verletzen Invarianten, erhöhen Kopplung und machen Refactoring riskant.
-
Getter und Setter sinnvoll? Wenn fachliche Notwendigkeit besteht, etwa lesender Zugriff oder kontrollierte Änderung mit Validierung, sonst vermeiden.
-
Immutabilität unterstützt Kapselung? Unveränderliche Objekte garantieren stabile Invarianten, vereinfachen nebenläufige Nutzung und verhindern Seiteneffekte.
-
Law of Demeter und wie hilft? Sprich nur mit deinen direkten Freunden, keine Kettenzugriffe, reduziert Wissen über interne Strukturen, stärkt Kapselung.
-
Auswirkung auf Teststrategien? Fokus auf Black Box Tests der öffentlichen API, interne Details werden über beobachtbares Verhalten geprüft.
-
Kapselung über Collections brechen? Rückgabe einer internen List ermöglicht externe Mutation, Lösung, defensive Kopie oder Unmodifiable View.