Vererbung: Rechteck und Quadtrat!?
-
"Ein Quadrat ist ein Rechteck" wahr und falsch sein kann
Na von wegen ... Was soll den an der Aussage falsch sein? Ich kann auch sagen, wenn vor mir nen quadratischer Körper ist, das er rechteckig ist.
-
(D)Evil schrieb:
"Ein Quadrat ist ein Rechteck" wahr und falsch sein kann
Na von wegen ... Was soll den an der Aussage falsch sein? Ich kann auch sagen, wenn vor mir nen quadratischer Körper ist, das er rechteckig ist.
Du liest am besten mal den Thread von vorne.
-
pumuckl schrieb:
Das Problem ist, dass unsere gemeine Sprache nicht genau genug ist, so dass die Behauptung "Ein Quadrat ist ein Rechteck" wahr und falsch sein kann, je nachdem was wir unter Quadraten und Rechtecken verstehen.
sag nicht 'ein quadrat ist ein rechteck' sondern sag' 'ein quadrat ist die erweiterung eines rechtecks' und dann merkst du schnell, dass der satz falsch ist (auch umgekehrt), denn mit vererbung kann man zwar etwas dazupacken, aber nichts wegnehmen.
-
@Bashar: Hmm ... tjo hab das schon zum groß Teil gelesen. Finde aber trotzdem keinen haltbaren Argumentationspunkt, ein Quadrat als gesonderten Fall anzusehen. Es sei denn du brauchst die besonderen Definitionen die nur bei einem Quadrat zutreffen. Quadrat ist nunmal laut Definition ein Rechteck**.** Von daher ist eine Basisklasse Rechteck, von der man keine Klasse Quadrat ableiten kann, falsch implementiert. Von Quadrat auf Rechteck ist es nat. anders ...
-
Und was genau ist dein Gegenargument? Es ging um die Methoden setWidth/setHeight eines Rechtecks, die man nicht korrekt in einem Quadrat implementieren kann. Ein Objekt ist nunmal in der OOP nicht nur ein bestimmtes Ding, sondern auch das, was man damit machen kann.
Man könnte höchstens argumentieren (vielleicht tust du das ja, ohne es zu sagen), dass Rechteck dann eben diese Methoden nicht haben darf. Dann ist natürlich trivial jedes Quadrat auch ein Rechteck, die Frage, woran man solche Problem im Allgemeinen erkennt, bleibt aber bestehen.
-
Ich sehe nicht wo dein Problem ist? Die Funktion setWidth und setHeight würden halt im Quadrat überschrieben ... z.B. gibt es auch eine Basisklasse Tier. Wenn die nun die Funktion laufen hätten, würdest du bei manchen(den meisten) wohl auch die lauf-Funktion überschreiben müssen ... setWidth und setHeight würden im Quadrat das selbe machen, und zwar m_nHeight und m_nWidth auf den übergeben Wert setzen ... wo ist da euer Problem?
-
(D)Evil schrieb:
Ich sehe nicht wo dein Problem ist? Die Funktion setWidth und setHeight würden halt im Quadrat überschrieben ... z.B. gibt es auch eine Basisklasse Tier. Wenn die nun die Funktion laufen hätten, würdest du bei manchen(den meisten) wohl auch die lauf-Funktion überschreiben müssen ... setWidth und setHeight würden im Quadrat das selbe machen, und zwar m_nHeight und m_nWidth auf den übergeben Wert setzen ... wo ist da euer Problem?
Das ist schlechtes OOP! Eine abgeleitete Klasse macht Zusicherungen über Attribute der Oberklasse. Das Liskovsche Substitutionsprinzip wird verletzt.
Programmier doch mal eine Methode, die ein Rechteck derart verzerrt, dass es bei gleichem Flächeninhalt die Breite 1 hat. Und dann finde heraus, ob diese Methode mit Quadraten funktioniert.tfa
-
jedes rechteck ist ein quadrat, aber ist jedes quadrat auch ein rechteck? wie war das mit der vererbung?
-
(D)Evil schrieb:
Ich sehe nicht wo dein Problem ist? Die Funktion setWidth und setHeight würden halt im Quadrat überschrieben ...
Wenn du sie so überschreibst, dass sie dafür sorgen, dass width == height immer gilt, kannst du ein Quadrat nicht mehr allgemein überall einsetzen, wo ein Rechteck erwartet wird.
Überschreibst du sie nicht, bleibt ein Quadrat nicht lange ein Quadrat.
Warum wiederhole ich das eigentlich für dich? Das wird hier doch von Anfang an diskutiert.
-
Hi,
ich denke, ein Problem dabei ist, dass es im "echten Leben" "Spezialisierung" eigentlich immer heißt: Reduzierung von Freiheitsgraden. (="Hinzufügen von Invarianten").
In den mir bekannten OO-Sprachen aber bedeutet "Ableiten" "Hinzufügen von Eigenschaften": Man kann kein "SetWidth()" mehr wegmachen, sondern nur Neues hinzufügen (oder ggf. Funktionalität via overriding umdefinieren).
Deswegen passt oftmals "Spezialisierung via Ableiten" nicht.
So auch in diesem Fall.Gruß,
Simon2.