Diskussion:Liskovsches Substitutionsprinzip

Der erste Satz der Einleitung endet mit "...ohne dabei das Programm zu verändern." Das kann so nicht richtig sein. Aenderungen im Verhalten sind ein immanenter Bestandteil von Flusssteuerung durch Polymorphie. Auch die Einleitung endet mit "Dann ließe sich nicht stets bedenkenlos ein Objekt vom Typ {\displaystyle T} T durch ein Objekt vom Typ {\displaystyle S} S ersetzen.", was diesen Umstand reflektiert. Verstehe ich hier etwas falsch? -- 30. Oct. 2018

Müsste es nicht heißen: "...wobei S ein Untertyp von T ist." -- 25. Feb. 2006

Stimmt, steht auch so in der Quelle. Ich hab's korrigiert, danke für den Hinweis. --jpp ?! 09:14, 27. Feb 2006 (CET)

Trotzem steht an einigen Stellen immer noch Unterklasse, obwohl es dort besser Untertyp hieße, z.B. direkt im ersten Satz. Nebenbei ich finde den Begriff Subtyp besser als Untertyp, das hat aber höchstens ästhetische Gründe.

--Gar kein name 18:44, 25. Nov. 2007 (CET)

Ich vermisse hier noch die Regeln für das Einhalten des Liskovschen Substitutionsprinzips

- Die Vorbedingungen an die überschriebenen Methoden sind nicht strenger als die für die Basisklasse.

- Die Nachbedingung an die überschriebenen Methoden sind nicht schwächer als die für die Basisklasse.

- Die überschriebenen Methoden werfen nicht andere / weitere Exceptions als die in die Basisklasse. (dies ist eigentlich schon im 1. Punkt enthalten)

-- 15. Feb. 2006

Ist auf jeden Fall besser verständlich als das Kreis-Ellipse-Dilemma, weil die es die Methoden angibt, die eine Ellipse hat, aber ein Kreis nicht haben darf. - Zoelomat 18:58, 22. Jun 2004 (CEST)

Die Darstellung der Kreis-Ellipse-Beziehung ist im Artikel nicht korrekt. das Substitutionsprinzip ist ein Typkonzept, d.h. es geht darum, ob die Typen "passen" (Wohlgetypheit). Dabei spielt es zunächste mal keine Rolle, was zur Laufzeit passiert. Das wären semantische Betrachtungen (um objektorientiert zu modellieren muss man natürlich beide Aspekte beachten). Die Eigenschaft, dass bei einem Kreis beide Achsen gleich lang sein müssen, ist eine semantische Eigenschaft. Diese nur an den Typen ablesen zu wollen, kann gar nicht funktionieren.

Kreis kann sehr wohl Subtyp von Ellipse sein. Dazu muss ein Kreis mindestenst die Methoden beherrschen, die eine Ellipse beherrscht, damit man jeden Kreis dort einsetzen kann, wo eine Ellipse verlangt wird. Also muss ein Kreis mindestens zwei Methoden zur Skalierung der beiden Achsen beherrschen. Wie er diese implemtiert ist keine Frage des Typs mehr, sondern der Semantik. Damit der Kreis ein Kreis bleibt, muss jede Änderung der einen Achse auch die andere ändern. Das ist aber kein Problem, dafür kann man ja Methoden überschreiben.

Einem Objekt, das eine Nachricht an einen Kreis sendet, kann es übrigens herzlich egal sein, welche Nebenwirkungen diese hat und was der Kreis sonst so damit anfängt. Für dieses Objekt muss nur klar sein, dass der Kreis diese Methode beherrscht und welcher Antworttyp zu erwarten ist.

Man kann es übrigens auch so auffassen, dass eine Ellipe auch nur ein Kreis ist, der aber zwei veränderbare Achsen hat. Während man in diesem Modell vom Kreis nur eine Methode erwartet, braucht die Ellipse zwei. D.h. hier entsteht der Subtyp durch eine weitere Methode (Breitenregel).

Welche Sichtweise man wählt, hängt davon ab, welche Eigenschaften der Betrachteten Objekte man zur Lösung des anstehenden Problems braucht.

--Gar kein name 18:44, 25. Nov. 2007 (CET)

Der Artikel handelt von Typen. Die Verbindung von Klassen mit Typen ist zwar in den meisten Programmiersprachen gegeben, aber nicht zwangsläufig. Gerade moderne Ansätze versuchen die Begriffe Unterklassenbildung und Untertypbildung zu trennen. Auch ist Unterklassenbildung nicht mit Vererbung gleichzusetzen. Dahingehend ist das Lemma etwas ungenau. Das Problem unter Berücksichtigung der von mir aufgeführten Begriffe wird ganz gut in den ersten Kapiteln des Buches A Theory of Objects behandelt. --guwac 10:24, 8. Mär 2005 (CET)

Kritik

Leider gibt es keine Referenz auf die drei genanten Kritikpunkte...

1) Die Definition bezieht sich explizit auf die direkte Zugehörigkeit von Objekten zu Typen...

2) Das LSP ist für einige Anwendungsfälle zu streng gefasst...

3) Das LSP ist implizit allquantifiziert...

Obwohl ich die Kritik einordnen kann, interessieren mich doch die Quellen. Traute Meyer 19:35, 27. Mär. 2009 (CET)

Wenn es denn keine Referenzen gibt, wuerde ich diese Informationen demnaechst herausnehmen. Traute Meyer 19:42, 3. Apr. 2009 (CEST)

Wurde entfernt. Traute Meyer 18:19, 9. Apr. 2009 (CEST)

Beweisbarkeit von Eigenschaften

Es sollte deutlich herausgearbeitet werden, das in der Formulierung Sei q(x) eine beweisbare Eigenschaft von Objekten x des Typs T. solche Eigenschaften beweisbare Eigenschaften sind, die anhand der Spezifikation abgeleitet werden können. Die Implementierung ist da nicht maßgeblich.

Ich habe das gelöst indem ich der Übersetzung des Satzes eine Übersetzung des vorausgehenden Absatzes hinzugefügt habe. Ich weiß nicht ob das die beste Möglichkeit ist; auf jeden Fall besteht Klärungsbedarf. -- Traxer 10:26, 3. Sep. 2009 (CEST)

Lesbarkeit

Den Satz "Bezogen auf einzelne Methoden bedeutet das ..." usw. verstehe ich nicht mal nach dem 3. Durchlesen. Es wäre besser hier einfache Formulierungen zu verwenden. (nicht signierter Beitrag von AlphaCentauri24 (Diskussion | Beiträge) 14:14, 17. Jul. 2020 (CEST))

Hab versucht den Satz jetzt etwas zu vereinfachen. --13:30, 18. Jul. 2020 (CEST) (unvollständig signierter Beitrag von Sebastian.Dietrich (Diskussion | Beiträge) )