Newsgroup: it.comp.java
Titolo: [niubbo] interfacce..

ciao a tutti
sto facendo i primi passi con Java (partendo da buone basi di programmazione 
in altri linguaggi) e mi sono un po' incartato sulle interfacce..
prendendo spunto da un esercizio che ci chiedevano di fare in laboratorio di 
Ingegneria del Software (creare due classi per la creazione di rettangoli e 
quadrati), ho ampliato un po' i listati cercando di sfruttare le interfacce, 
che mi sono per il momento un po' ostiche..
http://freeweb.supereva.com/thd2k3/TestFigure.html
la prima e' ovviamente l'interfaccia, gli altri 3 file solo per la 
costruzione di quadrati, rettangoli e cerchi..
(i metodi sono per lo piu' inutili, ovviamente, ma il testo dell'esercizio 
richiedeva questi..)
mi potete dire se come "idee" ci siamo? ho alcuni dubbi soprattutto sul 
casting degli oggetti..
e' corretto come ho svolto i vari cast?
inoltre, bisognava creare una classe che sfruttasse le varie classi e 
confrontasse le aree delle varie figure inserite dall'utente, scrivendo ogni 
volta qual'e' il piu' grande..
io ho fatto in modo che ogni oggetto creato finisse in un vettore di oggetti 
creato con Vector poligoni = new Vector();, in cui si inserisce in cima al 
vettore (poligoni.add(0,figura);) il poligono con l'area piu' grossa..
ma per ripescarlo, dopo vari inutili tentativi, mi sono dovuto arrendere a 
fare cosi'
((Geometria) poligoni.firstElement()).getArea()
teoricamente ha senso, il vettore poligoni contiene oggetti che vanno 
castati come tipo Geometria (l'interfaccia), proprio perche' non posso 
sapere se quello che sto tirando fuori e' un rettangolo, un quadrato o un 
cerchio.. e devo per forza fare un casting altrimenti il vettore mi tira 
fuori oggetti di tipo Object.. (giusto?)
ma non c'e' un modo per inizializzare il vettore per contenere oggetti di 
tipo Geometria e quindi non dover castare ogni volta tutto?
e soprattutto, per fare questo tipo di casting devo fare un import anche 
dell'interfaccia.. e' normale che si importino le interfacce in questi casi?
scusate la lunghezza ma penso che per sfruttare bene le interfacce bisogni 
capirle totalmente..
bye bye :) 


Con Java 1.5 (Tiger) e uso generics č possibile farlo; nelle versioni
precedenti il casting esplicito č obbligatorio.
Scorpio.

 Perchè hai dichiarato abstract i metodi delle interfacce ?
mi sono confuso con le classi astratte mentre scrivevo l'interfaccia..
pensavo (stupidamente) che i metodi di un interfaccia dovessero essere tutti 
abstract, mentre le limitazioni erano solo negli attributi, che devono 
essere static e final.. ho fatto confusione :)
che il resto sia tutto corretto mi fa piacere :) grazie mille 

 che il resto sia tutto corretto mi fa piacere :) grazie mille
Prego, ma non ho guardato con grande profondità tutto il codice... magari
c'è qualche errore, meno evidente dell'abstract sui metodi dell' interfaccia
Scorpio.

 dell' interfaccia
beh funzionare funziona tutto.. se hai magari solo il tempo di controllare i 
casting.. ho seri dubbi su quelli, per quanto riguarda le interfacce.. cmq 
ti ringrazio in qualsiasi caso :) 

 
http://freeweb.supereva.com/thd2k3/TestFigure.html
mi sembra che tu abbia le idee giuste(a parte i metodi abstract che tu hai
già chiarito :)), l unica cosa che ti voglio far notare è: se hai definito
un interfaccia Geometria, a parte equals che sovrascrive il metodo di Object
perchè nn passi invece di un Object un oggetto di tipo Geometria omettendo
quindi di fare il cast al interno del metodo?

 tipo Geometria omettendo quindi di fare il cast al interno del metodo?
so bene che equals e toString fanno entrambe un override dei metodi di 
Object, ma erano richiesti dall'esercizio.. :) e so anche che l'override di 
toString puo' aver senso, ma equals no, perche' a parte due figure 
*identiche* fare un confronto e' alquanto impossibile.. (a parita' di area e 
perimetro possono esserci miliardi di figure..)
non ho capito per quanto riguarda il casting, dici di mettere dentro le 
interfacce
public boolean haAreaMaggiore(Geometria o);
invece di Object o?
mi sembrava di averci provato e non funzionava.. riprovo e ti dico :) 

 mi sembrava di averci provato e non funzionava.. riprovo e ti dico :)
mica stupida come cosa, in effetti funziona :) grazie mille
sai mica dirmi dove posso trovare esempi di applicazioni di "teoria"? cioe', 
io ora so usare abbastanza le interfacce, pero' per esempio non saprei dove 
potrebbero risultare utili o addirittura *necessarie*.. 

 mi sembrava di averci provato e non funzionava.. riprovo e ti dico :)
intendo questo :)
public interface Geometria {
	public float getArea();
	public float getPerimetro();
	public boolean haAreaMaggiore(Geometria o);
	public boolean haPerimetroMaggiore(Geometria o);
	public boolean equals(Object o);
	public String toString();
}es. Quadrato public boolean haAreaMaggiore(Geometria quad) {
    if (this.getArea() > quad.getArea())
	return true;
    else
    return false;
} public boolean haPerimetroMaggiore(Geometria quad) {    if
(this.getPerimetro() > quad.getPerimetro())
	return true;
    else
	return false;
}che ne pensi? nn ti sembra piu' corretta la  semantica dei due metodi
adesso?viene verificato che un oggetto di tipo geometria sia haAreaMaggiore
o haPerimetroMaggiore rispetto ad un altro oggetto di tipo
Geometria.....oltre naturalmente a evitarti l eventuale ClassCastException a
runtime, in quanto tu nn hai nessun tipo di controllo su che tipo di Object
passi alla funzione....spero di essere stato chiaro...ciauz

 essere stato chiaro...ciauz
chiarissimo, infatti prima ho modificato il tutto e funziona alla grande :)
non l'avevo realizzato cosi' perche' prima, sicuramente per qualche errore, 
non mi funzionava..
ma perche' e' meglio che equals rimanga con Object?
perche' in questo modo quando chiamo il metodo equals di un oggetto 
Geometria devo fare un cast a (Geometria) dell'oggetto con cui confrontarlo?
questo intendi per mantenere la coerenza vero?
scusate se sono cosi' prolisso ma meglio chiarire tutto prima di inoltrarsi 
:) 

 potrebbero risultare utili o addirittura *necessarie*..
l 'esempio che hai fatto tu nn č necessario, ma hai visto come diventi
pulito il codice, le interfacce permettono di separare la tipizzazione degli
oggetti rispetto alla loro implementazione.....cmq per farti un idea dai un
occhiata qui
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
cerca cmq "design pattern java" con google trovi un sacco di giochetti che
si possono fare con interfacce e compagnia.
Parti dalle cose piu' semplici vedrai che ti divertirai un sacco ;)

 ma perche' e' meglio che equals rimanga con Object?
di metodi equals ne puoi scrivere quanti ne vuoi.....con uno o piu'
parametri diversi.....nn è un problema.....
è stata semplicemnte un osservazione leggendo il tuo codice e
l'implementazione che hai dato ad equals..........resta il problema che a
runtime dovrai assicurarti che l oggetto che passi al metodo implementi
Geometria altrimenti otterrai una bella eccezione di
ClassCastException......