Klassenhierarchie mit Mehrfachvererbung

[Java Oo]

Nabend,
ich soll in mit eclipse ein Java Programm schreiben welches wie folgt aufgebaut werden soll:


- Definieren Sie für folgende Klassen die Klassenhierarchie:
Viereck, konvexes Viereck, Trapez, Parallelogramm, Rhombus,
Rechteck, Quadrat
- Erzeugen Sie von allen Klassen eine Instanz, wenn dies möglich ist.
- Definieren Sie in allen Klassen sinnvolle Methoden und Attribute.
- Überladen und überlagern Sie Methoden.
- Schreiben Sie sinnvolle Konstruktoren für alle Klassen.
- Setzen Sie sinnvoll die Modifizierer abstract, static, final, public,
protected und private ein.


Da ich leider keine Mehrfachvererbung benutzen kann habe ich Interface-Klassen erstellt.
Der code sieht jetzt so aus und ich habe keine Idee wie ich weiter machen soll....

public abstract class Klassenhierachie {
	

	public interface Viereck 
	{
	 
		public void methode();
		
		 
	 
	}

	public interface KonvexesViereck extends Viereck 
	{
	  public void methode();
	  
	}
	
	interface Trapez extends KonvexesViereck
	{
	  public void methode();
	}
	
	interface Parallelogramm extends Trapez
	{
	  public void methode();
	}
	
	interface Rhombus extends Parallelogramm
	{
	  public void methode();
	}
	
	interface Rechteck extends Parallelogramm
	{
	  public void methode();
	}
	

	public abstract class Quadrat implements Rhombus, Rechteck 
	{
	  public void methode()
	  {
	     System.out.println("Wir sind in der Subklasse");
	  }
	}
	
	
	
}

 

[Marco13]

Methoden? Fläche und Umfang. Oder worum geht's?

 

[Java Oo]

Ja, die Aufgabenstellung ist sehr Schwammig....

Wenn ich die Aufgabe richtig verstehe soll ich dem Viereck z.b. erstmal zuweisen das es ein Viereck ist und das es Vier-Ecken hat, oder das die Winkel alle 90° sind...
Und dann durch Vererbung auf dem nächsten in der Hierarchie übertragen, und wenn dann nicht alles überein stimmt überschreiben oder überlagern damit die Angaben für jedes Viereck stimmen.

Mein Hauptproblem dabei ist, dass ich nicht mit dem interface klar komme, aber ich weiß sonst nicht wie ich die Doppeltvererbung von Rhombus und Rechteck auf Quadrat machen soll.

 

[Marco13]

Na das mit den Interfaces ist schon OK so. Ob die Aufgabenstellung nun "schwammig" oder "frei" ist, weiß ich nicht. Du könntest die besagten Funktionen einbauen, oder sowas an die Hierarchie angelehntes wie "istQuadrat()" oder "hatNurRechteWinkel()" - macht zwar IMHO keinen Sinn, aber ... :bahnhof:

 

[Andi_CH]

Mein Hauptproblem dabei ist, dass ich nicht mit dem Interface klar komme, aber ich weiß sonst nicht wie ich die Doppeltvererbung von Rhombus und Rechteck auf Quadrat machen soll.

Warum soll ein Quadrat ein Rhombus und ein Rechteck sein?

Vererbung wird gelesen als "ist ein"
Du sagst ein Quadrat "ist ein" Rhombus. Das stimmt schlicht nicht.
Ein Quadrat "ist ein" Rechteck kann ich gelten lassen obwohl vor einige Tagen genau das Gegenteil behauptet wurde. (Wer hat da vor Kurzem über Liskov reveriert? Jetzt wärst du gefragt ....)

"Parallelogramm extends Trapez" ist genau so abenteuerlich. Ein Parallelogramm hat parallele Seiten, ein Trapez nicht.

1. Eine Methode die methode heisst ist schon mal überflüssig!
2. Vorgehen: Zuerst (auf Papier!) überlegen welche Klasse welche Eigenschaften hat (Attribute und Methoden)
3. Gemeinsame Eigenschaften in Vaterklassen auslagern und Vererbungen definieren.
(Du wirst wunderbar mit einfachen Vererbungen auskommen.)


So nebenbei, was ist ein konvexes Viereck? Ich dachte von konvex und konkav kann man erst bei komplizierteren Figuren sprechen?

Als Starthilfe im Zusammenhang mit Interfaces mache ich folgenden Vorschlag:

public interface Viereck {
	public double flaeche();
}

public class Quadrat implements Viereck {

	private double mSeitenlaenge = 0.0;

	public void setSeitenlänge(double pSeitenlaenge) {
		mSeitenlaenge = pSeitenlaenge;
	}

	@Override
	public final double flaeche() {
		return mSeitenlaenge*mSeitenlaenge;
	}
}

Wobei ich weder behaupte, dass das optimal ist, noch dass es vollständig ist ....

 

[Rautenmensch]

Du sagst ein Quadrat "ist ein" Rhombus. Das stimmt schlicht nicht.

Wieso? Ein Rhombus ist ein Viereck mit 4 gleich langen Seiten. Ein Quadrat ebenso.

 

[Andi_CH]

Ein Quadrat hat per Definition 90 Grad Winkel - ein Rhombus nicht.

Du musst immer in der Realität denken - wie sieht der Mathematiker das.
Der wird dir als erstes sagen, dass ein Rhombus weder ein Quadrat noch ein Rechteck ist (Sonst hätte man den Begriff "Rhombus" gar nicht erst eingeführt.

Das Einzige das alle gemeinsam haben sind vier Ecken - also sind alles Vierecke
--
(Warum finde ich es wohl schei..... wenn man nicht erst UML und Design lernt sonder gleich mit einer Programmiersprache beginnt?)

 

[tfa]

Ein Quadrat hat per Definition 90 Grad Winkel - ein Rhombus nicht.

Ein Rhombus kann natürlich auch 90° Winkel haben und dadurch zum Quadrat werden.
Ebenso kann ein Rechteck vier gleich lange Seiten haben und dadurch zum Quadrat werden.
Oder ein Parallelogramm mit 90° Winkeln ist ein Rechteck -- vielleicht sogar ein Quadrat oder eine Raute, auf jeden Fall aber ein Trapez.
Ist das so schwer?

Der wird dir als erstes sagen, dass ein Rhombus weder ein Quadrat noch ein Rechteck ist (Sonst hätte man den Begriff "Rhombus" gar nicht erst eingeführt.

Das ist Unsinn.
Ein Vorschlag zur Nachtlektüre:

Raute ? Wikipedia
Quadrat (Geometrie) ? Wikipedia

Kleine Zusammenfassung: Ein Quadrat ist ein Rechteck ist ein Parallelogramm ist ein Trapez ist ein Viereck.
Das gilt in der Geometrie - aber nicht unbedingt für eine Klassenhierarchie.

 

[Marco13]

@Andi_CH: So viel Selbstsicherheit ... ... ... :reflect: Beeindruckend

Kleine Zusammenfassung: Ein Quadrat ist ein Rechteck ist ein Parallelogramm ist ein Trapez ist ein Viereck.
Das gilt in der Geometrie - aber nicht unbedingt für eine Klassenhierarchie.

Das letzte ist ein wichtiger Punkt. Die besagte Hierarchie kann man ohnehin nicht "verständlich und lehrreich" umsetzen, ohne sich in philosophische Diskussionen zu verstricken, und vermutlich auch nicht, ohne Fräulein Liskov zum Weinen zu bringen.

 

[henpara]

für alle, die sich unter konvexes viereck nix vorstellen können.
(konvex heißt, die Diagonalen verlaufen innerhalb der Fläche)
Ich bin auch der Meinung, daß man mit einfacher Vererbung hier schon sehr weit kommt.

 

[Andi_CH]

Siehe hier und hier Ich war auch mal anderer Meinung, aber wenn man "is a" oder halt deutsch "ist ein" anwendet, merkt man, dass es irgendwie nicht aufgeht.

Folgendes gilt ja wohl:

Ein viereck bei dem folgendes gilt
Alle Seiten gleich lang, 90 Grad Winkel -> eineindeutig Quadrat
Alle Seiten gleich lang, 0 Grad < Winkel < 90 Grad -> eineindeutig Rhombus
Seiten paarweise gleich lang, Winkel 90 Grad -> eineindeutig Rechteck
Seiten paarweise gleich lang, 0 Grad < Winkel < 90 Grad -> 0 Grad < Winkel < 90 Grad -> eineindeutig Parallelogramm

etc.

Also wenn jetzt jemand kommt und sagt Quadrat erbt von Rechteck, erbt es auch die Eigenschaft, dass es unterschiedlich lange Seiten hat, was nicht stimmt.
Quadrat ist ein Rechteck? In jedem aller Fälle? Nein!

Umgekehrt: Wenn Rechteck von Quadrat erben würde, dann würde das Rechteck die Eigenschaft erben, dass alle Seiten gleich lang sind, was genau so wenig stimmt.
Rechteck ist ein Quadrat? na ja! Nein!

Hilfe, hat ThreadPool heute Ferien?

 

[Marco13]

Diese "Eineindeutigkeit" trifft nicht zu (das ist auch ein ziemlich streng definierter Begriff)


Alle Seiten gleich lang, 90 Grad Winkel -> eineindeutig Quadrat
...
Seiten paarweise gleich lang, Winkel 90 Grad -> eineindeutig Rechteck

etc.

Also wenn jetzt jemand kommt und sagt Quadrat erbt von Rechteck, erbt es auch die Eigenschaft, dass es unterschiedlich lange Seiten hat, was nicht stimmt.
Quadrat ist ein Rechteck? In jedem aller Fälle? Nein!


Die Definition eines Rechtecks ist ja nicht
"Ein Viereck ist ein Rechteck, (wenn es nur Winkel 90° und paarweise gleichlange Seiten hat und die Seiten NICHT alle gleichlang sind)"
sondern
"Ein Viereck ist ein Rechteck, (wenn es nur Winkel 90° und paarweise gleichlange Seiten hat)"

Vielleicht kann man sich das durch einige if-Abfragen (die ich ganz oben schon angedeutet hatte) verdeutlichen: Je weiter man in der Vererbungshierarchie nach unten kommt, umso mehr Eigenschaften müssen erfüllt sein. (Nochmal: Das passt alles nicht mit Liskov zusammen, nur vom Grundgedanken her)

if (alleWinkel90Grad) istRechteck = true;
if (alleWinkel90Grad && alleSeitenGleichLang) istQuadrat = true;

Man wird es also nicht schaffen, etwas zu basteln, das nur ein Quadrat, aber kein Rechteck ist.

 

[tfa]

Also wenn jetzt jemand kommt und sagt Quadrat erbt von Rechteck, erbt es auch die Eigenschaft, dass es unterschiedlich lange Seiten hat, was nicht stimmt.
Quadrat ist ein Rechteck? In jedem aller Fälle? Nein!

...was das Klassenmodell angeht. Schön. Du hast es endlich verstanden.

Trotzdem war dein Beitrag hier wohl eher auf die Geometrie bezogen (jedenfalls schriebst du was von Mathematikern). Und das ist und bleibt Unsinn.
Also: Geometrie und OOD sind sich hier nicht einig.

 

[Marco13]

Das kommt drauf an. Geometrie und OOP können sich schon einig sein, es kommt darauf an, was man modelliert. Wenn man es auf den einfachen Fall von Quadrat und Rechteck bezieht:

class Rectangle {
    float getWidth() { ... }
    float getHeight() { ... }
    void scaleHeight(float factor) { ... }
}
class Square extends Rectangle { }

Das sieht auf den ersten Blick vielleicht "OK" aus, aber Liskov macht einem einen Strich durch die Rechnung

void demo()
{
    Square s = new Square(10,10);
    Rectangle r = s;
    r.scaleHeight(0.5);
    if (r.getWidth() != 10 || r.getHeight() != 5)
    {
        throw SomethingWrongException("scaleHeight did not work as expected");
    }
    if (s.getWidth() != s.getHeight()) 
    {
        throw SomethingWrongException("Square is no square");
    }
}

An einer der beiden Stellen muss eine Exception fliegen.


Wenn man diese "Verhaltensaspekte" aber gar nicht modellieren will, sondern nur die (jetzt NOCH weiter) oben schon angedeuteten, pragmatischen (und sehr an den Mathematischen Gegebenheiten ausgerichteten) Methoden anbieten will, spricht nichts dagegen, GANZ GROB sowas zu machen wie

class Rectangle 
{
    int w,h;
    boolean hasOnlyRightAngles() { return true; }
    boolean allSidesSameLength() { return w==h; }    
}
class Square extends Rectangle 
{ 
    @Override
    boolean allSidesSameLength() { return true; }    
}

 

[Andi_CH]

Warum hängt ihr Vererbung immer am Code auf? Das oben sind mathematische Definitionen und das "eineindeutig" ist kein Tippfehler ;-) Mathematische Definitionen sind "hoffentlich!) immer sehr hart.

Egal - wenn ThreadPool hier nichts dazu sagt, schweige ich auch, ich kann einfach nicht so gut argumentieren wie er.


Als Codiermonster würde ich wohl folgendes machen:

Viereck: Interface mit Methodendefinitionen -> alle Vierecke implentieren das
Quadrat: Attribut Seitenlänge
Rechteck: erbt von Quadrat und hat zusätzlich eine Seitenlänge
Trapez: erbt von Quadrat und hat noch eine Seitenlänge
Rhombus erbt von Quadrat und hat noch ein Attribut Winkel
.........

-> Aber da wird jeder Mathematiker und ThreadPool sicher ganz grün im Gesicht ;-)

 

[tfa]

Hm, die passende Umfrage zu dieser Sache feiert am Sonntag ihren dritten Geburtstag.
Leider ist sie schon geschlossen

 

[Andi_CH]

Ach und das soll der Weisheit letzter Schluss sein? :noe: Ich würde diese Frage sehr gerne mit SW-Engineering Leuten, von denen es hier eher wenige hat, diskutieren. Leider ist mir kein entsprechendes Forum bekannt.

Es ist wohl besser zusagen:
no further comment

 

[maki]

Ach und das soll der Weisheit letzter Schluss sein? :noe: Ich würde diese Frage sehr gerne mit SW-Engineering Leuten, von denen es hier eher wenige hat, diskutieren. Leider ist mir kein entsprechendes Forum bekannt.

Es ist wohl besser zusagen:
no further comment

Genau wegen solchen Aussagen brauchst du dich nicht wundern wenn hier regelmässig eine auf den Deckel bekommst.

 

[Andi_CH]

Wenn niemand konstruktiv (konstruktiv mit Angaben von Gründen) weiterdiskutieren will breche ich ab.

Ich weiss dass ich jedes mal eines auf den Deckel bekommen wenn ich sage worin ich Erfahrung habe und was ich kann - es währe SEHR gut wenn das die anderen auch machen würden. (ins Profil kann man es ja nicht schreiben) So könnte man die Aussagen gewichten. Es gibt hier nun mal Leute zwischen 0 und 100

So und nun breche ich halt mein Prinzip - ich habe oben begründet warum aus mathematischer Sicht die Vererbung nicht stimmt. (So betrachtet man etwas am Anfang - OO soll ja die reale Welt wiedergeben)

Die implementatorische Betrachtungsweise habe ich auch noch angeführt - auch dort habe ich begründet warum die Hierarchie so sein muss wie dargestellt.

Ich argumentiere und bitte darum, nicht einfach das Gegenteil ohne Gegenargumente in den Raum zu stellen - das währe professionelle Vorgehensweise

dann relativiere ich es halt:

ohne Argumente braucht keinen weitern Kommentar von mir.

 

[henpara]

Also wenn ich Vererbung richtig kapiert habe, werden damit Untermengen von allgemeineren Mengen dargestellt, daher auch immer das viel verwendete Beispiel: Klasse Auto, Klasse Sportauto extends Auto (jedes Sportauto ist auch ein Auto)

Hier angewendet gilt also: Klasse Viereck, Klasse Rechteck extrends Viereck, Klasse Trapez extends Viereck usw.
wobei eben das Problem besteht, daß ein Quadrat auf mehrere Objekte zutrifft, also müsste es dann ja sein: Quadrat extends Viereck extends Rechteck extends Trapez usw. usf., was wohl Java-technisch nicht vorgesehen ist.

Immerhin kann man schon sagen, daß alle unterklassen von Viereck erben, da nunmal alles Vierecke sind. Wie man die dann am besten untereinander verbandelt überlass ich den Profis

btw. schönes Wochenende

 

[Gast2]

So und nun breche ich halt mein Prinzip - ich habe oben begründet warum aus mathematischer Sicht die Vererbung nicht stimmt. (So betrachtet man etwas am Anfang - OO soll ja die reale Welt wiedergeben)

Die mathematische Definiton sagt:

Das Quadrat ist ein Sonderfall des Parallelogramms und des Trapezes, es ist sowohl Rechteck als auch Rhombus (Raute).

http://www.mathematische-basteleien.de/viereck14.gif
http://www.mathematische-basteleien.de/viereck23.gif

Dann mal viel Spaß beim modelieren...

 

[maki]

Wenn niemand konstruktiv (konstruktiv mit Angaben von Gründen) weiterdiskutieren will breche ich ab.

Die Gründe hat man dir doch genannt, ein ganzer Thread voller für und wider.

Ich weiss dass ich jedes mal eines auf den Deckel bekommen wenn ich sage worin ich Erfahrung habe und was ich kann - es währe SEHR gut wenn das die anderen auch machen würden. (ins Profil kann man es ja nicht schreiben) So könnte man die Aussagen gewichten. Es gibt hier nun mal Leute zwischen 0 und 100

Du bekommst regelmässig eine auf den Deckel wenn du dich einerseits Argumenten verschliesst und dann andererseits gleich die Kompetenz aller deiner Gesprächspartner in Frage stellst, während du selber deine Argumente weder belegen kannst noch in der Lage bist zu erkennen (wollen?) wenn du falsch liegst.
Was du kannst und nicht was wird sehr deutlich wenn man deine Beträge liest.

So und nun breche ich halt mein Prinzip - ich habe oben begründet warum aus mathematischer Sicht die Vererbung nicht stimmt. (So betrachtet man etwas am Anfang - OO soll ja die reale Welt wiedergeben)

Mathematisch betrachtet liegst du falsch, was OO angeht auch - wir abstrahieren die Wirklichkeit, genau darum geht es beim "modellieren".

Die implementatorische Betrachtungsweise habe ich auch noch angeführt - auch dort habe ich begründet warum die Hierarchie so sein muss wie dargestellt.

Ich argumentiere und bitte darum, nicht einfach das Gegenteil ohne Gegenargumente in den Raum zu stellen - das währe professionelle Vorgehensweise

Deine Argumente waren eben weder stichhaltig noch nachvollziehbar, stattdessen faselst du wieder irgendwas von "hier gibt es keine SW Ingenieure" und tuest so als ob du mehr wüsstest als der Rest, und zwar immer dann, wenn du nicht mehr weiter weist aber auch nicht zugeben möchtest dass du dich geirrt haben könntest bzw. dass du eigentlich gar keine Ahnung hast von dem was du da erzählst.

Alles in allem eine schwache Vorstellung.

 

[tfa]

Den Threadstarter haben wir jetzt wohl abgeschreckt. Schade. Mich hätte mal die Musterlösung interessiert.
Hier ein Vorschlag, der völlig an der Aufgabenstellung vorbei geht:

public class Viereck {

	private Point2D a;
	private Point2D b;
	private Point2D c;
	private Point2D d;

	public Viereck(Point2D a, Point2D b, Point2D c, Point2D d) {
		this.a = a;
		this.b = b;
		this.c = c;
		this.d = d;
	}

	public boolean isKonvex() {
		return ...;
	}

	public boolean isTrapez() {
		return ...;
	}

	public boolean isParallelogramm() {
		return ...;
	}

	public boolean isRhombus() {
		return ...;
	}

	public boolean isRechteck() {
		return ...;
	}

	public boolean isQuadrat() {
		return ...;		  
	}

Das wurde in Beitrag #4 schon angedacht.
Jetzt muss nur noch jemand die Methoden schreiben.