Seite wählen

Das Liskov Substitutionsprinzip zu verstehen hat mich mehr Zeit gekostet, als alle anderen SOLID Prinzipien zusammen. Der Grund ist der, dass wenn man es verletzt es sehr schwer zu korrigieren ist, denn man hat dann oft einen Gravierenden strukturellen Fehler in der Vererbungsdenke. Zum Beispiel könnte man meinen, dass eine Festplatte, der Speicher und ein Drucker vom der Klasse Device (Gerät) erben. Alle können Lesen und Schreiben. Hmm, naja bis auf der Drucker, der kann zwar Schreiben aber nicht lesen, aber dafür meinetwegen piepen. Und schon haben wir den Fall, dass die Lesemethode anstatt ein Boolean zurückzugeben eine Exception wirft.


Also ist das Konzept der Vererbung dann nicht 100 % passend und man muss sich nach einer anderen eleganten Lösung umsehen, die wirklich vom konkreten Fall abhängt und meist mit doch recht tiefen strukturellen Änderungen einhergeht. Um dem von Anfang an aus dem Weg zu gehen, sollte man sich im Vorfeld im Klaren darüber sein, was das Liskov Substitutionsprinzip besagt und tiefergehend darüber meditieren.
Objekte einer Elternklasse sollten mit Objekten einer Kindklasse austauschbar sein, ohne die Anwendung dabei zu beeinträchtigen. Dies erfordert, dass Objektmethoden der Kindklassen sich auf dieselbe Art und Weise verhalten müssen, wie die Objektmethoden der Elternklassen.
Das bedeutet in dem konkreten Fall, dass meine Kindmethode des Schreibens inkompatibel ist mit der Elternmethode des Device. Also ich kann die beiden Objekte nicht miteinander austauschen, ohne dass meine Applikation in die Brüche geht.
Die Idee von Barbara Liskov ist es striktere Regeln anzuwenden, wenn es darum geht Funktionalitäten der Elternklassemethoden durch die, der Kindklassemethoden zu überschreiben.
Liskov hat das in 5 praktische Regeln verpackt. 

  1. Funktions-/Methodenargumente der Kindklasse müssen mit denen der Elternklasse übereinstimmen.
  2. Rückgabewerttyp der Kindklassenfunktion muss mit Rückgabewerttyp der Elternklassenfunktion übereinstimmen
  3. Pre-Conditions der Kindklassenkfunktion dürfen nicht größer sein, als die Pre-Conditions der Elternklassenfunktion
  4. Post-Conditions der Kindklassenkfunktion dürfen nicht kleiner sein, als die Post-Conditions der Elternklassenfunktion
  5. Exceptions, die von der Kindklassenfunktion geworfen werden, müssen dieselben sein, wie die der Elternklassenfunktion oder von ihr vererben