{"id":314,"date":"2015-04-14T18:27:26","date_gmt":"2015-04-14T16:27:26","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=314"},"modified":"2015-09-06T09:53:33","modified_gmt":"2015-09-06T07:53:33","slug":"ist-wirklich-jeder-ersetzbar","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/ist-wirklich-jeder-ersetzbar\/","title":{"rendered":"Ist wirklich jeder ersetzbar?"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Wer von euch hat schon einmal eine abgeleitete Klasse (also Kindklasse) verwendet, und diese verhielt sich anders als die Ober(-\/Vater)klasse und damit anders, als ihr es erwartet habt? Oder ihr verarbeitet die Ausnahmen (Exception) einer Klasse alle sehr sorgf\u00e4ltig und nun kommt eine Kindklasse der bisherigen Implementierung daher und wirft pl\u00f6tzlich einen neuen Typ einer Ausnahme? Das war so nicht abgesprochen (oder erwartet)! Hier kommt das dritte Prinzip der SOL<\/strong>ID-Prinzipien ins Spiel.<\/p>\n

 <\/p>\n

Liskovsches Substitutionsprinzip (LSP)<\/h2>\n

Die Definition des LSP von Barbara Liskov und Jeanette Wing wurde nach Wikipedia<\/a> so formuliert:<\/p>\n

„Sei q(x)<\/em> eine beweisbare Eigenschaft von Objekten x<\/em> des Typs T<\/em>. Dann soll q(y)<\/em> f\u00fcr Objekte y<\/em> des Typs S<\/em> wahr sein, wobei S<\/em> ein Untertyp von T<\/em> ist.“<\/p>\n

Damit ist doch alles gesagt, oder?<\/p>\n

 <\/p>\n

Erl\u00e4uterung des Prinzips<\/h2>\n

Die oben genannten Definition mal anders formuliert sagt etwas aus wie:<\/p>\n

„Eine Kindklasse sollte sich so verhalten, dass es keine Probleme (oder unerwartetes Verhalten) gibt, wenn sie anstelle der Oberklasse verwendet wird.“<\/p>\n

Diese Aussage wird in den folgenden Regeln konkretisiert.<\/p>\n

1. In einer abgeleiteten Klasse d\u00fcrfen Methodenparameter generischer sein als die Parameter in der gleichen Methode der Oberklasse. Demnach darf in der Kindklasse als Methodenparameter eine Oberklasse des bisherigen Parameters verwendet werden. R\u00fcckgabewerte von Methoden d\u00fcrfen spezifischer sein als in der Oberklasse. Demnach darf in der abgeleiteten Klasse eine Kindklasse des bisherigen R\u00fcckgabewertes verwendet werden.<\/p>\n

Aufgrund der Ableitungshierarchie ist dies plausibel. Angenommen, ich tausche die Verwendung einer Klasse durch eine abgeleitete Kindklasse aus. W\u00fcrde diese in einer Methode nun eine Kindklasse des bisherigen Parameters erwarten, wird dies in den bisherigen Implementierungen nicht ber\u00fccksichtigt.<\/p>\n

Beispiel:<\/span> Ein BMW<\/em> ist ein Auto<\/em> ist ein Fahrzeug<\/em>. Wenn ich nun ein BMW<\/em> anstelle eines Auto<\/em>s erwarte, schl\u00e4gt der Aufruf fehlt, da ein Auto<\/em> kein BMW<\/em> ist – sondern nur andersherum.
\n2. In der abgeleiteten Klasse d\u00fcrfen keine neuen Exception-Typen geworfen werden. Werden alle bisherigen Ausnahmetypen fein s\u00e4uberlich abgefangen wird der Code zur Laufzeit kaputt gehen, wenn nun in einer Kindklasse ein neuer Typ einer Ausnahme geworfen wird, da dieser Typ nicht abgefangen wird. Zul\u00e4ssig ist hingegen, ein Ausnahmetyp von einer verwendeten Ausnahme abzuleiten, da diese auch immer vom Typ der Oberklasse ist und damit die Ausnahmebehandlung vollst\u00e4ndig bleibt.<\/p>\n

 <\/p>\n

3. Vorbedingungen d\u00fcrfen in der Kindklasse nicht verst\u00e4rkt werden. So d\u00fcrfen keine neuen Dinge erwartet werden, die eine bisherige Verwendung nicht erf\u00fcllt. Dies w\u00fcrde alle bisherigen Verwendungen der Oberklasse beim Austausch gegen eine Kindklasse kaputt machen. Nachbedingungen d\u00fcrfen in der Kindklasse nicht geschw\u00e4cht werden. Dies bedeutet, dass eine Kindklasse nicht weniger als ihre Oberklasse zur\u00fcckgeben darf, da hier bei der Verwendung bestimmte Erwartungen an die R\u00fcckgabewerte gekn\u00fcpft sind.<\/p>\n

 <\/p>\n

Zu diesem Prinzip gibt es im gesamten Netz nur ein Beispiel: Quadrat und Rechteck. Quadrat darf nicht von Rechteck ableiten. Warum? Beide haben doch vier Seiten. Ein Quadrat hat jedoch eine Einschr\u00e4nkung gegen\u00fcber einem Rechteck – es haben n\u00e4mlich alle Seiten dieselbe L\u00e4nge, was bei einem Quadrat bei beiden Seitenpaaren unabh\u00e4ngig voneinander der Fall ist. Wenn nun eine Verwendung von Quadrat erwartet, dass H\u00f6he und Breite unabh\u00e4ngig von einander gesetzt werden k\u00f6nnen, bricht dies das Prinzip – ein Quadrat hat nur eine und nur genau eine Kantenl\u00e4nge.<\/p>\n

 <\/p>\n

Unsere Erfahrung mit dem LSP<\/h2>\n

Mir ist gerade nicht bekannt, dass wir das Liskovsche Substitutionsprinzip bewusst eingesetzt haben. F\u00fcr mich ist der zweite genannte Punkt bez\u00fcglich der Ausnahmen interessant. Hier ein Bewusstsein daf\u00fcr zu entwickeln, dass ich bei abgeleiteten Klassen keine neuen Ausnahmetypen definiere und werfe, sondern – falls erforderlich – immer nur bestehende Ausnahmetypen ableite und damit konkretisiere.<\/p>\n

 <\/p>\n

Zusammenfassung<\/h2>\n

Bei allen SOLID-Prinzipien baut ein Prinzip immer auf den vorhergehenden Prinzipien auf. Das LSP mag m\u00f6glicherweise auf Anhieb wenig Relevanz f\u00fcr eure t\u00e4gliche Programmierpraxis haben, aber auch hier geht es um die Austauschbarkeit von Komponenten, die genau eine Verantwortlichkeit haben. Wenn ihr Erfahrungen mit diesem Prinzip gemacht habt, lasst uns teilhaben und schreibt einen Kommentar dazu.<\/p>\n

 <\/p>\n

Viel Spa\u00df beim Anwenden.<\/p>\n

Eure Spa\u00df-Coder.
\nDieser Artikel basiert neben unseren Erfahrungen auf verschiedenen Internetquellen, unter anderem diesem Video bei Youtube:<\/p>\n