Abstrakter Datentyp und Information Hiding

Ein abstrakter Datentyp (ADT) beschreibt zulässige Operationen und deren Verhalten, ohne eine konkrete Speicherorganisation festzulegen. Die sichtbare Schnittstelle bleibt stabil, die Implementierung darf gewechselt werden.

In Java modelliert man das oft als Interface plus Klasse. Aufrufer sehen nur Methodensignaturen und dokumentierte Verträge (Vorbedingungen, Nachbedingungen). Innere Felder bleiben privat.

Beispiel: Ein Stack-ADT verlangt push, pop und isEmpty. Ob die Elemente in einem Array oder in verketteten Knoten liegen, ist für den Aufrufer unerheblich, solange LIFO gilt.

Randfall: Verletzt eine Methode den Vertrag (pop auf leerem Stack), muss das spezifizierte Fehlerverhalten greifen, etwa eine Exception.

Schnittstellen wie List, Queue oder Map in der JDK und in Backend-APIs trennen Vertrag von Implementierung. Clients hängen am ADT; Teams können ArrayList durch eine andere List-Implementierung ersetzen, ohne Aufrufer umzuschreiben. Gleiches Muster in Microservices: öffentliche API stabil, interne Speicherung austauschbar.

Vertiefung

Ein abstrakter Datentyp wird durch seine beobachtbaren Operationen und deren Gesetze beschrieben. Ob seine Daten in einem Array, einer Liste oder einer Datei liegen, gehört nicht zum Vertrag. Dadurch kann eine Implementierung ersetzt werden, solange alle zugesicherten Wirkungen erhalten bleiben.

Information Hiding begrenzt die Zahl der Zustände, die fremder Code herstellen kann. Eine Repräsentationsinvariante wie 0 <= size <= capacity muss dann nur innerhalb der Klasse gesichert werden. Diese lokale Beweislast ist ein wesentlicher Grund für Kapselung.

Die Abstraktionsgrenze ist zugleich eine Grenze für Komplexitätszusagen. Eine Operation kann funktional gleich bleiben und dennoch von konstanter zu linearer Laufzeit wechseln. Deshalb gehören relevante Laufzeitgarantien zum dokumentierten Vertrag.

Schwierigkeitsstufen

1. Öffentliche Operationen von internen Feldern unterscheiden.
2. Eine Repräsentationsinvariante formulieren und an Methoden prüfen.
3. Zwei Implementierungen auf Verhaltens- und Laufzeitäquivalenz untersuchen.

Fallstricke

Getter und Setter erzeugen nicht automatisch eine gute Abstraktion. Wenn sie jeden internen Zustand ungeprüft freigeben, bleibt die Repräsentation faktisch öffentlich.