08.10.2026 · Signal Titans Editorial

Barbara Liskov machte Datenabstraktion zur Sprachfunktion, bevor objektorientierte Programmierung zum Mainstream wurde

Barbara Liskov rechts auf einem warmen Retro-Editorial-Cover mit dezentem Modul-Code-Motiv und dem Schriftzug Boundaries in Code.

Heute nehmen Programmierer eine grundlegende Fähigkeit fast selbstverständlich hin: Man definiert eine neue Art von Wert, legt fest, welche Operationen von außen erlaubt sind, und verbirgt die interne Darstellung, mit der diese Operationen umgesetzt werden. Eine Warteschlange bleibt eine Warteschlange, ohne dass jeder Aufrufer wissen muss, ob dahinter ein Array, eine verkettete Struktur oder etwas anderes steckt.

Anfang der 1970er Jahre war diese Grenze noch kein selbstverständlicher Bestandteil verbreiteter Programmiersprachen. Prozeduren konnten Berechnungen verbergen, doch die Repräsentation eines Datenobjekts systematisch zu schützen und andere Programmteile auf eine festgelegte Schnittstelle zu beschränken, war deutlich schwieriger.

Barbara Liskov und ihre Gruppe am MIT machten aus dieser Idee des Softwareentwurfs einen Mechanismus der Sprache selbst. Das Ergebnis war CLU. Seine historische Bedeutung zeigt sich weniger daran, wie viele Menschen heute noch CLU schreiben, sondern daran, wie vertraut uns viele seiner damals ungewöhnlichen Ideen geworden sind.

Ein Softwareproblem, das zugleich ein Sprachproblem war

Große Programme werden nicht nur wegen ihrer Zeilenzahl schwierig. Sie werden schwierig, wenn zu viele Teile zu viel voneinander wissen. Wenn mehrere Module von der internen Anordnung derselben Datenstruktur abhängen, kann eine kleine Änderung an dieser Darstellung Änderungen im ganzen System erzwingen. Dann pflegt man nicht mehr ein Bauteil, sondern ein Netz aus Annahmen.

Liskovs Arbeiten zur Programmiermethodik zielten darauf, dieses Netz aufzubrechen. Datenabstraktion behandelt ein nützliches Konzept als Einheit mit öffentlichem Verhalten und privater Darstellung. Anderer Code soll wissen, welche Operationen verfügbar sind und was sie bedeuten, aber nicht davon abhängen, wie die Werte intern gespeichert werden.

Heute begegnet dieselbe Idee in Modulen, Klassen, Interfaces, Paketen, abstrakten Datentypen und APIs. Damals war die entscheidende Frage, ob die Programmiersprache selbst diese Grenze unterstützen und absichern konnte, statt sie nur der Disziplin der Entwickler und Kommentaren zu überlassen.

CLU machte die Grenze zu einem Sprachbestandteil

In den 1970er Jahren leitete Liskov am MIT den Entwurf und die Implementierung von CLU. In ihrer späteren Geschichte des Projekts bezeichnete sie CLU als die erste implementierte Programmiersprache mit direkter sprachlicher Unterstützung für Datenabstraktion.

CLU organisierte einen abstrakten Datentyp in einer Konstruktion namens cluster. Der Cluster definierte die Operationen, die Nutzer des Typs aufrufen durften, während die Darstellung unter Kontrolle der Implementierung blieb. Code außerhalb des Clusters konnte mit der Abstraktion arbeiten, ohne die Schnittstelle zu umgehen oder sich auf private Details zu stützen.

Diese Trennung war praktisch relevant. Eine Implementierung konnte ausgetauscht werden, solange das erwartete Verhalten erhalten blieb. Zugleich wurde die Programmstruktur leichter diskutierbar: Ein Team konnte den Vertrag einer Komponente getrennt von den konkreten Datenstrukturen und Algorithmen betrachten.

CLU erprobte außerdem Merkmale, die später in anderen Sprachen alltäglich wurden, darunter Iteratoren, strukturierte Ausnahmebehandlung, parametrisierte Typen und Typprüfung zur Übersetzungszeit über getrennt entwickelte Programmeinheiten hinweg. Die ACM nennt in ihrer Würdigung von Liskov ausdrücklich den Einfluss dieser Ideen auf Ada, Modula-3, C++ und Java.

Warum das Verbergen der Darstellung Wartung verändert

Die tiefere Lehre der Datenabstraktion lautet, dass Information Hiding kein Selbstzweck ist. Es begrenzt die Kosten von Änderungen. Wenn zehn Module direkt auf die Felder einer Struktur zugreifen, kann eine neue Darstellung alle zehn betreffen. Wenn sie nur einen stabilen Satz von Operationen kennen, kann die Änderung häufig innerhalb einer einzigen Grenze bleiben.

Das wurde wichtiger, als Software von kleinen Programmen einzelner Entwickler zu Systemen wurde, die Teams über Jahre pflegten. Es genügte nicht mehr, eine Berechnung korrekt zu machen. Eine große Codebasis musste verständlich bleiben, obwohl sich Anforderungen, Hardware und interne Implementierungen änderten.

Liskov und John Guttag entwickelten diese Gedanken später in Abstraction and Specification in Program Development weiter. Dort geht es darum, große Programme in Module zu zerlegen, die unabhängige Gruppen entwickeln und anschließend wieder zusammensetzen können. Dieselbe Logik erkennt man heute in Bibliotheksschnittstellen, Paketen und Servicegrenzen.

Die Wirkung endete nicht bei CLU

CLU ist nicht der direkte Vorfahr jeder modernen Sprache, und Datenabstraktion ist nicht identisch mit objektorientierter Programmierung. Der historische Punkt ist genauer: CLU zeigte, dass Abstraktion, Kapselung und Parametrisierung praktische Sprachmechanismen sein konnten und nicht nur informelle Entwurfsratschläge.

Liskovs spätere Arbeit über verhaltensbezogene Subtypen führte dieselbe Frage weiter. Sie untersuchte, was ein Typ garantieren muss, damit er einen anderen ersetzen kann, ohne den verwendenden Code zu überraschen. Diese Forschung wurde später mit dem Liskovschen Substitutionsprinzip verbunden und verschob den Blick von bloßen Methodensignaturen auf beobachtbares Verhalten.

Später arbeitete Liskov intensiv an verteilten Systemen und Fehlertoleranz. Das wiederkehrende Motiv blieb jedoch ähnlich: Zuverlässigkeit entsteht durch klare Grenzen. Eine Komponente sollte ein eindeutiges Versprechen abgeben, und fremder Code sollte nicht von Details abhängen, die veränderbar bleiben müssen.

Ein Sprachmerkmal kann eine Denkweise werden

Die Wirkung von CLU erkennt man daran, dass viele seiner Grundideen heute kaum noch erklärt werden müssen. Wir erwarten, dass Module ihren Zustand verbergen. Wir erwarten generische Abstraktionen über mehrere Typen hinweg, strukturierte Wege für Fehlerfälle und Iteratoren, die Daten durchlaufen, ohne ihre Speicherung offenzulegen.

Diese Erwartungen waren nicht zwangsläufig. Sie entstanden aus jahrzehntelanger Sprachforschung, in der Menschen wie Barbara Liskov die Struktur von Software als eigenständiges technisches Problem behandelten.

Die praktische Lehre bleibt aktuell: Wenn sich eine Codebasis schwer ändern lässt, muss das Problem nicht in komplizierten Einzelfunktionen liegen. Vielleicht zeigen ihre Grenzen einfach zu viel. Gute Abstraktion beseitigt Komplexität nicht. Sie entscheidet, wo Komplexität leben darf.