Quelltext der Seite Liskovsches Substitutionsprinzip

Das '''Liskovsche Substitutionsprinzip''' ('''LSP''') oder '''Ersetzbarkeitsprinzip''' ist ein Kriterium in der [[Objektorientierte Programmierung|objektorientierten Programmierung]], das die Bedingungen zur Modellierung eines [[Datentyp]]s für seinen [[Subtyp|Untertyp]] angibt. Es besagt, dass ein Programm, das [[Objekt (Programmierung)|Objekte]] einer [[Basisklasse]] ''T'' verwendet, auch mit Objekten der davon [[Abgeleitete Klasse|abgeleiteten Klasse]] ''S'' korrekt funktionieren muss, ohne dabei das Programm zu verändern.

Das Liskovsche Substitutionsprinzip wurde erstmals 1987 von [[Barbara Liskov]] auf einer Konferenz ''Data abstraction and hierarchy'' vorgestellt und wurde 1993 von Barbara Liskov und [[Jeannette Wing]] formuliert.<ref>Barbara H. Liskov, Jeannette M. Wing: ''Family Values: A Behavioral Notion of Subtyping''. Pittsburgh 1993.([http://reports-archive.adm.cs.cmu.edu/anon/1993/CMU-CS-93-187.ps PostScript])</ref> In einem nachfolgenden Artikel wurde es folgendermaßen formuliert (Übersetzung):

{{Zitat|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 <math>q(x)</math> eine beweisbare Eigenschaft von Objekten <math>x</math> des Typs <math>T</math>. Dann soll <math>q(y)</math> für Objekte <math>y</math> des Typs <math>S</math> wahr sein, wobei <math>S</math> ein Untertyp von <math>T</math> ist.|ref=<ref>Barbara H. Liskov, Jeannette M. Wing: ''Behavioral Subtyping Using Invariants and Constraints''. Pittsburgh 1999 ([http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps PostScript]).</ref>}}

Damit ist garantiert, dass Operationen, die auf ein Objekt des Typs <math>T</math> vom Typ <math>S</math> angewendet werden, auch korrekt ausgeführt werden. In einigen der heute üblichen Programmiersprachen, die [[Polymorphie (Programmierung)|Polymorphie]] unterstützen, kann dieses Prinzip durch [[Vererbung (Programmierung)|Vererbung]] von mehr als einem Objekt auf ein anderes verletzt werden. Dann ließe sich nicht stets bedenkenlos ein Objekt vom Typ <math>T</math> durch ein Objekt vom Typ <math>S</math> ersetzen.

Bezogen auf einzelne [[Methode (Programmierung)|Methode]]n bedeutet das Liskovsche Substitutionsprinzip, dass beim [[Überschreiben (OOP)|Überschreiben]] einer Methode durch eine abgeleitete Klasse die [[Vorbedingung (Informatik)|Vorbedingungen]] nur abgeschwächt und die [[Nachbedingung (Informatik)|Nachbedingungen]] nur verstärkt werden dürfen (siehe [[Design by Contract]]).

== Das Problem ==
{{Hauptartikel|Kreis-Ellipse-Problem}}

[[Datei:Uml grafischeselement rechteck ellipse text.jpg|mini|350px|[[UML]]-Darstellung der Klasse GrafischesElement und deren Unterklassen]]

Ein wichtiges Element objektorientierter Programmierung ist die [[Vererbung (Programmierung)|Vererbung]]: Eine [[Klasse (objektorientierte Programmierung)|Klasse]] (die Unterklasse) wird von einer anderen Klasse (ihrer Oberklasse) abgeleitet und erbt dabei ihre [[Objektorientierte Programmierung|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.&nbsp;B. aus einer Oberklasse <code>GrafischesElement</code> und davon abgeleiteten Unterklassen wie <code>Rechteck</code>, <code>Ellipse</code> oder <code>Text</code> bestehen. Beispielsweise wird man die Ableitung der Klasse <code>Ellipse</code> von der Klasse <code>GrafischesElement</code> begründen mit: Eine Ellipse ''ist ein'' grafisches Element. Die Klasse <code>GrafischesElement</code> kann dann beispielsweise eine allgemeine Methode <code>zeichne</code> definieren, die von <code>Ellipse</code> ersetzt wird durch eine Methode, die speziell eine Ellipse 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 <code>Kreis</code> definiert, so würde man bei naiver Anwendung des „''ist-ein''-Kriteriums“ diese Klasse von <code>Ellipse</code> ableiten, denn ein Kreis ''ist eine'' Ellipse, nämlich eine Ellipse mit gleich langen 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 <code>Ellipse</code> die Methoden <code>SkaliereX</code> und <code>SkaliereY</code>, so würde die Klasse <code>Kreis</code> 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 <code>Ellipse</code>, jedoch nicht für die Klasse <code>Kreis</code> gilt. Wäre jedoch <code>Kreis</code> eine Unterklasse von <code>Ellipse</code>, so müsste nach dem Liskovschen Substitutionsprinzip diese Aussage auch für die Klasse <code>Kreis</code> gelten. Daher ist <code>Kreis</code> hier keine Unterklasse von <code>Ellipse</code>.

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 <code>Kreis</code> durchaus von <code>Ellipse</code> abgeleitet sein: Dass die Achsen unabhängig voneinander skaliert werden können, ist dann keine Eigenschaft der Klasse <code>Ellipse</code>, und somit muss sie auch keine Eigenschaft von <code>Kreis</code> sein, um <code>Kreis</code> zur Unterklasse von <code>Ellipse</code> zu machen.

Das Kreis-Ellipse-Problem als C#-Code:<syntaxhighlight lang="csharp" line="1">
public class GrafischesElement {
    public virtual void Zeichne() {
        // Code zum Zeichnen des Elements...
    }
}

public class Ellipse : GrafischesElement {
    public override void Zeichne() {
        // Code zum Zeichnen der Ellipse...
    }

    public void SkaliereX(double pX) {
        // Code zum Skalieren der X-Achse...
    }

    public void SkaliereY(double pY) {
        // Code zum Skalieren der Y-Achse...
    }
}

public class Kreis : Ellipse {
    /** SkaliereR sollte statt SkaliereX/SkaliereY aufgerufen werden. */
    public void SkaliereR(double pR) {
        SkaliereX(pR * 2);
        SkaliereY(pR * 2);
    }
}

public void ZeichenBrett() {
	public double X { get; set; }
	public double Y { get; set; }
	// Noch mehr Eigenschaften...
	
	private List<GrafischesElement> ListeGrafischeElemente { get; set; }
	// Noch mehr Variablen...
	
	public void Aktualisiere(){
		foreach(GrafischesElement gElem in ListeGrafischeElemente) {
			if (gElem is Ellipse) {
				var ellipse = gElem as Ellipse;
				ellipse.SkaliereX(this.X); // <-- Kreis erbt von Ellipse! Kreis IST eine Ellipse!
				ellipse.SkaliereY(this.Y); // <-- Kreis erbt von Ellipse! Kreis IST eine Ellipse!
			}
			// Noch mehr Code zum Neu-Zeichnen andere grafische Elemente...
		}
	}		
}
</syntaxhighlight>

== Einzelnachweise ==
<references />

{{Navigationsleiste Prinzipien objektorientierten Designs}}

[[Kategorie:Objektorientierte Programmierung]]