Enumerator

Status
Nicht offen für weitere Antworten.

A3XX

Bekanntes Mitglied
Hi

Ich ackere mich gerade durch dieses Java Buch und bin gerade in Kapitel 14. Nun bin ich Enumeratoren begegnet. Der Autor sagt, "das Interface Enumeration". Da läuteten bei mir die Glocken -> siehe mein Thread von gestern.

Müsste mann dann dieses Interface nicht implementieren? In seinem Beispiel erstellt er nur eine neue Instanz davon..
 
B

Beni

Gast
Welches Buch? :###

Oder kannst du nicht einfach kurz den Code dieses Autors posten? Ich verstehe die Frage nämlich nicht ganz... ???:L
 

Isaac

Bekanntes Mitglied
Das kann er nicht.

Enumeration e = new Enumeration() <- TRÖÖÖT, geht nicht!

Was wiederum geht ist

Enumeration e = new Vector().elements();//macht kein Sinn weil der Vector eh leer ist aber darum gehts hier ja nicht


Das zweite geht, weil Vector eben das Interface implementiert.
 

A3XX

Bekanntes Mitglied
ist aus www.javabuch.de

@ Isaac: Aha demfall implementiert Vector "standardmässig" (ebenso wie z.B. der String Tokenizer) den Enumerator? Das würde Sinn machen...
 

Isaac

Bekanntes Mitglied
Ja, das ist ja wie gesagt der vorteil an Interfaces.

Wenn du selbst eine Datenstruktur schreibst, z.b. eine verlinkte Liste oder sonst eine Kette dann würde es sinn machen das Interface zu implementieren damit man mit den Methoden hasMoreElements() und nextElement() einfach durch deine Datenstruktur "browsen" kann.
 
B

bygones

Gast
A3XX hat gesagt.:
@ Isaac: Aha demfall implementiert Vector "standardmässig" (ebenso wie z.B. der String Tokenizer) den Enumerator? Das würde Sinn machen...
Nicht ganz - Vector implementiert nicht das interface... würde er das machen wäre es schwierig immer wieder eine enumeration von vorne zu erhalten....
die implementierung der method läuft über eine anomye Klasse:
Code:
public Enumeration elements() {
	return new Enumeration() {
	    int count = 0;

	    public boolean hasMoreElements() {
		return count < elementCount;
	    }

	    public Object nextElement() {
		synchronized (Vector.this) {
		    if (count < elementCount) {
			return elementData[count++];
		    }
		}
		throw new NoSuchElementException("Vector Enumeration");
	    }
	};
    }
siehe auch Iterator Pattern
 

A3XX

Bekanntes Mitglied
Danke erstmal. Das mit der anonymen Klasse habe ich im Buch vorerst mal übersprungen, weil mir das alles noch bisschen zu hoch gegriffen und zu abstrakt ist. Am Ende des Buches gehe ich mit noch bisschen mehr Wissen nochmal zurück und versuche mein bestes :) dann les ich auch nochmal Deine Antwort genau durch und verstehe sie dann (hoffentlich) :)
 

A3XX

Bekanntes Mitglied
Bin jetzt wieder bisschen weiter und frage mich was der Unterschied zum Iterator ist? Iterator ist jetzt einfach an die Sprachkonventionen angepasst, weil alle anderen immer den Ausdruck Iterator für das verwenden und nicht Enumerator right?
 

A3XX

Bekanntes Mitglied
So nochmal ein Nachtrag (meine Frage von vorher ist natürilch immer noch offen: Unterschied Iterator - Enumerator?)

Ich ahb jetzt lange lange den folgenden Code zur Beispielklasse Queue http://www.rz.fhtw-berlin.de/hjp3/k100098.html

4 Fragen:

1. Soweit ich das sehe wird von nirgends was implementiert das es schon gibt (kein Interface etc., rein gar nichts), also nur Dinge die der Autor selbst geschrieben hat. Richtig?

2. Zur Klasse ElementWrapper: Innerhalb der Klasse ElementWrapper erstellt er ein Objekt von sich selber oder nicht? Also mittels ElementWrapper next. Aber: Wieso ist dann aber die Variable tmp.next das nächste Objekt? Müsste es dann nicht heissen temp.next.element?! Da hab ich nen Hänger...

3. in der Methode clear schreibt er:

Code:
while(first != null){
    ElementWrapper tmp = first;
    first = first.next;
    tmp.next = null;

tmp ist ja dann eine Kopie von first oder eine Referenz auf first? Wie würde man das jeweils andere machen? (also referenz oder kopie)?

4. Wie macht man eine Exception, die nicht behandelt werden muss? Wie z.B. die RuntimeErrors(oder sind es nicht die?! ???:L ). Also wie throwe ich selbst so eine, die dann aber nicht behandelt werden muss...nur kann wenn man will & es für gut empfindet
 
B

bygones

Gast
A3XX hat gesagt.:
Bin jetzt wieder bisschen weiter und frage mich was der Unterschied zum Iterator ist? Iterator ist jetzt einfach an die Sprachkonventionen angepasst, weil alle anderen immer den Ausdruck Iterator für das verwenden und nicht Enumerator right?
In der API:
An iterator over a collection. Iterator takes the place of Enumeration in the Java collections framework. Iterators differ from enumerations in two ways:

* Iterators allow the caller to remove elements from the underlying collection during the iteration with well-defined semantics.
* Method names have been improved.

This interface is a member of the Java Collections Framework.
 

A3XX

Bekanntes Mitglied
Ah ok, danke erstmal. Aber soweit ich jetzt das sehe, sind die Klassen, welche einen Enumerator verwenden, eher bei den älteren Collections, und die mit nem Iterator bei den neueren oder?

Und ich hab momentan ein riesen Collections-Chaos. Da gibt es die alten, die neuen und von denen gibt es wieder enorm viele verschiedene. Braucht ihr alle von denen, also je nach Zweck und kennt ihr die alle Auswendig? Oder beschränkt ihr euch so auf 1-2 verschiedene Collections? Ich denke Vektoren und Listen tönen sehr nützlich.
 
B

bygones

Gast
A3XX hat gesagt.:
Ah ok, danke erstmal. Aber soweit ich jetzt das sehe, sind die Klassen, welche einen Enumerator verwenden, eher bei den älteren Collections, und die mit nem Iterator bei den neueren oder?
Ja - wie in der API zu lesen ist der Iterator die neue Enumeration....

A3XX hat gesagt.:
Und ich hab momentan ein riesen Collections-Chaos. Da gibt es die alten, die neuen und von denen gibt es wieder enorm viele verschiedene. Braucht ihr alle von denen, also je nach Zweck und kennt ihr die alle Auswendig? Oder beschränkt ihr euch so auf 1-2 verschiedene Collections? Ich denke Vektoren und Listen tönen sehr nützlich.
Welche Collection du verwendest hängt stark von ab, wo und wie sie verwendet werden. Z.b. unterscheiden sich Vector und ArrayList nur darin, dass alle Methoden in Vector synchronisiert sind. Ist das für dich uninteressant ist Vector nicht so interessant. Weiterhin bieten Vector und ArrayList sog. Random Access an (da sie intern Arrays sind) - d.h. du kannst einfach und performant über
Code:
arrayList.get(5);
auf ein Element zugreifen. Eine LinkedList hingegen ist eine verkette Liste und ist daher z.b. beim RandomAccess sehr sehr unperformant (?). Dafür fällt aber bei ihr das Array kopieren flach wie bei Vector/ArrayList (wenn deren interner Array voll ist muss ein größeres angelegt werden und kopiert werden).
Alle diese Collection erlauben doppelte Elemente. Willst du das nicht gibt es z.b. HashSet und TreeSet. Ist dir die Ordnung egal nimm HashSet. Willst du auch eine Ordnung in der Collection haben dann TreeSet...

Siehste - nicht so schwer :wink:
 

A3XX

Bekanntes Mitglied
Ich druck mir jetzt das aus und für das nächste Jahr wird mir das als Richtlinie dienen :) Sowas hab ich gesucht. Denn in allen Büchern werden einfach ALLE Collections beschrieben und ein Amateur(Anfänger bin ich nicht mehr *räusper* hoff ich doch :) der hat das komplette Chaos. Danke Dir!
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen

Ähnliche Java Themen

Neue Themen


Oben