- Liskovsches Substitutionsprinzip
-
Das liskovsche Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip ist ein Kriterium in der objektorientierten Programmierung, das die Bedingungen zur Modellierung eines Datentyps für seinen Untertyp angibt.
Das liskovsche Substitutionsprinzip wurde 1993 von Barbara Liskov und Jeannette Wing formuliert.[1] In einem nachfolgenden Artikel[2] wurde es folgendermaßen formuliert (Übersetzung):
- Eine stärkere Forderung [als Kovarianz und Kontravarianz] wird benötigt, die das Verhalten von Untertypen einschränkt: Eigenschaften, die anhand der Spezifikation des vermeintlichen Typs eines Objektes bewiesen werden können, sollten auch dann gelten, wenn das Objekt einem Untertyp dieses Typs angehört:
- Sei q(x) eine beweisbare Eigenschaft von Objekten x des Typs T. Dann soll q(y) für Objekte y des Typs S wahr sein, wobei S ein Untertyp von T ist.
Damit ist garantiert, dass Operationen, die auf ein Objekt des Typs T vom Typ S angewendet werden, auch korrekt ausgeführt werden. In einigen der heute übliche Programmiersprachen, die Polymorphie unterstützen, kann dieses Prinzip durch Vererbung von mehr als einem Objekt auf ein anderes verletzt werden. Dann ließe sich nicht stets bedenkenlos ein Objekt vom Typ T durch ein Objekt vom Typ S ersetzen.
Das Problem
→ Siehe auch: Kreis-Ellipse-Problem
Ein wichtiges Element objektorientierter Programmierung ist die Vererbung: Eine Klasse (die Unterklasse) wird von einer anderen Klasse (ihrer Oberklasse) abgeleitet und erbt dabei ihre Methoden und Datenelemente. Dabei können neue Datenelemente hinzugefügt sowie Methoden hinzugefügt oder ersetzt werden.
Dies führt zur Frage, was Vererbung über die Beziehung der Oberklasse zur Unterklasse aussagt. Diese Frage wird normalerweise beantwortet mit: Vererbung beschreibt eine ist-ein-Beziehung. Eine typische Hierarchie von Klassen in einem Grafikprogramm könnte z.B. aus einer Oberklasse GrafischesElement und davon abgeleiteten Unterklassen wie Rechteck, Ellipse oder Text bestehen. Beispielsweise wird man die Ableitung der Klasse Ellipse von der Klasse GrafischesElement begründen mit: Eine Ellipse ist ein grafisches Element. Die Klasse GrafischesElement kann dann beispielsweise eine allgemeine Methode zeichne definieren, die von Kreis ersetzt wird durch eine Methode, die speziell einen Kreis zeichnet.
Das Problem hierbei ist jedoch, dass das "ist-ein-Kriterium" manchmal in die Irre führt. Wird für das Grafikprogramm beispielsweise die Klasse Kreis definiert, so würde man bei naiver Anwendung des "ist-ein-Kriteriums" diese Klasse von Ellipse ableiten, denn ein Kreis ist eine Ellipse, nämlich eine Ellipse mit gleichlangen Halbachsen. Diese Ableitung kann jedoch im Kontext des Grafikprogramms falsch sein: Grafikprogramme erlauben es üblicherweise, die grafischen Elemente zu verändern. Beispielsweise lässt sich bei Ellipsen die Länge der beiden Halbachsen unabhängig voneinander ändern. Für einen Kreis gilt dies jedoch nicht, denn nach einer solchen Änderung wäre er kein Kreis mehr. Hat also die Klasse Ellipse die Methoden SkaliereX und SkaliereY, so würde die Klasse Kreis diese Methoden erben, obwohl ihre Anwendung für einen Kreis nicht erlaubt ist.
Das liskovsche Substitutionsprinzip deckt hier das Problem auf. Im vorliegenden Fall würde festgestellt, dass die Aussage "die Achsen können unabhängig voneinander skaliert werden" zwar für die Klasse Ellipse, jedoch nicht für die Klasse Kreis gilt. Wäre jedoch Kreis eine Unterklasse von Ellipse, so müsste nach dem liskovschen Substitutionsprinzip diese Aussage auch für die Klasse Kreis gelten. Daher ist Kreis hier keine Unterklasse von Ellipse.
Zu beachten ist hierbei, dass die Entscheidung jeweils abhängig vom konkreten Fall ist. Ist beispielsweise eine Manipulation der geometrischen Figur nach der Erzeugung nicht vorgesehen, so kann Kreis durchaus von Ellipse abgeleitet sein: Dann ist "die Achsen können unabhängig voneinander skaliert werden" keine Eigenschaft der Klasse Ellipse, und somit muss sie auch keine Eigenschaft von Kreis sein, um Kreis zur Unterklasse von Ellipse zu machen.
Siehe auch
- Kovarianz, Kontravarianz und Invarianz
- Prinzipien Objektorientierten Designs - weitere Prinzipien objektorientierten Designs
Einzelnachweise
- ↑ Barbara H. Liskov, Jeannette M. Wing: Family Values: A Behavioral Notion of Subtyping. Pittsburgh 1993.
- ↑ Barbara H. Liskov, Jeannette M. Wing: Behavioral Subtyping Using Invariants and Constraints. Pittsburgh 1999 (PostScript).
- Eine stärkere Forderung [als Kovarianz und Kontravarianz] wird benötigt, die das Verhalten von Untertypen einschränkt: Eigenschaften, die anhand der Spezifikation des vermeintlichen Typs eines Objektes bewiesen werden können, sollten auch dann gelten, wenn das Objekt einem Untertyp dieses Typs angehört:
Wikimedia Foundation.