Iterator (Architektur)

[shorty]

Tach die Damen

Ich habe heute mal ein Paar Fragen bezüglich der Architektur und Funktionalität von Iteratoren. Das Root-Interface sieht aktuell wie folgt aus:

PHP-Code:

package com.shortybmc.util
{
    
    public interface Iterator
    {
        
        
        /**
         * Returns the current cursor position.
         * 
         * @return the current cursor position
         */
        function current () : int
        
        
        /**
         * Returns the next element.
         * 
         * @return the next element
         * @throws com.shortybmc.collection.NoSuchElementException If
         * iteration has no more elements.
         */
        function next () : *
        
        
        /**
         * Returns true if iterator has more elements.
         * 
         * @return true if iterator has more elements else false
         */
        function hasNext () : Boolean
    }
} 


Grundlegende Überlegung

Alle Iteratoren sollen eine Mindestfunktionalität in Form von Vorwärts- und Rückwärtstraversiebarkeit des Aggregates aufweisen.


Implementierungsmöglichkeiten

Damit die Ausführungen nicht ganz so trocken werden nehmen wir einen Array-Iterator der das übergebene Array vorwärts und rückwärts traversieren können soll. Die "Robustheit" der jeweiligen Implementierung, und die fehlende remove Methode im Iterator Interface sollen vorerst keine Beachtung finden, das kommt aus Platz- und Verständlichkeitsgründen später. Los gehts.

Möglichkeit eins:

Es wird ein abstrakter Iterator AbstractArrayIterator erstellt welcher die Schnittstelle Iterator implementiert. Für die jeweilige Art der Traversierung werden zwei zusätzliche konkrete Iteratoren erstellt.

1. ArrayForwardIterator
2. ArrayBackwardIterator

Diese beiden Iteratoren erweitern AbstractArrayIterator und unterscheiden sich nur durch die Position des internen Cursors. Das zu traversierende Array wir im Konstruktor übergeben.

Möglichkeit zwei:

Es wird ein konkreter Iterator ArrayIterator erstellt welcher die Schnittstelle Iterator implementiert. Um die Art der Traversierung zu ändern bediene ich mich eines State-Patterns, welches es mir ermöglicht den internen Zustand, respektive den Traversierungsalgorithmus zu ändern. Der Zustand wird, genau wie das zu traversierende Array im Konstruktor von ArrayIterator übergeben.

Ich kann mich bisher nicht so recht für eine bestimmte Variante entscheiden. Sicher ist nur das der Traversierungsalgorithmus im Iterator selbst stecken soll, und alle konkreten Iteratoren als externer Iterator implementiert werden, aka. der Client treibt die Iteration selbst voran.

Mein Favorit ist Möglichkeit zwei, wie seht ihr das? Habt ihr andere Vorschläge?


lg,
shorty

[Omega Psi]

Hm, ich implementiere in meinen Iteratoren eine Funktion previous():Object.

Ich verstehe auch gerade nciht so ganz, worauf der Thread hinaslaufen soll...

[shorty]

Moin Flo,

ich schreibe gerade ein Package welches die für mich wichtigsten konkreten Iterator-Implementierungen enthält (StringIterator, ArrayIterator, ObjectIterator). Damit Schnittstelle, Architektur und interner Aufbau möglichst gleich sind, und bleiben frage ich welche die günstigere Methode ist. Wenn ich damit fertig bin gehts weiter mit dem collection package. Spätestens da möchte ich nicht mehr an den Iteratoren fummeln.

Edit: previous & hasPrevious fallen nach aktuellem Stand vollständig aus, da diese Funktionalität wie z.B. in bsp 2 geschrieben durch den Zustand des Iterators gewährleistet wird, und die Schnittstelle schön schlank bleibt.

[Omega Psi]

Die States beschreiben, ob der interne Zähler inkrementiert oder dekrementiert werden? Also ich würde mich entweder für Version 2 entscheiden oder einfach zusätzliche Funtionen add und previous implementieren.

Edit: hab das mit den Funktionen gerade gelesen. Dann Version 2.

[sebastian]

Ist 1 nicht die übliche Variante?

Bzw sowas:

public class ArrayCollection implements ICollection
{
    // ...
 
    public function iterator(type:String):IIterator
    { 
        if(type=="XYZ")
        {
            return new ArrayReverseIterator(data);
        }
        else
        {
            return new ArrayIterator(data);
        }
    }
} 

[shorty]

@Sebastian dito!

@Flo Version 2 finde ich persönlich auch am schicksten, hat auch n weilchen
gedauert bis ich da angekommen bin

[Omega Psi]

Hm, kann ich an dieser Stelle nicht soviel zu sagen. Ich arbeite nicht oft mit Iteratoren, nur wenn ich Mengen von Objekten untersuche, aus denen ich dann auch Objekte kicken will... und da bau ich mir meistens noch die previous Funktionen ein.