Engineering-Philosophie: Barbara Liskov – Der Vertrag ist der Typ

Die wichtigsten Erkenntnisse

• Bei Abstraktion geht es um Verhalten, nicht um Struktur. Ein Typ ist der Vertrag, den er einhält – die Operationen und ihre Bedeutung – und nicht die Bits, die er speichert. Man benutzt die Sache über ihre Versprechen, niemals über ihre Repräsentation.
• Ein Subtyp muss die Versprechen des Supertyps erfüllen. Das Liskovsche Substitutionsprinzip: Überall dort, wo ein Supertyp erwartet wird, muss ein Subtyp funktionieren, ohne die Annahmen des Aufrufers zu verletzen – schwächere Vorbedingungen, stärkere Nachbedingungen, gewahrte Invarianten.
• Modularität bedeutet, über einen Teil nachzudenken, ohne das Ganze zu kennen. Liskovs präzise Definition: Man kann ein Modul isoliert verstehen und überprüfen und darauf vertrauen, dass seine Abhängigkeiten ihre Verträge einhalten. Abstraktion ist das, was dieses Vertrauen legitim macht.
• Sie machte Datenabstraktion zu einem Grundbaustein der Programmierung. Von CLU über Argus bis zum Turing Award 2008 skaliert eine einzige Idee von einer Datenstruktur bis zu einer verteilten Datenbank: Definiere den Vertrag, verbirg den Mechanismus.

Das Prinzip

„Sei φ(x) eine über Objekte x vom Typ T beweisbare Eigenschaft. Dann sollte φ(y) für Objekte y vom Typ S gelten, wobei S ein Subtyp von T ist.“ – Barbara Liskov und Jeannette Wing¹

Langsam gelesen, ist das die formale Formulierung dessen, was das Fachgebiet heute das Liskovsche Substitutionsprinzip nennt, aus ihrem Aufsatz von 1994 mit Jeannette Wing.¹ Streicht man die Notation, sagt sie etwas geradezu Strenges aus: Ein Subtyp darf einen nicht überraschen. Alles, was sich über den Supertyp als wahr beweisen ließ, muss wahr bleiben, wenn man dem Programm stattdessen einen Subtyp übergibt. Der Subtyp erbt die Versprechen des Elternteils, nicht bloß dessen Gestalt – und kann er diese Versprechen nicht halten, dann ist er kein Subtyp, ganz gleich, was der Typprüfer sagt.

Hinter dieser Strenge steht die Krönung einer einzigen Idee, die Liskov vierzig Jahre lang verfolgte: Ein Typ ist durch sein Verhalten definiert, nicht durch seine Repräsentation. Ein Modul ist ein Vertrag – eine Menge von Operationen mit festgelegter Bedeutung – und der ganze Sinn des Vertrags besteht darin, dass man die Sache benutzen kann, ohne zu lesen, wie sie gebaut ist. Substituierbarkeit ist genau diese Überzeugung, angewandt auf Vererbung: Behauptet S, eine Art von T zu sein, dann muss überall dort, wo ein T zugesagt war, ein S dasselbe Versprechen erfüllen. Die Struktur darf sich unterscheiden. Das Verhalten nicht.

Warum das wichtig ist, ist der rote Faden ihrer gesamten Laufbahn: Große Programme sind nur dann beherrschbar, wenn man über ein Teilstück nachdenken kann, ohne das Ganze im Kopf zu behalten. Liskovs Wort dafür war Modularität, und sie meinte damit etwas Präzises: die Fähigkeit, ein Modul isoliert zu verstehen und zu überprüfen, im Vertrauen darauf, dass alles, wovon es abhängt, seinen erklärten Vertrag einhält. Datenabstraktion ist das, was dieses Vertrauen legitim macht, und verhaltensbasierte Subtypisierung ist das, was die Vererbung daran hindert, es klammheimlich zu untergraben. Es ist dieselbe Überzeugung, die unter dem Argument liegt, dass gute Systeme so gebaut sind, dass Geschmack ein technisches System ist, das man prüfen kann – ein Vertrag, den man formulieren und überprüfen kann – statt einer Tradition, die man durch Lesen der gesamten Codebasis aufnimmt.

Kontext

Barbara Jane Huberman Liskov wurde am 7. November 1939 in Los Angeles, Kalifornien, geboren.² 1961 erwarb sie an der University of California, Berkeley, einen Bachelor in Mathematik mit Nebenfach Physik.² Als sie sich für Mathematik-Promotionsprogramme in Berkeley und Princeton bewarb, ließ Princeton überhaupt keine Frauen zu; sie ging stattdessen arbeiten und fand fast zufällig den Weg ins frühe Computing, indem sie bei der Mitre Corporation und in Harvard programmierte, ehe sie sich entschied, doch noch die Promotion anzustreben.²

1968 promovierte sie in Stanford – als eine der ersten Frauen in den Vereinigten Staaten, die einen Doktortitel an einem Informatik-Fachbereich erhielt.² Ihr Doktorvater war John McCarthy, der Erfinder von Lisp und einer der Begründer des Fachgebiets der künstlichen Intelligenz; ihre Dissertation entwickelte ein Programm zum Spielen von Schach-Endspielen, und dabei ersann sie die Killer-Heuristik, einen Trick zur Zugsortierung, der bis heute in der Spielbaumsuche verwendet wird.² Dieses Detail lohnt es festzuhalten: Sie kam über die KI, unter dem Mann, der den Begriff prägte, und wandte sich dann von ihr ab, hin zu dem Problem, das sie prägen sollte – nicht, wie man eine Maschine zum Denken bringt, sondern wie man ein großes Programm begreifbar macht.

Nach Stanford kehrte sie zu Mitre zurück, wo sie den Entwurf des Betriebssystems Venus leitete – ein kleines, kostengünstiges, interaktives Time-Sharing-System, gebaut, um zu erkunden, wie eine durchdachte Maschinen- und Softwarearchitektur ein System vereinfachen kann.²³ 1972 trat sie in die Fakultät des MIT ein, wo sie seither geblieben ist, heute als Institute Professor, dem höchsten Rang, den die Institution vergibt.² Venus hatte ihr die Frage gestellt. Die Software-Krisen-Angst der frühen 1970er-Jahre – die aufkeimende Erkenntnis, dass Programme zu groß geworden waren, als dass irgendjemand sie noch durchdringen konnte – schärfte sie. Die Antwort wurde CLU.

Das Werk

Datenabstraktion und die Programmiersprache CLU

Ab 1973 entwarfen und bauten Liskov und ihre Studierenden am MIT CLU, und es ist eine der unauffällig einflussreichsten Sprachen, die je geschaffen wurden – eine Sprache, in der fast niemand Produktionscode schrieb, deren Ideen heute aber in nahezu allem stecken.⁴ Ihr ordnendes Konzept war der Cluster, von dem die Sprache ihren Namen hat: eine Einheit, die eine Datenrepräsentation mit den auf ihr erlaubten Operationen bündelt und die Repräsentation vollständig hinter dieser Menge von Operationen verbirgt.⁴ Der Cluster war die konkrete Verwirklichung des abstrakten Datentyps – der Idee, dass ein Typ seinen Benutzern nur durch das bekannt sein sollte, was er tut, niemals dadurch, wie er seine Bits speichert.⁴⁵

CLU blieb nicht dabei stehen. Es führte ein bemerkenswertes Bündel von Merkmalen ein oder machte sie populär, die heute zum Standardrepertoire gehören: Iteratoren, implementiert als Koroutinen mit einer yield-Anweisung, sodass man eine Sammlung durchlaufen konnte, ohne ihre interne Struktur offenzulegen; strukturierte Ausnahmebehandlung mit signal und except, behandelt als Teil des normalen Kontrollflusses statt nachträglich angeflanscht; parametrische Polymorphie – typsichere parametrisierte Typen mit Einschränkungen, der Vorfahr der Generics; typsichere Varianten-Typen; und mehrere Rückgabewerte über Parallelzuweisung.⁴ Iteratoren tauchten in Python, C# und Ruby wieder auf. Parametrisierte Typen wurden zu Generics in Java und C#. Die Ausnahmebehandlung prägte Java und C++. Die Entwickler von Swift nannten CLU namentlich als Vorbild.⁴ Die Sprache war eine Samenbank.

Doch die Merkmale waren dem Prinzip nachgelagert. Liskovs Argument lautete, dass Abstraktion der Mechanismus ist, mit dem wir Komplexität bewältigen – man baut eine schwierige Sache, indem man eine saubere Grenze definiert, festlegt, was sie überschreitet, und dann nie über beide Seiten zugleich nachdenken muss. CLU war der Beweis, dass eine Programmiersprache diese Grenze erzwingen kann, statt sie bloß zu gestatten. Der Compiler wurde zum Verbündeten des Vertrags.

Das Liskovsche Substitutionsprinzip

1987 hielt Liskov auf der OOPSLA einen Hauptvortrag mit dem Titel „Data Abstraction and Hierarchy“, der im Folgejahr in den SIGPLAN Notices erschien.⁶ Die objektorientierte Programmierung war im Aufstieg, und mit ihr die Idee der Subtypen – Typen, die von anderen Typen erben und sie erweitern. Liskovs Frage war die naheliegende, die niemand präzise formuliert hatte: Wann ist es eigentlich sicher, einen Subtyp wie seinen Supertyp zu behandeln? Ihre Antwort, in den Worten des Vortrags selbst, war eine Substitutionseigenschaft: „Was hier gewünscht wird, ist etwa die folgende Substitutionseigenschaft: Wenn es für jedes Objekt o1 vom Typ S ein Objekt o2 vom Typ T gibt, sodass für alle in Termen von T definierten Programme P das Verhalten von P unverändert bleibt, wenn o1 für o2 eingesetzt wird, dann ist S ein Subtyp von T.“⁶

Die populäre Umschreibung, die man überall antrifft – „Wenn S ein Subtyp von T ist, dann dürfen Objekte vom Typ T durch Objekte vom Typ S ersetzt werden, ohne dass sich irgendeine der erwünschten Eigenschaften des Programms ändert“ –, ist eine getreue Verdichtung davon.⁷ 1994 machten Liskov und Jeannette Wing dies im Aufsatz „A Behavioral Notion of Subtyping“ streng und gaben die Bedingungen an, die ein echter Subtyp erfüllen muss: Seine Methoden dürfen nicht mehr verlangen (schwächere oder gleiche Vorbedingungen) und nicht weniger versprechen (stärkere oder gleiche Nachbedingungen) als die des Supertyps, und er muss dessen Invarianten und Historieneigenschaften wahren.¹ Diese Bedingungen zusammengenommen sind es, was verhaltensbasierte Subtypisierung bedeutet – und sie sind der Grund, warum die umgangssprachlichen Formulierungen vom Schlag „Wenn es aussieht wie eine Ente und quakt wie eine Ente“ nicht von ihr stammen und den Kern verfehlen: Aussehen und Quaken sind Gestalt; beim Prinzip geht es um gehaltene Versprechen.

Das klassische Gegenbeispiel ist das Quadrat, das vom Rechteck erbt. Ein Rectangle lässt einen Breite und Höhe unabhängig setzen; ein Client darf die Höhe setzen und darauf vertrauen, dass die Breite unverändert bleibt. Ein Square, das davon erbt, muss die beiden gleich erzwingen – sodass das Setzen der Höhe klammheimlich die Breite ändert und die vernünftige Annahme des Clients verletzt wird.⁷ Das Quadrat ist ein Rechteck im Sinne des Wörterbuchs und besteht jede Typprüfung, und ist dennoch kein verhaltensbasierter Subtyp, weil es die Versprechen des Rechtecks nicht halten kann. Die ganze Lehre steckt in dieser einen Gestalt: Vererbung von Struktur ist nicht Vererbung von Vertrag.

Verteilte Systeme: Argus und Thor

Liskov blieb nicht beim Sprachentwurf. In den frühen 1980er-Jahren baute sie Argus, beschrieben als die erste höhere Programmiersprache, die die Implementierung verteilter Programme unterstützte – Programme, die über Maschinen verteilt sind, die unabhängig voneinander ausfallen.²³ Argus, eine Erweiterung von CLU, führte Guardians ein (Objekte, die verteilten Zustand kapseln und über Handler angesprochen werden) sowie atomare Aktionen (Transaktionen, die entweder vollständig oder gar nicht abgeschlossen werden, selbst über Ausfälle hinweg, koordiniert durch Two-Phase-Commit), und es führte Promise Pipelining vor, bei dem man einen Aufruf absetzen und weiterarbeiten kann, bevor sein Ergebnis zurückkommt.⁹ Das harte Problem der Verteilung ist der partielle Ausfall – ein Knoten stirbt, während die anderen weiterleben – und Argus brachte Datenabstraktion dagegen in Stellung: Ein Guardian ist ein Vertrag, der hält, selbst wenn das Netzwerk es nicht tut.

Thor, in den 1990er-Jahren, war eine verteilte objektorientierte Datenbank, die zuverlässige, hochverfügbare persistente Speicherung von Objekten bot, auf die Programme zugriffen, die in vielen Sprachen geschrieben waren.²³ Der durchgehende Faden von CLU her ist exakt. Ein Cluster verbirgt eine Repräsentation hinter Operationen; ein Guardian verbirgt verteilten Zustand hinter atomaren Operationen; ein Thor-Objekt verbirgt Persistenz hinter einer typisierten Schnittstelle. Auf jeder Ebene – einer Datenstruktur, einem Netzwerkdienst, einer Datenbank – ist Liskovs Schritt derselbe: Definiere den Vertrag, verbirg den Mechanismus, und lass den Rest des Systems allein über den Vertrag nachdenken.

Der Turing Award 2008 und das Vermächtnis

2009 verlieh die ACM Liskov den A.M. Turing Award 2008 – die höchste Auszeichnung des Computings – mit der Begründung: „Für Beiträge zu den praktischen und theoretischen Grundlagen des Entwurfs von Programmiersprachen und Systemen, insbesondere im Zusammenhang mit Datenabstraktion, Fehlertoleranz und verteiltem Rechnen.“⁸ Die ausführliche Begründung benennt den roten Faden präzise: Sie brachte „Datenabstraktion, Modularität, Fehlertoleranz, Persistenz und verteilte Rechensysteme“ voran.⁸ Sie hatte bereits 2004 die IEEE John von Neumann Medal erhalten „für grundlegende Beiträge zu Programmiersprachen, Programmiermethodik und verteilten Systemen“, und wurde später in die National Inventors Hall of Fame aufgenommen (2012) sowie mit der Benjamin Franklin Medal (2023) ausgezeichnet.²

Das Vermächtnis ist keine Sprache und kein System, auf das man zeigen und das man ausführen kann. Es ist, dass die Art, wie arbeitende Programmierer heute denken – „programmiere gegen eine Schnittstelle“, „hänge von Verträgen ab, nicht von Implementierungen“, „diese Klasse verletzt das LSP“ –, Liskovs Vokabular ist, so vollständig aufgesogen, dass die meisten, die es benutzen, den Aufsatz nie gelesen haben. Das ist die tiefste Art von Einfluss: wenn die eigene Idee aufhört, zugeschrieben zu werden, weil sie zur Luft geworden ist.

Die Methode

Die Methode ist über dreißig Jahre hinweg konsistent – Betriebssysteme, Sprachentwurf und verteilte Datenbanken.

Definiere den Typ durch sein Verhalten, nicht durch seine Repräsentation. Der wiederkehrende Schritt besteht darin, eine Grenze zu ziehen, genau festzulegen, was sie überschreitet, und sich dann zu weigern, eine Seite von den Interna der anderen abhängen zu lassen. Ein Cluster, ein Guardian, ein Thor-Objekt sind alle derselbe Akt: ein Vertrag, der einen Mechanismus verbirgt.⁴⁵

Mache Modularität wörtlich, dann erzwinge sie. Modularität ist für Liskov keine Vorliebe der Code-Organisation – sie ist die Fähigkeit, über ein Modul isoliert nachzudenken, im Vertrauen darauf, dass seine Abhängigkeiten ihre Verträge einhalten. CLUs Compiler erzwang die Abstraktionsgrenze, statt sie höflich nahezulegen. Die Disziplin ist nur dann real, wenn das Werkzeug sie überprüft.⁴

Ein Subtyp muss die Versprechen des Supertyps halten. Verhaltensbasierte Subtypisierung ist das Prinzip, dass Vererbung ein Vertrag ist, keine Bequemlichkeit. Schwächere Vorbedingungen, stärkere Nachbedingungen, gewahrte Invarianten – der Subtyp darf mehr tun, aber er darf nie mehr verlangen oder weniger versprechen als sein Supertyp.¹

Greife das harte Problem an der Grenze an. Partieller Ausfall in verteilten Systemen ist gerade deshalb brutal, weil er die Fähigkeit zerstört, lokal nachzudenken. Argus’ Antwort war, Abstraktion in das Ausfallmodell selbst hineinzudrücken – atomare Aktionen und Guardians –, sodass eine Programmiererin noch immer über ein Teilstück nachdenken konnte, ohne jede Art zu simulieren, auf die das Netzwerk auseinanderfallen könnte.²³

Trage eine Idee ganz nach oben. Datenabstraktion im Maßstab eines Stacks, eines Netzwerkdienstes und einer Datenbank ist erkennbar dieselbe Idee. Liskov erfand nicht für jede Domäne eine neue Philosophie; sie fand die eine, die skalierte, und ritt sie von einem Typsystem der 1970er-Jahre bis zu einem verteilten Speicher der 1990er-Jahre.

Einfluss-Kette

Wer sie prägte

John McCarthy. Ihr Doktorvater in Stanford, der Erfinder von Lisp und ein Begründer der KI, gab ihr sowohl die Strenge der mathematischen Informatik als auch – über ihre Abwendung von der KI hin zur Programmstruktur – das Problem, das zu ihrem Lebenswerk wurde.² (Direkter Einfluss)

Die Software-Krise und die Ära der strukturierten Programmierung. Liskov reifte als Forscherin genau in dem Moment heran, als das Fachgebiet eingestand, dass Programme dem menschlichen Begreifen entwachsen waren. Die Bewegung der strukturierten Programmierung – Dijkstra, Hoare, Wirth – hatte argumentiert, dass der Kontrollfluss diszipliniert sein muss, um durchdacht werden zu können. Liskov dehnte dieselbe Überzeugung auf Daten aus: Es genügt nicht, zu disziplinieren, wie ein Programm sich bewegt; man muss disziplinieren, was seine Daten bedeuten und wer sehen darf, wie sie gespeichert sind. (Prägender Einfluss)

C.A.R. Hoare und die Disziplin der Spezifikation. Hoares Arbeit zu Vor- und Nachbedingungen und Invarianten – das Nachdenken über Programme als logische Zusicherungen – ist der direkte geistige Vorfahr der Bedingungen verhaltensbasierter Subtypisierung, die sie und Wing präzise machten. (Prägender Einfluss)

Wen sie prägte

Jedes moderne Typsystem. Generics in Java und C#, Iteratoren in Python und C#, Ausnahmebehandlung quer durch die C-Familie, der Entwurf von Swift – die Merkmale, die CLU einführte, sind heute das selbstverständliche Mobiliar nahezu jeder Sprache.⁴

Die objektorientierte Praxis. „Programmiere gegen eine Schnittstelle, nicht gegen eine Implementierung“, die Abhängigkeitsumkehr und das ganze „L“ im SOLID-Vokabular sind Liskovs Prinzip, in die Praxis übersetzt. Eine Generation lernte, eine schlechte Unterklasse zu erkennen, ohne je zu erfahren, wessen Idee das war.⁷

Die Entwicklung verteilter Systeme. Atomare Aktionen, transaktionale Garantien über ausfallende Knoten hinweg und die Praxis, einen entfernten Dienst als Vertrag zu behandeln, der partiellen Ausfall überlebt, lassen sich über Argus und Thor zurückverfolgen.²³

Der rote Faden

Edsger Dijkstra argumentierte, dass ein Programm so strukturiert sein muss, dass ein Mensch darüber nachdenken kann – strukturierte Programmierung war die Disziplin des Kontrollflusses im Dienste der Korrektheit. Liskov ist die direkte Abstammung: Sie tat für Daten, was Dijkstra für die Steuerung tat, und bestand darauf, dass modulares Nachdenken disziplinierte Abstraktionsgrenzen erfordert, nicht bloß disziplinierte Schleifen. Und wo Thompson und Ritchie Unix und C um kleine Komponenten herum bauten, die „eine Sache gut machen“ und sich über saubere Schnittstellen zusammensetzen, lieferte Liskov die Theorie des Warum diese Zusammensetzung vertrauenswürdig ist: Eine Komponente, auf die man sich verlassen kann, ist eine, deren Vertrag man formulieren kann und deren Subtypen ihn erfüllen. Selbst Grace Hoppers Compiler war ein Akt der Abstraktion – er verlagerte die Übersetzung in die Maschine, sodass ein Mensch in seinen eigenen Begriffen denken konnte; Liskov machte die Abstraktion selbst zur Einheit des Programmentwurfs statt zu einer Bequemlichkeit, die der Compiler bereitstellte. (Serienbrücke)

Was ich daraus mitnehme

Die Lehre, die ich behalte, ist, dass eine Schnittstelle ein Versprechen ist und die einzigen Schnittstellen, die etwas wert sind, jene sind, die man tatsächlich einhält. Es ist leicht, eine Typsignatur zu schreiben; es ist schwer, alles zu erfüllen, was diese Signatur impliziert, und es unter einer neuen Unterklasse oder einem Refactoring nie klammheimlich zu verletzen. Liskovs Prinzip ist der Maßstab, an dem ich eine Grenze messe: nicht „besteht die Typprüfung?“, sondern „kann ein Aufrufer dieser Sache überall dort vertrauen, wo ihrem Elternteil vertraut wurde, ohne zu lesen, wie sie gebaut ist?“ Es ist derselbe Maßstab wie Qualität als einzige Variable – die Frage ist nie, ob der Code kompiliert, sondern ob der Vertrag real ist.

In der Welt, in der ich jetzt baue – Agenten, Tool-Schleifen, KI-Systeme –, ist Liskovs Überzeugung tragender denn je, weil die Komponenten, die ich zusammensetze, ihrer Natur nach undurchsichtig sind. Ein Tool, ein Sub-Agent, ein Modellaufruf ist ein Modul: Man ruft es über einen Vertrag auf und kann seine Interna nicht lesen. Das ganze Spiel besteht darin, ob dieser Vertrag hält – ob ein Tool, das behauptet, „die Codebasis zu durchsuchen“, tatsächlich zurückgibt, was seine Spezifikation versprach, oder ob der Austausch eines Modells gegen ein anderes klammheimlich eine Nachbedingung schwächt, von der der Rest des Systems abhing. Das ist das Liskovsche Substitutionsprinzip im Gewand des Jahres 2026: Eine ausgetauschte Komponente muss die Versprechen jener halten, die sie ersetzt. Die Disziplin, Verträge zu formulieren und zu prüfen, dass Subtypen sie erfüllen, ist genau die Disziplin, die die Beweisschwelle zu mehr als einer Parole macht – ein System, über das man in Teilen nachdenken kann, weil jedes Teil sein Wort hält.

FAQ

Was ist Barbara Liskovs Engineering-Philosophie?

Liskovs Kernüberzeugung ist, dass ein Typ durch sein Verhalten definiert ist, nicht durch seine Repräsentation, und dass dies große Programme beherrschbar macht. Ein Modul ist ein Vertrag – eine Menge von Operationen mit festgelegten Bedeutungen – und der Zweck des Vertrags besteht darin, dass man das Modul benutzen kann, ohne zu verstehen, wie es gebaut ist. Diese Idee der Datenabstraktion zieht sich durch alles, was sie baute, von der Sprache CLU bis zum verteilten System Argus, und sie brachte ihr berühmtestes Ergebnis hervor: das Prinzip, dass ein Subtyp jedes Versprechen seines Supertyps erfüllen muss.⁴⁵¹

Was ist das Liskovsche Substitutionsprinzip?

Es ist die Forderung, dass ein Subtyp überall dort verwendbar sein muss, wo sein Supertyp erwartet wird, ohne die Annahmen des Aufrufers zu verletzen. Formal, in Liskovs und Wings Formulierung von 1994: „Sei φ(x) eine über Objekte x vom Typ T beweisbare Eigenschaft. Dann sollte φ(y) für Objekte y vom Typ S gelten, wobei S ein Subtyp von T ist.“¹ In ihrem OOPSLA-Hauptvortrag von 1987 fasste sie es als Substitutionseigenschaft: Wenn das Einsetzen eines Objekts vom Typ S anstelle eines vom Typ T das Verhalten jedes Programms unverändert lässt, dann ist S ein Subtyp von T.⁶ In der Praxis darf ein echter Subtyp nicht mehr verlangen als sein Supertyp (schwächere oder gleiche Vorbedingungen), nicht weniger versprechen (stärkere oder gleiche Nachbedingungen) und muss dessen Invarianten wahren. Die populären „Wenn es aussieht wie eine Ente“-Formulierungen stammen nicht von Liskov und verfehlen den Kern: Beim Prinzip geht es um gehaltene Versprechen, nicht um oberflächliche Ähnlichkeit.⁷

Was hat Barbara Liskov erfunden?

Sie entwarf und leitete die Implementierung der Programmiersprache CLU (begonnen 1973), die abstrakte Datentypen, Iteratoren, strukturierte Ausnahmebehandlung und parametrische Polymorphie einführte oder populär machte – Merkmale, die heute in Java, C#, Python, Swift und anderen Standard sind.⁴ Zuvor baute sie das Time-Sharing-Betriebssystem Venus; später schuf sie Argus, die erste höhere Sprache für verteilte Programme, und Thor, eine verteilte objektorientierte Datenbank.²³ Mit Jeannette Wing formalisierte sie die verhaltensbasierte Subtypisierung, heute Liskovsches Substitutionsprinzip genannt.¹

Warum gewann Barbara Liskov den Turing Award?

Die ACM verlieh ihr den A.M. Turing Award 2008 „für Beiträge zu den praktischen und theoretischen Grundlagen des Entwurfs von Programmiersprachen und Systemen, insbesondere im Zusammenhang mit Datenabstraktion, Fehlertoleranz und verteiltem Rechnen.“⁸ Die Anerkennung umspannt ihre gesamte Laufbahn: Datenabstraktion durch CLU zu einem Grundbaustein der Programmiersprache zu machen, Modularität und die Theorie der Subtypisierung voranzubringen und diese Ideen auf das harte Problem anzuwenden, zuverlässige Systeme über Maschinen hinweg zu bauen, die unabhängig voneinander ausfallen. Sie war eine der ersten Frauen in den USA, die in Informatik promovierte (Stanford, 1968), und ist Institute Professor am MIT.²

Quellen