Klasse Rechteck von Quadrat ableiten oder umgekehrt?

[marabu]

Hallo Leute,

vor etwa zwanzig Jahren hat Barbara Liskov (MIT CS Prof) darüber nachgedacht, was Vererbung eigentlich ist und das nach ihr benannte Liskov Substitution Principle (LSP) formuliert:

Zitat:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Demnach ist das Quadrat kein Rechteck im Sinne der Vererbung, sondern lässt sich ganz wunderbar über ein Constraint in der Klasse TRechteck modellieren.

Grüße vom marabu

[OregonGhost]

Ein Quadrat ist ja nicht nur ein spezielles Rechteck, sondern auch eine spezielle Raute. Eine Raute ist jedoch kein Rechteck. Ergo kann ein Quadrat kein Rechteck sein. :mrgreen:

Mal ernsthaft, es ist eine Definitionsfrage, was richtig ist. Einerseits stimmt es, ein Quadrat ist vollständig definiert mit einer Seitenlänge, während ein Rechteck zwei Seitenlängen benötigt. Ein Quadrat hat aber trotzdem zwei Seitenlängen, die sind nur gleich. Wenn ich ein Rechteck mache mit 5cm vertikaler und 5cm horizontaler Seitenlänge, dann ist es ein Quadrat.

Vererbung ist eine "ist-ein"-Beziehung. JEDES Quadrat ist ein Rechteck. Quadrat von Rechteck abzuleiten ist also nach den OO-Prinzipien sauber. Auch finde ich es blödsinnig, mathematisch minimalistisch zu denken. Klar kann man die Fläche eines Quadrats durch Quadrieren der Seitenlänge und den Umfang durch Vervierfachen derselben berechnen - aber man kann genauso die zwei Seitenlängen multiplizieren oder jeweils das Doppelte der beiden Seitenlängen addieren. Der springende Punkt dabei ist der, dass all diese Berechnungen in der Klasse Quadrat nicht implementiert werden müssen, wenn man Quadrat von Rechteck ableitet, weil sie in Rechteck schon definiert sind und ihre Funktionsweise identisch ist, trotz möglicher Vereinfachungen der zugrundeliegenden Mathematik. Wer ernsthaft Quadrat und Rechteck nebeneinander implementiert, endet also mit doppeltem Code. Genau das, was objektorienterte Programmierung vermeiden soll. Ob man da nun über Vererbung hingelangt oder über Constraints, die auch nichts anderes machen, als eine Spezialisierung über bestimmte Bedingungen herzustellen, bleibt sich ziemlich gleich. Je nach Sprache kommt das sogar auf exakt dasselbe raus.

Insofern stimme ich ulrich.b zu und gebe den Professoren eine glatte 5,0 für das Vergessen der Gründe, wofür objektorientierte Programmierung überhaupt existiert (nicht damit man philosophische Fragen klären kann). Wenn überhaupt wäre in meinen Augen der einzige korrekte Grund, Quadrat nicht von Rechteck abzuleiten, der, den ich im ersten Absatz beschrieben habe. Aber den haben die Professoren wohl vergessen. Übrigens dürfte man nach deren Meinung auch nicht von Viereck ableiten. Viereck ist ja immerhin definiert über vier Punkte, oder über vier Seitenlängen und Winkel. Die hat Rechteck oder Quadrat ja auch, obwohl nur ein Teil davon notwendig ist.

[shmia]

Zitat:

Zitat von ulrich.b

Doch das Institut für "Computer Languages" an der TU Wien sieht das anders!!! Die reden davon, dass zwar eine Vererbungsbeziehung in die eine Richtung existiert (Quadrat => Rechteck) jedoch eine sg. "Reale-Welt Beziehung" in die andere (In der Mathematik ist ein Rechteck mit selben Seitenlängen ein Quadrat). => Nach dem Comp Lang Institut darf man beide nicht voneinander ableiten....

Viele Wege führen nach Rom. Ebenso haben die verschiedenen Ansätze zur Modellierung der Klassen ihre Vor- und Nachteile.
Man könnte z.B. auf die Klasse TQuadrat ganz verzichten und nur mit TRechteck auskommen.
Zusätzlich wird die (virtuelle) Funktion GetDrehsymmetrie:integer eingeführt.
Ist das Rechteck ein Quadrat liefert die Funktion 4 ansonsten 2. (gleichseitige Dreiecke -> 3, gleichs. Fünfecke -> 5, Kreis -> unendlich, Elypse -> 2, ...)

Wenn man TQuadrat von TRechteck ableitet, dann könnte man ein TRechteck-Objekt mit gleichen Seitenlängen erzeugen, dass zwar de Fakto ein Quadrat ist, aber nicht von der Klasse Quadrat abstammt.

Mit dem Ansatz des Comp Lang Institut könnte dies verhindert werden. Es könnte hier also nie ein Objekt der Klasse TRechteck geben, dass gleiche Seitenlängen hat (ansonsten würde eine Exception erzeugt).
Es kommt aber immer drauf an, was man erreichen möchte.
So wäre der Ansatz des Comp Lang Institut eher störend, wenn man die Seitenlängen nachträglich verändern möchte (z.B. Skalierung in Y-Richtung), da nun aus einem Rechteck ein Quadrat werden könnte.

[mimi]

Na, dann darf ich das bei meiner GUI ja gar nicht so machen, wie ich es im Moment mache, oder ?

ich mache das z.b. so:

Jede Komponente die einen Text da stellt benutzt TmyLabel.
TmyCheckbox ist von typ TmyCompo und TmyRadiobox von Typ TmyCheckbox.

und alle Komponenten haben mind. eine Variable von typ TmyShape für den rahmen und die Fillfläche.

oder z.b. ist TmyTrackbar von TmyProssesbar abgeleitet. Weil ja eigentlich genau das gleiche Passiert, nur der unterschied: eine Prossesbar wird ja nicht gezogen von z.b. der Maus.

Oder die Scrollbar ist von typ TmyTrackbar, deshalb hat TmyTrackbar eine Variable mehr bekommen:
isScrollbar. Damit ein bestimmter Bereich verschoben werden kann und nicht von Anfang bis Neue Position gezeichnet wird.