Zitat von
Cyf:
Vielleicht liegt das jetzt an meinen Geschmack und die
OOP-Fetischisten werden mich jetzt steinigen
, aber ist zur Verwaltung von Bäumen nicht eine Klasse, die einen Zeiger auf den Root kapselt und als Aufbau des Baums Records die aufeinander Zeiger enthalten sinnvoller? Bei der Benutzung von außen (außerhalb dieser Klasse) hat man dann trotzdem nur mit einem schönen Interface der Klasse zu kämpfen, während sie innen organisiert sein kann, wie sie will, und innen erspart man sich den nicht unbeträchlichen Overhead, für jedes Element ein Objekt zu erzeugen.
Okay, ich steinige dann mal
Erstens: Ja, kannst du so machen -
OOP beinhaltet auch Kapselung
Im Grunde kannst du also in der Baum-Klasse machen was du willst, solange ich das Teil problemlos benutzen kann.
Allerdings wird es etwas komplizierter sein, die Baumstruktur mit den records zu schreiben da man ja an alle initialisierungen und konsistenzprüfungen denken muss.
Btw.: Ich würde gerne mal den "nicht unbeträchlichen Overhead für jedes Element ein Objekt zu erzeugen" sehen - wenn ich richtig informiert bin, stehen die Methoden der Klasse sowiso im Speicher herum. Wenn ein Objekt dann angelegt wird, passiert doch eigenlich nichts weiter, als dass ein Speicherbereich reserviert wird, in den dann der Self-Pointer, die Felder und vll. n paar Typinformationen reinkommen. Kommt dann natürlich noch drauf an, was im Konstruktor passiert.
Ist jetzt nicht bös gemeint oder so, aber ich wollte nur mal meinen Senf dazugeben
(Nein, es ist nicht der mittelscharfe von Develei ^^)