Das Liskovsche Substituionsprinzip

Um die Reihe der S.O.L.I.D.-Prinzipien weiter zu vervollständigen, nehme ich das Liskovsche Substitutionsprinzip in den Katalog auf. Wie sich zeigen wird, erscheint die Einordnung als Prinzip jedoch zumindest als fragwürdig.

Name, Kurzform	Liskovsches Substitutionsprinzip
Synonyme	Substitutionsprinzip, Ersetzbarkeitsprinzip, LSP
Beschreibung	Klassen sollen in jedem Fall durch ihre Unterklassen ersetzbar sein. Formulierung des Prinzips in [Starke 2011]
Erläuterung	In der ursprünglichen Formulierung von Liskov und Wing [Liskov 1994] klingt dies noch weniger eingängig, und auch von „Prinzip“ ist hier noch nicht die Rede. Die Autorinnen bezeichnen Folgendes als „Subtype Requirement“: „Sei p(x) eine beweisbare Eigenschaft von Objekten x des Typs T. Dann soll p(x) auch für Objekte y des Typs S wahr sein, wenn S ein Subtyp von T ist.“ Das LSP drückt keine rein syntaktische Einschränkung aus: Was eine „beweisbare Eigenschaft“ ist, lässt sich nicht ausschließlich über den Programmcode ermitteln. Liskov und Wing schreiben dies allgemeiner der „Typspezifikation“ zu: „Die Typspezifikation legt fest, welche Eigenschaften eines Objekts beweisbar sind.“ Dass es sich hierbei durchaus um rein semantische Annahmen über das Verhalten eines Typs handeln kann, zeigt das gewählte Beispiel: Die Typen Stack und Queue weisen beide die Methoden put() und get() auf, könnten also formal in einer Supertyp/Subtyp-Beziehung stehen. Und dennoch wird ein Programm, dass davon ausgeht, mit einem Stack zu arbeiten, wahrscheinlich nicht funktionieren, wenn es sich dabei um eine Queue handelt. Das LSP steht in dieser Hinsicht dem „Design by Contract“-Ansatz von Bertrand Meyer nahe, in welchem sich das Verhalten eines Stacks mittels Vor- und Nachbedingungen präziser ausdrücken ließe. Zur Bedeutung des Prinzips lassen sich einige Anmerkungen machen: Das LSP ist kein positives Strukturprinzip, sondern ein negatives: Es empfiehlt das Unterlassen gewisser Subtypenbildungen. Wird dagegen verstoßen, so ist es wahrscheinlich, dass die Folgen gravierend sind. Eine positiv formulierte Alternativlösung wird durch das Prinzip nicht formuliert. Das Prinzip ist ausschließlich in dem eng umgrenzten Bereich der Subtypen-Bildung anwendbar. Es scheint insgesamt fragwürdig, ob die Einordnung als Prinzip überhaupt gerechtfertigt ist. Robert C. Martin rechtfertigt seine Aufnahme in die S.O.L.I.D.-Prinzipien mit den gravierenden Folgen seiner Missachtung. Sein negativer Charakter und sein enger Anwendungsbereich lässt es jedoch weniger bedeutsam erscheinen.
Beispiele	Häufig werden mathematische Beispiele wie Ellipse – Kreis oder Rechteck – Quadrat zur Demonstration verwendet. Während sich beispielsweise Länge und Breite eines Rechtecks mit unterschiedlichen Werten belegen lassen, ist dies für Quadrate nicht der Fall. Obwohl das Quadrat in mathematischer Hinsicht eine Spezialisierung des Rechtecks ist, kann es daher gegen das LSP verstoßen, das Quadrat als Subtyp von Rechteck zu modellieren.
Historie	Erste Formulierung des Prinzips in [Liskov 1994]. Ernennung zum S.O.L.I.D.-Prinzip durch Robert C. Martin in seinem Blog „Principles of OOD“.
Art des Prinzips	Grundlegende Einteilung: Produktprinzip. Technologiebezug: Spezifisch. (Objektorientierung). Entwurfsgüte: Strukturprinzip. Handlungsbezug: Erleichterung von Änderung. Kognitionsbezug: Keiner. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Nur hoch in Kombination mit „Design by Contract“-ähnlichen Ansätzen, welche die Typsemantik so formal wie möglich ausdrücken.
Vorteile	Vermeidung schwerwiegender semantischer Probleme bei der Verwendung von Subtypen.
Nachteile	-
Übergeordnete Prinzipien	Verwandschaft mit dem allgemeineren „Prinzip der minimalen Verwunderung“.
Abgleitete Prinzipien	-
Qualitätsmerkmale	Korrektheit(+)

Quellen:

[Starke 2011] – Effektive Software-Architekturen, Gernot Starke (2011)

[Liskov 1994] – A Behavioral Notion of Subtyping, Barbara Liskov, Jeanette Wing (1994)