Mahlzeit
Ich will eine Baumstruktur erstellen, und habe dafür eine abstrakte Klasse TreeItem geschrieben. Ein TreeItem kennt seinen Parent und seine Children und seine UUID. Vom Parent kann es ein Address-Objekt (das ist im wesentlichen eine ArrayList<UUID> mit allen UUIDs von der Baumwurzel bis zum Ziel-Child) anfordern, diese Anforderung wird nach oben bis zur Baumwurzel weitergereicht und über ein Dekoratormuster wird ein Address-Objekt ab der Baumwurzel gebaut und zum Aufrufer durchgereicht.
So können jetzt neue Child-Objekte hinzugefügt, existierende zurückgegeben oder entfernt werden, indem das lediglich das Wurzel-TreeItem mit einem Address-Objekt aufgerufen wird.
Das funktioniert soweit sehr gut.
Jetzt möchte ich ein Modell des Baums erstellen, um nicht jedesmal den gesamten Baum bzw. das gesamte TreeItem herumreichen muß, wenn ich z.B. lediglich die Namen der TreeItems in einer Baumstruktur anzeigen lassen will. Außerdem ist die Baumstruktur von außen nicht ersichtlich. da der Baum ja nur über das Wurzel-Element über ein Address-Objekt benutzt werden soll-und dieses Address-Objekt braucht man ja erstmal.
Jetzt ist mein Plan, eine (abstrakte) Klasse TreeItemModel zu schreiben. Ein TreeItemModel soll seinen Parent (bzw. den Parent des "Origials" im Baum) kennen und ein aktuelles Address-Objekt enthalten. Vielleicht soll es auch die Children kennen, ich weiß aber noch nicht ob ich das brauche.
Am Ende gebe ich eine ArrayList<TreeItemModel> aus, die alle TreeItemModels des Baums enthält. Da jedes TreeItemModel ein Address-Objekt hat und es das TreeItemModel des Parents kennt, kann ich die Baumstruktur in einer einfachen Schleife wiederherstellen.
TreeItem ist abstrakt, weil diese Klasse eine Fähigkeit bereitstellen soll. Ich hätte es lieber über ein Interface gelöst, aber mit einem Interface kann man keine Befähigung umsetzen da Interfaces keine Instanzvariablen aufnehmen können. Aber ein TreeItem nur um des TreeItems willen nutzt noch nichts, da soll noch mehr rein um es nutzen zu können.
Daher ist auch TreeItemModel abstrakt. Diese Klasse soll ja einerseits die Nachvervolkbarkeit der TreeItems bereitstellen, andererseits auch als Nutzdatencontainer dienen.
Jetzt überlege ich, wie ich das am Besten umsetze. Ich weiß jetzt noch nicht, wieviele und welche TreeItems es mal geben wird und welche Daten ich dann haben will.
Ich hab schon überlegt, das TreeItemModel nicht abstrakt zu machen und dem TreeItem dafür noch eine abstrakte Methode mitzugeben. Diese dient dazu, eine HashMap aller gewünschten Eigenschaften zurückzugeben. Mit einer Methode wie "Object getSomeProperty(String propertyname)" würde ich die Werte dann aus dem TreeItemModel rausholen.
Diese Lösung gefällt mir jedoch nicht. Ich habe diese Methode nur einmal, und müßte diese jedesmal erweitern wenn ich dann doch einmal andere Daten brauche. Und dann schleppe ich jedesmal ALLE Daten umher die irgednwann irgendwie mal gebraucht werden könnten -> schlechte Kapselung.
Am liebsten wäre mir, für einen konkreten Anwendungsfall eine Klasse zu schreiben, die von der Klasse TreeItemModel erbt und der ich, je nach Wunsch, die Nutzdaten mitgeben kann die ich jeweils haben will. Und hier fangen die Probleme an.
1. Wie kriege ich ein TreeItem-Objekt dazu, nach Wunsch ein TreeItemModelABC oder ein TreeItemModelXYZ zurückzuliefern? Über eine Enum als Methodenparameter wäre vielleicht eine Möglichkeit, aber so richtig gefällt mir die Idee nicht.
2. Besser wäre, dem TreeItemModel das Original im Konstruktor bekannt zu machen. Aber da stellt sich die Frage: Woher kann ein TreeItem wissen, ob es ein TreeItemAnton oder ein TreeItemBerta ist? Und wenn ich nachher ein ArrayList<TreeItemModel> habe: wie kriege ich möglichst einfach (also ohne Reflections-Brechstange oder Castorgie) raus, ob list.get(5) dann ein TreeModelAnton oder ein TreeModelBerta zurückliefert? Ich hab überlegt ob da nicht was mit Generics zu machen wäre.
Hat jemand eine Idee (vielleicht auch einen komplett anderen Ansatz), wie ich da am Besten zu einer guten Lösung komme?
Ich will eine Baumstruktur erstellen, und habe dafür eine abstrakte Klasse TreeItem geschrieben. Ein TreeItem kennt seinen Parent und seine Children und seine UUID. Vom Parent kann es ein Address-Objekt (das ist im wesentlichen eine ArrayList<UUID> mit allen UUIDs von der Baumwurzel bis zum Ziel-Child) anfordern, diese Anforderung wird nach oben bis zur Baumwurzel weitergereicht und über ein Dekoratormuster wird ein Address-Objekt ab der Baumwurzel gebaut und zum Aufrufer durchgereicht.
So können jetzt neue Child-Objekte hinzugefügt, existierende zurückgegeben oder entfernt werden, indem das lediglich das Wurzel-TreeItem mit einem Address-Objekt aufgerufen wird.
Das funktioniert soweit sehr gut.
Jetzt möchte ich ein Modell des Baums erstellen, um nicht jedesmal den gesamten Baum bzw. das gesamte TreeItem herumreichen muß, wenn ich z.B. lediglich die Namen der TreeItems in einer Baumstruktur anzeigen lassen will. Außerdem ist die Baumstruktur von außen nicht ersichtlich. da der Baum ja nur über das Wurzel-Element über ein Address-Objekt benutzt werden soll-und dieses Address-Objekt braucht man ja erstmal.
Jetzt ist mein Plan, eine (abstrakte) Klasse TreeItemModel zu schreiben. Ein TreeItemModel soll seinen Parent (bzw. den Parent des "Origials" im Baum) kennen und ein aktuelles Address-Objekt enthalten. Vielleicht soll es auch die Children kennen, ich weiß aber noch nicht ob ich das brauche.
Am Ende gebe ich eine ArrayList<TreeItemModel> aus, die alle TreeItemModels des Baums enthält. Da jedes TreeItemModel ein Address-Objekt hat und es das TreeItemModel des Parents kennt, kann ich die Baumstruktur in einer einfachen Schleife wiederherstellen.
TreeItem ist abstrakt, weil diese Klasse eine Fähigkeit bereitstellen soll. Ich hätte es lieber über ein Interface gelöst, aber mit einem Interface kann man keine Befähigung umsetzen da Interfaces keine Instanzvariablen aufnehmen können. Aber ein TreeItem nur um des TreeItems willen nutzt noch nichts, da soll noch mehr rein um es nutzen zu können.
Daher ist auch TreeItemModel abstrakt. Diese Klasse soll ja einerseits die Nachvervolkbarkeit der TreeItems bereitstellen, andererseits auch als Nutzdatencontainer dienen.
Jetzt überlege ich, wie ich das am Besten umsetze. Ich weiß jetzt noch nicht, wieviele und welche TreeItems es mal geben wird und welche Daten ich dann haben will.
Ich hab schon überlegt, das TreeItemModel nicht abstrakt zu machen und dem TreeItem dafür noch eine abstrakte Methode mitzugeben. Diese dient dazu, eine HashMap aller gewünschten Eigenschaften zurückzugeben. Mit einer Methode wie "Object getSomeProperty(String propertyname)" würde ich die Werte dann aus dem TreeItemModel rausholen.
Diese Lösung gefällt mir jedoch nicht. Ich habe diese Methode nur einmal, und müßte diese jedesmal erweitern wenn ich dann doch einmal andere Daten brauche. Und dann schleppe ich jedesmal ALLE Daten umher die irgednwann irgendwie mal gebraucht werden könnten -> schlechte Kapselung.
Am liebsten wäre mir, für einen konkreten Anwendungsfall eine Klasse zu schreiben, die von der Klasse TreeItemModel erbt und der ich, je nach Wunsch, die Nutzdaten mitgeben kann die ich jeweils haben will. Und hier fangen die Probleme an.
1. Wie kriege ich ein TreeItem-Objekt dazu, nach Wunsch ein TreeItemModelABC oder ein TreeItemModelXYZ zurückzuliefern? Über eine Enum als Methodenparameter wäre vielleicht eine Möglichkeit, aber so richtig gefällt mir die Idee nicht.
2. Besser wäre, dem TreeItemModel das Original im Konstruktor bekannt zu machen. Aber da stellt sich die Frage: Woher kann ein TreeItem wissen, ob es ein TreeItemAnton oder ein TreeItemBerta ist? Und wenn ich nachher ein ArrayList<TreeItemModel> habe: wie kriege ich möglichst einfach (also ohne Reflections-Brechstange oder Castorgie) raus, ob list.get(5) dann ein TreeModelAnton oder ein TreeModelBerta zurückliefert? Ich hab überlegt ob da nicht was mit Generics zu machen wäre.
Hat jemand eine Idee (vielleicht auch einen komplett anderen Ansatz), wie ich da am Besten zu einer guten Lösung komme?