Ich habe vor kurzem ein Buch "The Java Tutorials" 3. Ausgabe gelesen. Es spricht über die Implementierung der inneren Klasse, wie das Bild zeigt.
Im dritten Absatz heißt es: "Die Stack-Klasse selbst sollte die Iterator-Schnittstelle nicht implementieren, weil ...".
Ich kann keinen Grund finden, dass die Stack-Klasse Iterator nicht implementieren sollte. Der angegebene Grund ist NICHT persistent.
Könnten Sie das erklären?
Grundsätzlich ist ein Iterator Stateful - er muss wissen, wo er in die Collection zeigt. Das gehört nicht als Teil der Sammlung selbst - und die gegebene Erklärung ist die richtige ... Es ist durchaus möglich, zwei unabhängige Iterator-Objekte zu haben, die über dasselbe Sammelobjekt iterieren. Wie würden Sie das modellieren, wenn die Sammlung selbst die Iterator-Schnittstelle implementiert? Es ist möglich (z. B. Erstellen einer neuen Instanz der Sammlung, die wiederum einen Verweis auf die ursprüngliche Sammlung enthielt), aber es wäre wirklich hässlich.
Hier gibt es getrennte Bedenken:
Getrennte Bedenken = & gt; getrennte Klassen.
Der einfachste Weg, sich davon zu überzeugen, ist wahrscheinlich, dass Sie versuchen, Ihre eigene Sammlung zu implementieren - und dann mehrere Iteratoren haben. Zum Beispiel könnten Sie versuchen:
%Vor%Das sollte ausgedruckt werden:
%Vor%Versuchen Sie es zu implementieren, ohne zwei Klassen zu haben, und sehen Sie, wie Sie vorgehen, wobei Sie die Trennung von Bedenken berücksichtigen.
Der Stapel sollte den Iterator nicht selbst implementieren, da Sie dann immer nur einen Iterator haben könnten und das Iterieren über einen Stapel würde den Stapel ändern.
Beachten Sie, dass die verschachtelte Klasse ein "currentItem" -Feld hat. Dieses Feld müsste sich in "Stack" befinden und würde sich ändern, wenn next () aufgerufen wird. Das Iterieren über eine Sammlung sollte die Sammlung nicht ändern.
Das erste Problem ist ernster: Angenommen, zwei Personen durchlaufen den Stapel (oder eine Methode möchte zwei Iteratoren über den Stapel erstellen). Wenn iterator()
this
zurückgibt, sind die beiden Iteratoren identisch. Der Aufruf von next()
auf einen würde den anderen verschieben. Chaos.
A Stack
kann nicht seine eigene Iterator
sein, da ein Stack mehr als einen Iterator unterstützt.
Sie möchten vielleicht mehr als einmal über den Stack iterieren. Diese Iterationen können zu verschiedenen Zeiten oder sogar gleichzeitig auftreten. Mehrere Iterationen zur gleichen Zeit erfordern eindeutig mehrere Objekte. Mehrere Iterationen zu unterschiedlichen Zeiten erfordern mehrere Objekte, da die Iterator-Schnittstelle die Rückkehr zum Start nicht unterstützt.
Es gibt zwei Gründe, aus denen ich mir Gedanken machen kann.
Möglicherweise möchten Sie mehrere Arten von Iteratoren, die auf verschiedene Arten iterieren. Zum Beispiel, sowohl ein Vorwärts-Iterator als auch ein Rückwärts-Iterator (iteriert vom Ende des Containers bis zum Anfang).
Wenn Sie einen Multiple-Pass-Algorithmus und / oder verschachtelte Schleifen haben, sollte jede Schleife ihren eigenen Iterator haben wollen, der unabhängig von den anderen Iteratoren die Position im Container verfolgt.
Es wäre schwierig, wenn nicht gar unmöglich, diese Funktionalitäten mit der in der Klasse Iterator
implementierten Schnittstelle Stack
zu unterstützen.
Um der Diskussion noch hinzuzufügen, wird die innere Klasse Zugriff auf private Daten der Stack-Klasse haben. Auf diese Weise wird es der Stack-Klasse gelingen, mit dem Client-Programmierer ein Objekt oder mehrere Objekte (den Iterator (s ), und dennoch können diese Objekte auf die Klasse zugreifen und separate Iterationen über die Sammlung bereitstellen.
Tags und Links java inner-classes iterator