[JAVA] Quesito sugli iteratori

[AndreaNobili]

Ciao,
studiando Java sono arrivato a vedere gli iteratori...vi faccio qualche domanda relativa ad un esempio giocattolo fatto dalla professoressa.

Da quello che ho capito uso il meccanismo degli iteratori per poter scorrere collezioni di oggetti in modo standard per tutti i tipi di collezioni senza dover scendere a basso livello (per esempio impostando un ciclo per scorrere un array o una lista concatenata).

Così quando progetto una collezione di oggetti posso cacciarci dentro una particolare implementazione dell'interface Iterator e chi userà la classe che implementa quella collezione avrà gratis un modo standard per scorrere la collezione....è giusto come concetto del perchè si usano gli iteratori?

Veniamo all'esempio fatto in classe:

public class CollStr{	// Classe che gestisce una collezione di stringhe

	private String[] c;	// Variabile di istanza: la collezione di stringhe è gestita banalmente da un array di stringhe
	int i;
	
	public CollStr(String str[]){	// COSTRUTTORE
		// COSTRUISCE L'ARRAY c CHE IMPLEMENTA LA COLLEZIONE IN QUALCHE MODO
	}
	
	private class MioIteratore implements Iterator{		// E' una CLASSE INTERNA che implementa l'interface Iterator
		
		private int dove;
		
		public MioIteratore(){		// COSTRUTTORE MioIterator
			dove = 0;				// Punta al primo elemento dell'array
		}
		
		public Object next(){		// Restituisce l'elemento non ancora estratto
			return c[dove];
		}
		
		public void remove(){
			dove ++;				// Non elimina l'oggetto dalla collezione malo rimuove solo dall'iteratore
		}
		
		public boolean hasNext{
			return dove < c.length;	// TRUE se ha un elemento successivo, FALSE se non ce l'ha
		}
	
	}	// CHIUSURA DELLA CLASSE INTERNA
	
	public Iterator enumera(){		// Metodo che restituisce il riferimento ad un oggetto che implementa Iterator
		return new MioIteratore();	// Ritorna il riferimento ad un oggetto di tipo MioIteratore appena creato
	}
	
}

La collezione di stringhe viene banalmente rappresentata tramite un array di stringhe (il costruttore non l'ho scritto perchè tanto ai fini di questo argomento mi interessa poco ora come ora)

Poi voglio munirla di un iteratore per poterla scorrere comodamente in modo standard, allora ci ficco dentro una classe interna che ho chiamato MioIteratore che implementa l'interface Iterator e quindi implementa in modo coerente a com'è rappresentata la collezione tutti i metodi presenti dentro Iterator.

Fin quì tutto ok...

La domanda è la seguente....perchè poi fuori alla classe interna (quindi dentro la classe esterna) la proff ha dichiarato il metodo enumera che di fatto restituisce il riferimento ad un MioIteratore? Per comodità?

Ad esempio nel main se volevo iterare non funzionava comunque se creavo un nuovo oggetto di tipo MioIteratore a mano? Oppure non lo vedrei perchè è nella classe interna e quindi devo usare per forza il metodo enumera che è nella classe esterna che a sua volta può comunicare con la classe interna?

Spero di essere stato abbastanza chiaro...

Grazie
Andrea

[andbin]

Originariamente inviato da AndreaNobili
Da quello che ho capito uso il meccanismo degli iteratori per poter scorrere collezioni di oggetti in modo standard per tutti i tipi di collezioni senza dover scendere a basso livello (per esempio impostando un ciclo per scorrere un array o una lista concatenata).

Il design pattern "Iterator" ha come obiettivo quello di rendere possibile la iterazione sugli elementi di una "collezione" (parlando in generale) senza dover "esporre" all'esterno i dettagli sulla struttura interna della collezione. La "conoscenza" di come avviene la iterazione è appunto incapsulata all'interno dell'iteratore. Tutto qui.

Originariamente inviato da AndreaNobili
Veniamo all'esempio fatto in classe:

Sì .. a livello concettuale hai sicuramente capito.
Vedo qualche piccolo errore. Di sintassi (es. manca () per hasNext). Ma anche concettuale.
Se la interfaccia Iterator è proprio quella del framework (java.util.Iterator) e non una "tua" (nessuno ti obbliga ad usare quella del framework ...) allora dovresti rispettare meglio il suo "contratto". Ovvero: se non intendi implementare il remove(), dovresti fargli lanciare UnsupportedOperationException e nel next() dovresti verificare se c'è almeno 1 elemento da restituire. In caso contrario dovresti lanciare NoSuchElementException. E il next comunque deve far avanzare la iterazione (cosa che non vedo nel tuo codice)

Se la interfaccia fosse una "tua" ... potresti stabilire/fare quello che ti pare.

Un mio esempio più completo (e che usa i generics) lo trovi in questa discussione.

Originariamente inviato da AndreaNobili
perchè poi fuori alla classe interna (quindi dentro la classe esterna) la proff ha dichiarato il metodo enumera che di fatto restituisce il riferimento ad un MioIteratore? Per comodità?

Per motivi di "incapsulazione" e astrazione. La classe che effettivamente implementa l'iteratore dovrebbe restare nascosta ... insomma, non è importante (non interessa sapere se si chiama MioIteratore o se è una inner-class o altro). Quello che invece importa è solo poter "vedere" l'iteratore come tipo più astratto, cioè la interfaccia Iterator.

se creavo un nuovo oggetto di tipo MioIteratore a mano?

Non dovresti, nemmeno se la classe dell'iteratore fosse "visibile" fuori da CollStr (e non dovrebbe esserlo). E infatti vedi bene che è una inner-class private quindi non visibile fuori da CollStr!

Come viene creato l'iteratore non è importante. Dove è implementato l'iteratore non è importante. Il massimo che si dovrebbe fare è mettere un metodo nella collezione che restituisce un oggetto iteratore. Della serie: "dammi un iteratore". Punto. Dove/come è fatto non importa.

[AndreaNobili]

Originariamente inviato da andbin


Sì .. a livello concettuale hai sicuramente capito.
Vedo qualche piccolo errore. Di sintassi (es. manca () per hasNext). Ma anche concettuale.
Se la interfaccia Iterator è proprio quella del framework (java.util.Iterator) e non una "tua" (nessuno ti obbliga ad usare quella del framework ...) allora dovresti rispettare meglio il suo "contratto". Ovvero: se non intendi implementare il remove(), dovresti fargli lanciare UnsupportedOperationException e nel next() dovresti verificare se c'è almeno 1 elemento da restituire. In caso contrario dovresti lanciare NoSuchElementException. E il next comunque deve far avanzare la iterazione (cosa che non vedo nel tuo codice)

Se la interfaccia fosse una "tua" ... potresti stabilire/fare quello che ti pare.

Un mio esempio più completo (e che usa i generics) lo trovi in questa discussione.

Per motivi di "incapsulazione" e astrazione. La classe che effettivamente implementa l'iteratore dovrebbe restare nascosta ... insomma, non è importante (non interessa sapere se si chiama MioIteratore o se è una inner-class o altro). Quello che invece importa è solo poter "vedere" l'iteratore come tipo più astratto, cioè la interfaccia Iterator.

Non dovresti, nemmeno se la classe dell'iteratore fosse "visibile" fuori da CollStr (e non dovrebbe esserlo). E infatti vedi bene che è una inner-class private quindi non visibile fuori da CollStr!

Come viene creato l'iteratore non è importante. Dove è implementato l'iteratore non è importante. Il massimo che si dovrebbe fare è mettere un metodo nella collezione che restituisce un oggetto iteratore. Della serie: "dammi un iteratore". Punto. Dove/come è fatto non importa.

Ti ringrazio moltissimo...solo un piccolo chiarimento:
cosa intendi con se non volessi implementare il remove()? Io il remove() l'ho implementato...che intendevi?

Grazie
Andrea

[andbin]

Originariamente inviato da AndreaNobili
Ti ringrazio moltissimo...solo un piccolo chiarimento:
cosa intendi con se non volessi implementare il remove()? Io il remove() l'ho implementato...che intendevi?

Intendevo dire: non implementare effettivamente la funzionalità di "rimozione" dell'elemento dalla collezione .... non il metodo in sé (che se ci pensi devi comunque implementare visto che è un metodo della interfaccia!!)

Potresti non voler consentire la rimozione tramite l'iteratore. In tal caso fai semplicemente lanciare UnsupportedOperationException.

[AndreaNobili]

Originariamente inviato da andbin
Intendevo dire: non implementare effettivamente la funzionalità di "rimozione" dell'elemento dalla collezione .... non il metodo in sé (che se ci pensi devi comunque implementare visto che è un metodo della interfaccia!!)

Potresti non voler consentire la rimozione tramite l'iteratore. In tal caso fai semplicemente lanciare UnsupportedOperationException.

mmm la professoressa ed il libro di testo dicono che il metodo remove non elimina l'oggetto dalla collezione ma solo dall'iteratore...ed infatti nel mio metodo remove() incrementa per passare all'oggetto successivo (appunto lo ha rimosso dall'iteratore ma non dalla collezione)...

C'è qualcosa che mi sfugge?

Tnx
Andrea

[andbin]

Originariamente inviato da AndreaNobili
la professoressa ed il libro di testo dicono che il metodo remove non elimina l'oggetto dalla collezione ma solo dall'iteratore...

Allora entrambi hanno sbagliato!
Dal javadoc di Iterator:

void remove()

Removes from the underlying collection the last element returned by the iterator (optional operation).

Originariamente inviato da AndreaNobili
ed infatti nel mio metodo remove() incrementa per passare all'oggetto successivo

Non sarebbe appropriato visto quanto ho appena detto sopra.

[AndreaNobili]

Originariamente inviato da andbin
Allora entrambi hanno sbagliato!
Dal javadoc di Iterator:

void remove()

Removes from the underlying collection the last element returned by the iterator (optional operation).

Non sarebbe appropriato visto quanto ho appena detto sopra.

Hai ragione te...cioè...sul libro mi pare che faccia come dici te nel senco che implementa solo 2 metodi: hasnesxt() e next() che da l'elelmento successivo e lo incrementa...

Poi la proff fa sempre nell'altro modo...ma è sbagliato che non funziona o che non è lo standard mka che può comunque andare?

Grazie
Andrea

[andbin]

Originariamente inviato da AndreaNobili
Poi la proff fa sempre nell'altro modo...ma è sbagliato che non funziona o che non è lo standard mka che può comunque andare?

Dico che non ha senso fare un metodo che "rimuove" l'elemento dalla iterazione.

Tipicamente la scansione con un iteratore si fa così:

for (Iterator<Qualcosa> i = collezione.iterator(); i.hasNext(); ) {
    Qualcosa e = i.next();
    .....
}

Non ha granché senso "rimuovere" dalla iterazione ... se non ti piace l'elemento i-esimo, non lo usi e al prossimo giro ne prende già un altro con il next()!

Anche ammesso per ipotesi di fare il metodo come dici tu (rimuove dalla iterazione ... ovvero "salta") ... il remove() quando la chiami? Se lo chiamassi dopo il next(), salteresti il successivo (vorresti davvero così?) e se lo chiamassi prima del next() ... come sai che vuoi saltarlo?? Insomma ... non ha senso!

[AndreaNobili]

Booo non è che lo dico io Lo dice la proff...poi capisco il tuo discorso...però con i professori a volte bisogna fargli anche le cose come dicono loro (purtroppo).

Per esempio lei lo ha definito così e per usarli (ad esempio nel main) dice che il sistema standard è questo (almeno standard per lei...):

public class Test{
	public static void main(String[] args){
		
		int k;
		CollStr x = new CollStr(....);		// Crea in qualche modo la collezione di stringhe
		String s;
			
		Iterator it;						// Dichiaro una variabile di tipo Iterator
		it = x.enumera();					// Crea il corretto iteratore per la collezione x
		
		while(it.hasNext()){				// Finchè nella collezione ci sono ancora elementi su cui iterare
			s = (String) it.next();			// Metti in s la stringa corrente
			// USA S IN QUALCHE MODO;
			it.remove();	// Passa al successivo elemento rimuovendo quello corrente dall'iteratore (non dalla collezione)
		}
	}
}

Comunque grazie di avermi fatto notare la cosa...ho controllato sul libro ed in effetti fà come dici te e logicamente parlando mi pare anche più sensato (anche se credo che funzioni anche così).

Ciao
Andrea

[andbin]

Originariamente inviato da AndreaNobili
Booo non è che lo dico io Lo dice la proff...poi capisco il tuo discorso...però con i professori a volte bisogna fargli anche le cose come dicono loro (purtroppo).

Allora hai 2 strade:

a) Suggerisci alla prof. di leggersi il javadoc di java.util.Iterator (perché dubito molto l'abbia mai letto anche solo di sfuggita). Questa soluzione è praticabile ma in base al "carattere" del docente. Sconsigliata se è il tipo "sono io che vi insegno" ....

b) Fare come dice la prof per gli esercizi (giusto per farla stare buona...) .... ma poi apprendere quello che invece è giusto e più logico (e mi pare che adesso hai compreso la questione).