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).