25. Liskov-Substitutionsprinzip

Themen

Das Liskov-Substitutionsprinzip

Beispiele für seinen Einsatz

Bedeutung im Gesamtkontext der Software-Architektur

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_25

• Objekte einer abgeleiteten Klasse sollten sich
  genauso verhalten wie Objekte der Basisklasse.
• Verletzungen des Liskov-Substitutionsprinzips
  lassen sich immer nur im konkreten Kontext feststellen.
• Das Liskov-Substitutionsprinzip ist eine wesentliche Voraussetzung für das Open-Closed-Prinzip.
• „Entwurf gemäß Vereinbarung“ (design by contract)
  formalisiert die Erwartungen an eine Klasse.
• Allgemein sorgt das Prinzip für klar definierte Schnittstellen
  und austauschbare Implementierungen auf allen Ebenen.

Objekte einer abgeleiteten Klasse sollten sich genauso verhalten wie Objekte der Basisklasse. Diese scheinbar einfache, nach ihrer Urheberin Liskov-Substitutionsprinzip (LSP) genannte Regel stellt klare Prinzipien für die Vererbung in der objektorientierten Programmierung auf. Es ist im Kontext guter objektorientierter Architektur und den SOLID-Prinzipien eng mit dem Open-Closed-Prinzip verbunden. Viele Autoren sehen die Regeln für Vererbung, die das LSP aufstellt, als notwendige Voraussetzung für korrekte Vererbung in der objektorientierten Programmierung an.

Inwieweit eine Vererbungsbeziehung dem LSP folgt, lässt sich letztlich immer nur im konkreten Kontext feststellen. Die konsequente Anwendung des LSP sorgt für klar definierte Schnittstellen und somit austauschbare Implementierungen – und das auf allen Ebenen der Softwarearchitektur bis hin zum Zusammenspiel zwischen Komponenten und Schichten.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Welche Bedeutung kommt dem LSP im Kontext der SOLID-Prinzipien und der gesamten Softwarearchitektur zu?
• Warum lässt sich das LSP, obwohl ursprünglich für die Vererbungsrelationen von Klassen in der OOP definiert, auch auf abstrakterer architektonischer Ebene anwenden?
• Was ist ein sehr typisches, offensichtliches Beispiel im Code für eine Verletzung des LSP?
• Welche Vor- und Nachbedingungen gelten laut LSP für abgeleitete Klassen im Vergleich zur Basisklasse?
• Welche Möglichkeit können Sie sich vorstellen, das LSP auf Ebene des Codes im Sinne eines „Enturfs gemäß Vereinbarung“ (design by contract) zu formalisieren, wenn Sie Programmiersprachen verwenden, die derlei Strukturen nicht bereits mitbringen?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Die Originalformulierung des Liskov-Substitutionsprinzips findet sich in [Liskov, 1987Liskov, Barbara (1987): Data Abstraction and Hierarchy, ACM Sigplan Not. 23:17-34], eine etwas verständlichere Formulierung in [Liskov, 1994Liskov, Barbara H.; Wing, Jeannette M. (1994): A behavioral notion of subtyping, ACM Trans. Program. Lang. Syst. 16:1811-1841]. Im Rahmen der SOLID-Prinzipien diskutiert wird es von Robert C. Martin in Kapitel 10 in [Martin, 2003Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey] sowie in Kapitel 9 von [Martin, 2018Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston]. Sehr viele hilfreiche Hinweise für seine Anwendung sowie für das Konzept des „Entwurfs kraft Vereinbarung“ (design by contract) finden sich auch in [Meyer, 1997Meyer, Bertrand (1997): Object-Oriented Software Construction, Prentice Hall PTR, Upper Saddle River, New Jersey].

• Liskov, Barbara (1987): Data Abstraction and Hierarchy, ACM Sigplan Not. 23:17-34
• Liskov, Barbara H.; Wing, Jeannette M. (1994): A behavioral notion of subtyping, ACM Trans. Program. Lang. Syst. 16:1811-1841
• Martin, Robert C. (2003): Agile Software Development. Principles, Patterns, and Practices, Prentice Hall, Upper Saddle River, New Jersey
• Martin, Robert C. (2018): Clean Architecture. A Craftman's Guide to Software Structure and Design, Prentice Hall, Boston
• Meyer, Bertrand (1997): Object-Oriented Software Construction, Prentice Hall PTR, Upper Saddle River, New Jersey