Klasse Rechteck von Quadrat ableiten oder umgekehrt?

[Chris P]

Hi Leute,

ich stehe vor folgender Aufgabe:

"Man hat zwei Klassen Quadrat und Rechteck zur Darstellung geometrischer Objekte.
Sollte man nun die Klasse Quadrat von der Klasse Rechteck ableiten? Oder umgekehrt? Warum?"

Also so viel erstmal zur Aufgabengabenstellung.

Ich habe mir gedacht, dass das Quadrat ja ein spezielles Rechteck ist mit der Eigenschaft das die Länge gleiche der Breite ist.

Man kann also sagen, dass die Klasse Rechteck eine Verallgemeinerung und die Klasse Quadrat eine Spezialisierung ist.


Ich würde dann sagen, dass Rechteck die Basisklasse ist und die Klasse Quadrat die Ableitung.


Was meint ihr dazu?

[BenjaminH]

Zitat:

Zitat von Chris P

Ich habe mir gedacht, dass das Quadrat ja ein spezielles Rechteck ist mit der Eigenschaft das die Länge gleiche der Breite ist.

Man kann also sagen, dass die Klasse Rechteck eine Verallgemeinerung und die Klasse Quadrat eine Spezialisierung ist.


Ich würde dann sagen, dass Rechteck die Basisklasse ist und die Klasse Quadrat die Ableitung.


Was meint ihr dazu?

Richtig.
TQuadrat= class(TRechteck)

[DeddyH]

Seh ich genauso.

[Dezipaitor]

man sollte immer vom Allgemeinen ins Spezielle ableiten.

Also die Elternklassen sind allgemeiner gehalten, als die Kindklassen.

[ulrich.b]

Echt witzig diese Frage. Vor einem Jahr bin ich vor derselben gestanden. Ich musste für mein Studium in Java genau dieses Problem lösen. Ich habe es in der Abgabe dann auch so gemacht wie ihr es vorgeschlagen habt, und es auch der Rest der Welt sieht (class Quadrat extends Rechteck).

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. Man darf höchstens eine Oberklasse (oder Interface) (benannt mit zB. "Viereck") für beide mit Funktion wie "Draw()", "GetLength()" oder "SetWidth()" zur Wiederverwendung von Code erstellen. Ich hab diese Meinung zur Kenntnis genommen, bin aber nicht wirklich damit einverstanden. Punkte habe ich dann trotzdem keine bekommen *g*!

[Tormentor32]

Dann hätte ich es so gemacht

Delphi-Quellcode:

TGeometrischeForm = class
  TViereck= class(TGeometrischeForm)
    TRechteck = class(TViereck)
      TQuadrat = class(TRechteck)
    TParallelogramm = class(TViereck)

//usw

[Hansa]

Hätte es auch zuerst so gemacht : Rechteck -> Quadrat. Hätte ich den Code allerdings geschrieben, dann wäre schon aufgefallen, dass das Institut Recht hat ! Ein Quadrat ist zwar schon ein spezielles Rechteck, aber das braucht (anders als das Rechteck) keine zwei Seitenlängenangaben, sondern nur eine !! Es ist also unnötig für das Quadrat eine geerbte überflüssige Seite mitzuschleppen.

Also so hätte ich das gemacht : TViereck -> TRechtwinkliges Viereck.

Das nächste wäre eine Verzweigung :

Delphi-Quellcode:

TRechteck = Class (TRechtwinkligesViereck)
  SeitenlaengeA,
  SeitelaengeB :...

TQuadrat = Class (TRechtwinkligesViereck)
  SeiteLaenge,

Wenn man sich das nämlich mal weiter überlegt : beim Quadrat brauche ich für Fläche lediglich sqr. Beim Rechteck aber SeitenLaengeA * SeitenLaengeB. Umfang usw. geht in ähnliche Richtung. Das läuft also doch viel weiter auseinder, als man im ersten Moment denkt.

[Muetze1]

Ja und? Bei einem gleichschenkligen Dreieck bräuchte ich auch nur 2 Seitenangaben und schon kann ich alles was ich von TDreieck erben könnte nicht mehr nutzen, da ich nicht mehr davon ableiten darf? Hallo?

Bei einem gleichseitigen Dreieck darf ich dann alles nochmals implementieren, was ich beim Dreieck und beim gleichschenkligen Dreieck schon implementiert habe? Wozu?

Grundlegend: Die Routinen von TRechteck und vom allgemeinen Dreieck gelten und funktionieren genauso bei den anderen Fällen. Es ist nur eine Vereinfachung in Form a = b hinzu gekommen, aber das ändert nichts an den Formeln - die werden dadurch nicht falsch.

Warum sollte ich also z.B. die Formeln 3 mal implementieren (Beispiel Dreieck bzw. 2x Beispiel Rechteck) anstatt die vorhandenen zu nutzen?

Und dein Argument ist keins: Die Seiten können auch protected deklariert werden und erst mit der richtigen Endform veröffentlicht werden.

[Hansa]

Muetze, wie das in der Praxis aussieht ist eine ganz andere Sache. Es gibt nicht überall protected, override usw. Ob der jeweilige Linker in der Lage ist, alles überflüssige wirklich restlos zu entfernen, wer weiß ? Gehe jedenfalls davon aus, daß die richtige Sparte gewählt wurde und die ist eben in diesem Fall nicht "Object Pascal".

[Muetze1]

Zitat:

Zitat von Hansa

Es gibt nicht überall protected, override usw.

Es wurde nach OO Programmierung gefragt und zum OO Sprachumfang gehört nunmal ein gewisser Satz an OO Mitteln.

Zitat:

Zitat von Hansa

Ob der jeweilige Linker in der Lage ist, alles überflüssige wirklich restlos zu entfernen, wer weiß ?

Was hat dies mit dem anderen zu tun?

[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.