Vererbungshirachie Graph

Status
Nicht offen für weitere Antworten.

JanDMC

Mitglied
Hey Leute,

Ich will eine durch und durch objektorientierte Vererbungshierachi für einen Graphen anlegen. Folgende Klasse sollen enthalten sein;

- abstract Graph
- ungerichteter Graph extends Graph
- gerichteter Graph extends Graph
- abstract Baum extends gerichteter Graph
- Binaerbaum extends Baum
- AVL Baum extends Baum


Meine Fragen hierzu sind: Ist es korrekt die Klasse Baum ebenfalls abstract zu machen, denn meiner Meinung gibt es keinen allgemeinen Baum den man implementieren könnte, es muss schon festgelegt werden ob es ein z.b leerer Baum , Binärbaum oder Ternärbaum ist.

Wie ist eure Meinung dazu.

mfg

Jan
 

0x7F800000

Top Contributor
Naja, viel hast du nicht geschrieben, damit man dazu irgendwas sagen könnte... Interfaces werden ja auch nicht durch den Namen, sondern durch die Funktionalität definiert (ich sag "Interfaces", weil ich nicht verstehe, wozu "Baum" eine abstrakte Klasse sein soll: welche Funktionalität soll sich denn für alle Bäume gleichartig umsetzen lassen? Naja, vielleicht ein paar suchalgorithmen oder so...) Erzähl mal mehr, was du mit den ganzen sachen vorhast, wie gesagt, dass die Reihenfolge der Namen stimmt ist ja auch so klar.
 

JanDMC

Mitglied
Hey

Die Aufgabe wurde absichtlich nicht eindeutig gestellt, ich soll ein eine komplett objektorientierte Graph-Hierachi aufbauen und implementieren. Klassen die genannt wurden, waren halt AVLBaum und Binärbaum ... beides sind logischerweise Bäume und Bäume sind gerichtete Graphen. Um einem Baum zu erstellen benötigt man somit eine Klasse GerichteterGraph und da ein gerichteter Graph schon eine spezialisierung ist generalisier ich das und erstelle vorher eine Klasse Graph.
Das Ziel wird es sein, wovon ich ausgehe, dass es möglich sein soll einen Binärbaum/AVLBaum instantzieren zu können und Knoten eingefügt , gelöscht werden sollen. Außerdem soll ebenfalls travasiert werden können (pre-,post- und inOrder).

Um auf meine eigentliche Frage zurückzukommen, bin ich mir halt nich sicher ob es einen "normalen" Baum gibt oder dieser ebenfalls als abstract gesehen werden kann, weil einen Baum gibt es nicht, höchstens eine spezialisierte Form.

hoffe das Hilft bei der Antwort ein wenig, sonst einfach weiter fragen =)



danke

mfg Jan

//Edit

Ich habe gerade noch die Information erhalten, dass ich anhand dieses Programms polymorphismus erklären soll. d.h die komplette implemenataion ist nicht nötig nur einige Beispiele wie traversieren ( mit hilfe eines interfaces) ....
jan
 

0x7F800000

Top Contributor
JanDMC hat gesagt.:
Um auf meine eigentliche Frage zurückzukommen, bin ich mir halt nich sicher ob es einen "normalen" Baum gibt oder dieser ebenfalls als abstract gesehen werden kann, weil einen Baum gibt es nicht, höchstens eine spezialisierte Form.
Aj, zum beispiel die blinde Suche würde man bereits auf allen graphen gleich implementieren, wenn du dir etwa die tiefensuche anschaust... daher würde es sich schon lohnen, einen abstrakten graphen zu machen, und es nicht nur bei einer interface zu lassen. daher muss ein baum bereits zwangsläufig mindestens eine abstrakte klasse sein. Eine konkrete Klasse kann das auch nicht sein, da es eben zu allgemein ist... Also muss es abstrakt sein.
 

Marco13

Top Contributor
Ich würde die Datenstrukturen an Ssich komplett als Interfaces schreiben. Und dann eben ggf. das obligatorische
interface Tree extends ...
class AbstractTree implements Tree
class DefaultTree extends AbstractTree

Aber nur so nebenbei: Das wird so einige Schwierigkeiten mit der Erfüllung des Liskov'schen Substitutionprinzips geben

- gerichteter Graph extends Graph
- abstract Baum extends gerichteter Graph

Ein gerichteter Graph wird dadurch zum Baum, dass er zyklenfrei ist. Wie soll man das in die Vererbungshierarchie reindrücken?
Code:
void addCycle(DirectedGraph graph)
{
    addNodesAndEdgesThatFormTheCycleTo(graph);
}

void knirsch()
{
    Tree tree = new Tree();
    addCycle(tree); // Syntaktisch OK, aber was pssiert hier?
}
Eigentlich müßte (oder sollte?) man Tree nicht als eigene Klasse machen. Stattdessen könnte DirectedGraph eine Methode haben "boolean isTree()", die nach Zyklen sucht...

Wenn es nur darum geht, daran Polymorphie zu erklären, könnte man sagen, dass das egal ist - aber vielleicht ist es ja gerade deswegen wichtig?! Mit Polymorphie kann man sich ziemlich leicht in den Fuß schießen, wenn man nicht berücksichtigt, dass sie auch bestimmte Anforderungen an das Verhalten stellt....
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen

Neue Themen


Oben