Seite 1 von 1

Ex05 Aufgabe 2.3

Verfasst: 27. Nov 2007 19:29
von timoph
Hallo,
ich finde die Aufgabenstellung von der 2.3 ein wenig unklar formuliert.

"Versuchen Sie das Interface ICollapsedCompositeNode, um die Methoden collapseChildren() und expandChildren() zu erweitern, und von den Adaptern zu implementieren, so dass beim Aufruf von collapse() über collapseChildren() auch alle Kindeskinder versteckt werden (). Gibt es Probleme die dabei auftreten?"

Sind Children nur die direkten Childknoten (wie z.B. in XML) oder bezieht sich das auf alle Descendants (Kindeskinder, Enkel der Kinder, usw.)?

Desweiteren wäre zu klären warum diese Funktionalität von Adaptern implementiert werden muss. Wir haben einfach eine Klasse CollapsableCompositeNode extends CompositeNode erzeugt und dort die expand/collapse Funktionalität hinzugefügt. Das darf man ja machen, oder ist das nicht im Sinne der Aufgabe und wir müssen einen Adapter für Node erstellen?

Liebe Grüße

Verfasst: 27. Nov 2007 20:24
von es11
Bei der Vorstellung der Übung hat er gesagt man sollte es sich wie beim Windows Datei Explorer vorstellen. Dort werden alle Childs eingeklappt.

Mit diesem Vergleich vor Augen, stellt sich mir die Frage was genau der Unterschied zwischen collapse() und collapseChildren() ist?

Verfasst: 28. Nov 2007 09:53
von dinkelaker
Hallo timoph,

Children eines Knoten sind direkte Nachfahren. Deren Kinder wären ja dann Enkel ;-).

Die Methode collapse ist wie im Explorer zu implementieren,
diese wirkt nur auf direkte Kinder.

In Aufgabe 2.3 geht es darum einmal auszuprobieren,
was passiert, wenn wir collapse/expand durch den Baum propagieren.
Eine entsprechende Funktion gibt es im Explorer allerdings nicht.
Eclipse bietet zumindestens "Collapse All" im Package Explorer an.
Es werden ALLE aufgeklappten Knoten des Baum zusammengeklappt.

Diese Funktion wird dann vorübergehend in collapse() mit eingebaut werden,
nur damit nicht zusätzlich noch neue Einträge in das Menü einfügen werden müssen.
Wir wollten Euch die Anpassung des Menüs an dieser Stelle ersparen. Nach dem Bearbeiten bitte die Zeile in collapse() die collapseChildren() aufruft wieder auskommentieren.

Tom

Verfasst: 28. Nov 2007 10:06
von Bara2
Ich habe einen neuen Menü-Punkt eingebaut - das ist jetzt ja wirklch kein weiterer Aufwand :)
Allerdings finde ich die beiden collapseAll- und expandAll- Methoden in diesem Baum schwer zu testen, Es gibt ja gerade einmal 3 Ebenen und die Blätter können ja nicht collapsed werden. Der einzig sinnvolle collapseAll-Aufruf (auf die Wurzel) wirkt sich doch also in der Darstellung genauso aus wie ein einfaches collapse() auf root, oder?
Natürlich sind danach, wenn man nur root wieder expanded die beiden Departments noch collapsed.

Verfasst: 28. Nov 2007 20:51
von Evgeni
Bara2 hat geschrieben:Ich habe einen neuen Menü-Punkt eingebaut - das ist jetzt ja wirklch kein weiterer Aufwand :)
Allerdings finde ich die beiden collapseAll- und expandAll- Methoden in diesem Baum schwer zu testen, Es gibt ja gerade einmal 3 Ebenen und die Blätter können ja nicht collapsed werden. Der einzig sinnvolle collapseAll-Aufruf (auf die Wurzel) wirkt sich doch also in der Darstellung genauso aus wie ein einfaches collapse() auf root, oder?
Natürlich sind danach, wenn man nur root wieder expanded die beiden Departments noch collapsed.
Mich würde es auch interessieren.

Bei mir sieht es dann wie im Anhang aus.
wobei mit collapseAll die collapse mit collapseChildren gemeint.

Die Bilder sind leider in umgekehrten Reihenfolge.

Verfasst: 29. Nov 2007 12:29
von dinkelaker
Hallo Bara2, Hallo Evgeni,

Ja, bei collapseAll() auf root und danach ein expand() auf root sind die Departments zusammengeklappt. Bei expandAll() root hingegen sind die Departments alle Aufgeklappt.
Von daher in der Darstellung ist das nicht besonders überraschend.

Allerdings interessiert uns eher, ob durch diese neue Funktion Design-Probleme oder "Bad Smells" im Code entstehen.

Gruß, Tom

Verfasst: 29. Nov 2007 22:00
von MuldeR
dinkelaker hat geschrieben:Allerdings interessiert uns eher, ob durch diese neue Funktion Design-Probleme oder "Bad Smells" im Code entstehen.
Das Problem, dass ich hier sehe ist, dass CollapsedCompositeNode ja einen "normalen" CompositeNode zum ICollapsedCompositeNode adaptiert. Die Kinder werden folglich nicht in der CollapsedCompositeNode Klasse selbst, sondern in der adaptierten Klasse (CompositeNode) verwaltet. Wenn man nun die Kinder durchläuft, haben diese natürlich den statischen Typ Node, was das Aufrufen von collapse() bzw. expand() erschweren dürfte...

Allerdings steht man vor exakt dem selben Problem, wenn man die ganzen CollapsedCompositeNode's schön in seinem HierarchyDisplay drin hat, und dann von außen (etwa über das Menu) die collapse() bzw. expand() Methoden testen will. Siehe dazu auch:
http://www.fachschaft.informatik.tu-dar ... hp?t=10485