Typischerweise schon, ja.
Nicht explizit, das passiert eher versehentlich, wenn z.B. irgendwo
eine Hilfsmethode das größte Element oder eine Summe der Collection
sucht - und dieses Konstrukt irgendwann im Zug einer
Weiterentwicklung von viel weiter oben iterativ aufgerufen wird.
Klar *kann* man das auflösen (und sollte man nach dem Reinheitsgebot
wohl auch), aber wenn nur genügend Ebenen dazwischen sind, fällt es
halt erst im Fehlerfall auf. In der Regel lasse ich den Code dann
auch so (nur halt mit explizitem getIterator()), weil es bezüglich
Performance (bei Collections mit <10 Elementen) völlig egal ist und
die API schlank hält.
> Oder hast du eine tiefere baumstruktur, über die du (depth first
> oder breadth first) iterierst?
Nein, meine Collections implementieren (grundsätzlich, d.h. schon in
der abstrakten Basisklasse) RecursiveIterator, wobei es der
jeweiligen Implementierung obliegt, das mit Leben zu erfüllen.
Erschien mir seinerzeit eine gute Idee, weil es nichts kostet und
ich mir eine gesonderte Klasse RecursiveCollection erspare. Dass
ich mir damit die Implementierung von \Iterator verbaue, ist mir
erst später aufgefallen, als ich das zum ersten Mal gebraucht hätte.
Und irgendwie finde ich das dumm, weil die beiden Interfaces in
keinerlei Konflikt zueinander stünden - dass man sie nicht beide
nebeneinander implementieren kann, liegt einzig und alleine an der
Erbhierarchie.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - beglücken!? Aber blicken ist verständiger.
(Sloganizer)