Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    Se implemento l'iteratore non compila più

    Ciao,
    ho un problema in questo codice....una volta che implemento l'iteratoremi dà un messaggio di errore in fase di compilazione, comemai?

    Il problema è solo nell'iteratore perchè senza compilava...ed ilmessaggio di errore
    è questo:


    C:\Programmi\Crimson Editor\template\esercizi\esami\11-07-07>javac Involucro2.java
    Involucro2.java:123: Involucro2.MioIteratore is not abstract and does not override abstract method hasNext() in java.util.
    Iterator
    private class MioIteratore implements Iterator{ // E' la classe interna che implementa l'interfaccia Itera
    tor
    ^
    Involucro2.java:145: cannot find symbol
    symbol : method MioIteratore()
    location: class Involucro2
    return MioIteratore();
    ^
    Note: Involucro2.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    2 errors



    codice:
    import java.util.*;
    
    public class Involucro2{
    	/** OVERVIEW: Involucro rappresenta una collezione dinamica di stringhe del tipo <s1, s2, s3,...., sn> tali che 
    				  s_i è completamente contenuta in s_(i+1).
    				  
    				  V = {{s1,s2,s3,...,sn>: Per ogni i s_i è una stringa ed s_i è interamente contenuto in s_(i+1)}}
    				  
    				  O = inserisci: Se l'oggetto che si vuole inserire è coerente con la rappresentazione della collezione
    				                 (è una stringa) e con lo stato attuale della collezione (i valori già presenti nella
    				                 collezione), allora lo inserisce nella collezione modificandola
    				      
    				      fondi: Date collezioni S e T se s_n è interamente contenuto in t_1 allora fonde le due collezioni nel
    				             seguente modo: S = <s1,s2,s3,...,sn> T = {t1,t2,t3,...,tn} --> {s1,s2,s3,...,sn,t1,t2,t3,..,tn}
    				      
    				      get(i): Accede in maniera posizionale all'i-esimo elemento della collezione */
    				     
    	Vector collStr;			// Rappresenta la collezione di stringhe
    	
    	
    	/** FUNZIONE DI ASTRAZIONE: F_a(): STATO CONCRETO ----> STATO ASTRATTO
    								F_a([a, ab, abc, abcd]) ------> {<a, ab, abc, abcd>}
    								ma anche: F_a([a, b(a), (ba)f, z(baf), (zbaf)e]) ---> {a, ba, baf, zbaf, zbafe}
    								
    		INVARIANTE DI RAPPRESENTAZIONE: è un predicato I: C ---> boolean che è vero per gli stati concreti che sono
    										rappresentazioni leggittime di uno stato astratto:
    										
    										I(collStr): collStr != NULL (il Vector deve essere sempre diverso da NULL)
    										Per ogni i: v.get(i) deve essere incluso in v.get(i+1) (la i-esima stringa deve
    										sempre essere interamente contenuta nella (i+1)-esima stringa della collezione */
    										
    	/** COSTRUTTORE:
    		EFFECTS: Crea un nuovo oggetto di tipo Involucro che rappresenta la collezione vuota
    		@param: void:
    		@return: Il riferimento ad un oggetto di tipo Involucro
    		Il costruttore soddisfa l'invariante di rappresentazione in quanto: 1) Viene assegnata alla variabile di istanza
    		collStr il riferimento ad un nuovo Vector quindi no è mai null. 2) Il costruttore crea una collezione vuota che
    		rappresenta la stringa vuota contenuta in ogni stringa, quindi qualsiasi sia il primo elemento va bene */
    		
    	public Involucro2(){
    		collStr = new Vector();		// Crea la collezione vuota assegnando a collStr il riferimento ad un nuovo Vector vuoto
    	}
    	
    	/** Metodo inserisci()
    		EFFECTS: Se il parametro può essere inserito nella collezione (se contiene completamente l'ultima stringa della
    				 collezione, allora viene inserito nella collezione rappresentata dall'oggetto ricevente, altrimenti viene
    				 sollevata una StringaNonValidaException
    		MODIFIES: this
    		@param: Un oggetto di tipo String 
    		Il metodo inserisci() soddisfa l'invariante di rappresentazione in quanto se la collezione è vuota permette
    		l'inserimento di una stringa qualsiasi, se invece nella collezione è già presente qualcosa prima di inserire il
    		parametro controlla che il parametro contiene completamente l'ultima stringa presente nella collezione. Se ciò è
    		verificato la inserisce, altrimenti no e la collezione rimane sempre coerente con la sua definizione */
    	
    	public void inserisci(String str){
    		
    		int dimensione = collStr.size() ;	// Contiene la dimensione del Vector collStr
    		String ultima = (String)collStr.elementAt(dimensione);
    		if(dimensione == 0)					// Se la collezione è vuota
    			collStr.addElement(str);		// Aggiungi la stringa parametro in prima posizione
    			
    		else{						// Altrimenti, se nella collezione ci sono già degli elementi
    			if(str.contains(ultima))	// Se il parametro contiene l'ultima stringa della collezione
    				collStr.addElement(str);					// Aggiungi la stringa parametro in prima posizione
    			else throw new StringaNonValidaException();		// altrimenti solleva un'eccezione
    		}
    	}
    				 
    
    	
    	/** Metodo fondi():
    		EFFECTS: Se possibile fonde la collezione ricevente con quella referenziata dal parametro. Tale fusione è possibile
    				 se e solo se l'ultimo elemento della collezione ricevente è totalmente contenuto nel primo elemento della
    				 collezione referenziata dal parametro, altrimenti solleva una CollezioneParametroNonValidaExcepion
    				 Eventualmente la dusione fosse possiebileil metodo crea una nuova collezione che contiene la fusione delle
    				 due collezioni iniziali.
    		@param: Il riferimento ad un oggetto Involucro
    		@return: Il riferimento ad un nuovo oggetto Involucro
    		Il metodo rispetta l'invariante di rappresentazione in quanto ne l'oggetto ricevente, ne il parametro possono essere
    		null e poichè l'eventuale nuova collezione rispetta la proprietà che Per ogni i, l'i-esima stringa è sempre
    		contenuta nella (i+1)-esima stringa */
    		
    		public Involucro2 fondi(Involucro2 coll){
    			
    			Involucro2 fusione;									// Conterrà l'eventuale fusione delle due collezioni
    			int dimensioneRicevente = collStr.size();			// Contiene la dimensione della collezione del ricevente
    			int dimensioneParametro = coll.collStr.size();		// Contiene la dimensione della collezione del parametro
    			int cont;
    			
    			// Contiene l'ultima stringa della collezione ricevente
    			String ultimoElemRicevente = (String) collStr.elementAt(dimensioneRicevente);
    			
    			// Contiene la prima stringa della collezione referenziata dal parametro
    			String primoElemPar = (String) coll.collStr.elementAt(0);
    			
    			/* Se la prima stringa della collezione referenziata dal parametro contiene l'ultima stringa della collezione
    			   dell'oggetto ricevente */
    			if(primoElemPar.contains(ultimoElemRicevente)){	
    				fusione = new Involucro2();		// Costruisci un nuovo oggetto Involucro che conterrà la fusione
    		
    				// Copia in ordine tutte le stringhe della prima collezione (oggetto ricevente) nell'oggetto fusione
    				for(cont=0; cont<=dimensioneRicevente; cont++){
    					fusione.collStr.addElement((String) collStr.elementAt(cont));
    				}
    				
    				// Poi copia in ordine tutte le stringhe della collezione referenziata dal parametro nell'oggetto fusione
    				for(cont=0; cont<=dimensioneRicevente; cont++){
    					fusione.collStr.addElement((String) coll.collStr.elementAt(cont));
    				}
    			}
    			
    			/* Se invece non è rispettata la prprietà che la prima stringa del parametro contiene l'ultima stringa
    			   della collezione ricevente solleva un'eccezione */
    			else throw new CollezioneParametroNonValidaExcepion();
    			
    			// Alla fine, se non è stata sollevata l'eccezione ritorna l'oggetto creato e popolato
    			return fusione;
    		}
    			
    			
    		/* Iteratore */
    		
    		private class MioIteratore implements Iterator{	// E' la classe interna che implementa l'interfaccia Iterator
    			
    			public int dove;		// Rappresenta la posizione all'interno della collezione su cui si itera
    			
    			public MioIteratore(){	// Costruttore del generatore
    				dove = 0;			// L'iterazione viene fatta partire dal primo elemento della collezione
    			}
    			
    			public Object next(){	// Restituisce l'elemento correte della collezione su cui si stà iterando
    				return collStr.elementAt(dove);
    			}
    			
    			public boolean hasNest(){	// Restituisce true se ci sono ancora elementi su cui iterare, false altrimenti
    				return dove < collStr.size();
    			}
    			
    			public void remove(){		// Passa al prossimo elemento della collezione
    				dove++;
    			}
    		}
    		
    		public Iterator enumera(){		// Maschero l'implementazione di MioIterator usando un metodo enumera
    			return MioIteratore();
    		}
    			
    }
    Grazie
    Andrea

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284

    Re: Se implemento l'iteratore non compila più

    Originariamente inviato da AndreaNobili
    return MioIteratore();
    No.
    return new MioIteratore();

    Comunque, tornando all'iteratore: remove() non dovrebbe far avanzare! (aspe ... è sempre per far contenta il/la prof??? ). E nel next() dovresti nuovamente controllare se c'è un prossimo elemento, se c'è lo ritorni e comunque incrementi la posizione. Se non c'è un elemento si dovrebbe lanciare NoSuchElementException.

    Ah. hasNext non hasNest
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3

    Re: Re: Se implemento l'iteratore non compila più

    Originariamente inviato da andbin
    No.
    return new MioIteratore();

    Comunque, tornando all'iteratore: remove() non dovrebbe far avanzare! (aspe ... è sempre per far contenta il/la prof??? ). E nel next() dovresti nuovamente controllare se c'è un prossimo elemento, se c'è lo ritorni e comunque incrementi la posizione. Se non c'è un elemento si dovrebbe lanciare NoSuchElementException.
    Esatto...per ora faccio le cose come piacciono al docente
    CMQ sono un deficiente...errore stupiderrimo

    Però ora continua a darmi questo errore:

    C:\Programmi\Crimson Editor\template\esercizi\esami\11-07-07>javac Involucro2.java
    Involucro2.java:123: Involucro2.MioIteratore is not abstract and does not override abstract method hasNext() in java.util.
    Iterator
    private class MioIteratore implements Iterator{ // E' la classe interna che implementa l'interfaccia Itera
    tor
    ^
    Note: Involucro2.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    1 error


    Ultima domanda su questo esercizio (chemi stà facendo venire la nausea).

    L'ultimo punto del compito mi chiede:

    Si richiede una generalizzazione del tipo Involucro che possa rappresentare e gestire insiemi di oggetti qualsiasi (oltre che di stringhe). Proggettare ed implementare tutte le entità necessarie al conseguimento di tale obbiettivo

    Primo dubbio:
    Involucro mi rappresentava insiemi di stringhe in cui la i-esima stringa era totalmente contenuta nella (i+1)-esima stringa quindi cose del tipo: {a, ab, cab, cabz}

    Qui mi si chiede di generalizzarlo...ma questa proprietà dovrà essere valida anche per la generalizzazione? (Ad esempio una collezione che gestisce rettangoli dove il primo rettangolo è contenuto nel secondo che a sua volta è contenuto nel terzo e così via...)

    Tranne che non sò bene come farlo...

    1) IDEA 1: Realizzo la classe Involucro2 come una CLASSE ABSTRACT che contiene la rappresentazione della collezione sotto forma di Vector e che contiene l'implementazione del costruttore (che tanto crea una collezione vuota) e dichiaro come metodi abstract i vari metodi inserisci() e fondi() (l'iteratore credo che posso implementarlo direttamente nella classe abstract perchè itero sulla collezione che è rappresentata dal Vector nella classe abstract)

    Poi da questa classe abstract estendo i vari tipi di collezioni come appunto Involucro2Stringhe, Involucro2Rettangoli, Involucro2Circonferenze, etcetc

    ed in ogni sottoclasse che estende Involucro2 implemento ad hoc i metodi inserisci e fondi in maniera appropriata

    2) IDEA 2 (più strampalata): Avevo pensato di creare un'interface chiamata Contenibile:
    codice:
    public interface Contenibile{
    	double contiene(Contenibile d);		// Ogni elemento deve essere capace di dire se è contenuto in un altro elemento
    }
    Poi nella classe Involucro2 il Vector conterrà collezioni di Contenibili ed il metodo aggiungi e fondi useranno il metodo contiene() di Contenibili per controllare se l'i-esimo elemento è contenuto nell'(i+1)-esimo elemento dellacollezione.

    Implemento Contenibile per creare tipi di dato come stringheContenibili, rettangoliContenibili, circonferenzeContenibili, etcetc ed in ognuno di esse implemento il metodo abstrac contiene().

    mmm come fare?

    Grazie
    Andrea

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284

    Re: Re: Re: Se implemento l'iteratore non compila più

    Originariamente inviato da AndreaNobili
    Esatto...per ora faccio le cose come piacciono al docente
    Lo immaginavo

    Originariamente inviato da AndreaNobili
    Però ora continua a darmi questo errore:
    Non hai corretto hasNest in hasNext.

    Originariamente inviato da AndreaNobili
    Si richiede una generalizzazione del tipo Involucro che possa rappresentare e gestire insiemi di oggetti qualsiasi (oltre che di stringhe). Proggettare ed implementare tutte le entità necessarie al conseguimento di tale obbiettivo

    Primo dubbio:
    Involucro mi rappresentava insiemi di stringhe in cui la i-esima stringa era totalmente contenuta nella (i+1)-esima stringa quindi cose del tipo: {a, ab, cab, cabz}

    Qui mi si chiede di generalizzarlo...ma questa proprietà dovrà essere valida anche per la generalizzazione? (Ad esempio una collezione che gestisce rettangoli dove il primo rettangolo è contenuto nel secondo che a sua volta è contenuto nel terzo e così via...)
    Io deduco che tu debba fare una (1) classe che sia in grado di gestire oggetti di tipo non noto a priori. Come succede concettualmente per le collezioni.

    Originariamente inviato da AndreaNobili
    1) IDEA 1: Realizzo la classe Involucro2 come una CLASSE ABSTRACT che contiene la rappresentazione della collezione sotto forma di Vector e che contiene l'implementazione del costruttore (che tanto crea una collezione vuota) e dichiaro come metodi abstract i vari metodi inserisci() e fondi() (l'iteratore credo che posso implementarlo direttamente nella classe abstract perchè itero sulla collezione che è rappresentata dal Vector nella classe abstract)

    2) IDEA 2 (più strampalata): Avevo pensato di creare un'interface chiamata Contenibile:
    codice:
    public interface Contenibile{
    	double contiene(Contenibile d);		// Ogni elemento deve essere capace di dire se è contenuto in un altro elemento
    }
    La questione di questa "generalizzazione" va affrontata su 2 fronti: il tipo degli oggetti e il criterio di "contenibilità".

    Vediamo il primo, il "tipo":
    Attualmente nella tua classe hai un Vector .. che di per sé può contenere tecnicamente oggetti di qualunque tipo. Ma nella tua classe il inserisci() riceve un String. E ammesso che il Vector sia gestito direttamente solo dall'interno della tua classe (ecco perché i campi è bene metterli private!) e non "esca" fuori per nessun motivo, puoi garantire tu che la collezione sarà sempre e solo di String.
    Se vuoi rendere generica la classe, ovvero che possa trattare un tipo arbitrario, che tipo usi? Cosa passi a inserisci()?
    Questa è la prima questione. Una prima risposta potrebbe essere: il metodo riceverà un Object. Questione seguente: chi/come garantisce che non venga passato prima un oggetto di tipo X e poi successivamente di tipo Y dove X e Y non centrano una mazza tra di loro???

    Secondo punto, la "contenibilità".
    Ora la tua classe gestisce dei String. E di String hai usato contains() che è un suo metodo, ben specifico. In generale, per qualunque Object non esiste un metodo contains() nemmeno con un altro nome. Perché il concetto di "contenuto" è particolare e potrebbe non avere senso per certi tipi e il senso/implementazione dipenderebbe comunque dal tipo.

    Quello che servirebbe è un "contratto" tra la tua classe e gli oggetti da trattare.
    Come si stabilisce un "contratto"? In Java si usano generalmente le interfacce.
    Quindi sappi che la tua Idea 2 è molto meno "strampalata" di quanto hai subito immaginato!!!

    La Idea 1 invece non va bene. Perché hai un metodo inserisci(tipo) a cui devi passare un tipo. Anche ammesso di fare sottoclassi ... nella classe base che tipo usi per inserisci()? Object? E poi nella sottoclasse metti un inserisci(TipoSpecifico)? Ma allora non sarebbe un override!!!
    E comunque .... hai 20 tipi .... fai 20 classi???
    No.

    La strada che comunque è più corretta dal punto di vista della OOP è la interfaccia:

    codice:
    public interface Contenibile {
        boolean contiene(Contenibile d);
    }
    contiene() ritorna true se l'oggetto this "contiene" l'oggetto d. Altrimenti false.

    Il tuo metodo inserisci() quindi potrebbe ricevere un Contenibile e già saresti a posto.
    Rimane ancora un problema. Classi diverse possono implementare Contenibile. Come garantisci che al inserisci() non si passi prima un tipo X e poi un tipo Y che non centrano nulla tra di loro??

    Questo purtroppo non si può garantire a livello di compilazione (a meno di usare i generics che in questo senso aiutano). Ma lo puoi controllare a runtime.

    Dove implementi Contenibile, nel contiene() dovrai fare un cast. Se fai una classe Rettangolo, il contiene() deve comunque ricevere un Contenibile. Tu devi fare un cast a Rettangolo di questo argomento, per poter ovviamente fare il test.
    Se l'oggetto non è-un Rettangolo, è corretto lanciare una eccezione ClassCastException (è quello che fa il cast).

    In pratica è la stessa cosa che succede quando si usa Collections.sort() per ordinare un List tramite Comparable o Comparator. Se due oggetti non sono "mutualmente" comparabili il sort non può essere fatto e salta fuori questa eccezione. Che è poi solo dovuta o a un cast diretto o comunque a un test con instanceof (e poi lancio esplicito della eccezione).
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.