Corsi di Laurea

[Ale89]

Ora l'unica cosa che non mi è chiara è l'attesa svolta dal listener: secondo me non si tratta di un'attesa, perchè il thread in teoria viene creato solo alla generazione dell'evento. Prima dell'evento esiste solo un oggetto di tipo listener registrato presso un componente grafico, che secondo me non è nient'altro che un collegamento tra il componente ed il brano di codice che solo EVENTUALMENTE deve essere eseguito.

Sei sicuro che il listener eseguito è un thread??? A me sembra che si tratti di una classe la cui istanza( dunque oggetto) viene aggiunta alla lista dei listener di un componente... il Thread è unico ed è quello di sistema che gestisce l'interfacce...

[eferre]

Prova ad associare ad un listener un metodo del tipo "actionPerdormed" il cui corpo ci mette tanto tempo ad essere eseguito, in modo che puoi eventualmente premere di nuovo il bottone sull'interfaccia prima che termini... e vedi cosa accade. Se ti parte di nuovo lo stesso brano di codice allora quelli sono 2 threads.

[Ale89]

Cavolo Enrì non ci avevo pensato ... Bah comunque mi sa ke ci spingiamo troppo oltre!!

PS X evitare brutte figure me ne esco con "In java tutto è un oggetto dunque anche i Thread sono oggetti"

[Di bello Giuseppe]

Se ad un listener è associato un thread allora non c'è nesson problema.
Ho provato a a mettere due for molto lunghi nel listener, ho la netta senzazione che non sono thread.

[Di bello Giuseppe]

E se guardiamo la discendenza di ActionListener, dovrebbe discendere da Thread Giusto?

[Mikelito]

Il thread per l'interfaccia grafica è uno solo e si chiama awt Thread ed è sempre attivo altrimenti se non fosse cosi non vedremo l'interfaccia come una cosa fissa sullo schermo....ora penso che essendo il listener appartenente all'interfaccia grafica,è implicitamente compreso nel thread awt !Un thread per ogni listener secondo me è un casino.......Per me il listener è come gli handler per le eccezioni sta li e aspetta....

[Ale89]

C'e' qualcuno che possa chiudere il topic in modo da evitare che qualche sviluppatore della Sun possa quelerarci!?!

Scherzi a parte secondo me è abbastanza complicato immaginare come vanno le cose.. Ognuno potrebbe dire la sua e dare una motivazione valida.. E' quasi impossibile arrivare a fare nei dettagli quello che hanno fatto decine di persone per decine di anni.. Penso che basti il concetto di S.O. fa polling sul registro di stato trova un interruzione e la comunica alla jvm o meglio al thread x la gestione degli eventi grafici(o come cavolo si chiama ) e poi questo riconosce quale componente ha interagito con l'utente e sceglie quale listener di quel componente "lanciare"...
Va bene cosi??

[Mikelito]

io aggiungerei un'altra cosa,quando la gestione dell'evento viene passata alla jvm questa istanzia un oggetto della classe di cui si è verificato l'evento,questo oggetto viene in qualche modo(non so come)catturato dal listener(o forse passato al listener di competenza direttamente)infatti se notate i metodi dei listener prendono come parametro sempre un oggetto del relativo tipo di evento...quell'oggetto rappresenta il riferimento dell'oggetto istanziato dalla jvm.

[Ale89]

Il meccanismo del "catturare" potrebbe essere quello degli handler nelle eccezioni... Anche li c'e' quel parametro che a dire il vero non ho mai capito cosa rappresenta(ovviamente oltre alla rappresentazione del tipo di eccezione servita)...

[Ale89]

Ps: Io non ho tempo altrimenti l'avrei fatto io... Fate questa prova:

Fate un listener associato ad un pulsante che prende il contenuto di un textfield... Poi a seconda di questo valore gli fate fare due cose diverse, ad esempio se il valore è 0 gli fate solo stampare 0 se è uguale ad 1 gli fate fare un for lunghissimo e poi stampate 1.... Se mandate in esecuzione "tramite il valore in ingresso" prima 1 e poi 0 e vedete che termina prima 0 allora di sicuro si tratta di thread

[eferre]

Questa è la dimostrazione che i listener non sono dei threads, notate come però l'interfaccia sia comunque reattiva (anche se un bottone sembra rimanere premuto):

File allegato

•  NoThread!.zip   5,99K   37 Download

[Ale89]

Ok ... Comunque meglio ke oggi non apro topic altrimenti non ci si arriva vivi a domani!!!

[ildiabolico]

Raga una domanda per un chiarimento:
Il polimorfismo nelle collection oltre che mmm nn so ad assegnare ad un oggetto Set un riferimento di un tipo Hash set o cavoli vari, si può vedere anche nella sovrascrittura a tempo di esecuzione dei metodi delle collezioni come set e list che implementano Collection?
tipo add() remove() etc? toglietemi sto dubbio per gentilezza XD

[eferre]

Raga una domanda per un chiarimento:
Il polimorfismo nelle collection oltre che mmm nn so ad assegnare ad un oggetto Set un riferimento di un tipo Hash set o cavoli vari, si può vedere anche nella sovrascrittura a tempo di esecuzione dei metodi delle collezioni come set e list che implementano Collection?
tipo add() remove() etc? toglietemi sto dubbio per gentilezza XD

Si, però il polimorfismo è sempre rispetto a Collection, non può essere tra metodi di classi che non sono imparentate tra loro.

[f.savarese]

Essendo set un interface, derivata dall' interface collection, mi sembrebbe scorretto parlare di polimorfismo riferito a collection.In realtà i metodi d hashSet o treeset sono diverse implementazioni di una stessa interfaccia, ergo non è polimorfismo ma sono solo classi diverse.Il polimorfismo nelle collection(nei conteiner per essere rigorosi se si becca il prof.Vento:HO avuto brutte Esperienze ) compare solo per quanto rigurda le classi di oggetti che possono essere contenuti in una stesso contenitore, e in quello che diceva ildiabolico riferito a set s= new HashSet()

[ciraso]

Se qualcuno più esperto potrebbe chiarire una volta per sempre questo benedetto polimorfismo nelle collection...magari con un esmpio! Grazie

[eferre]

Anche se il professore non me l'ha chiesto esplicitamente, sono stato io a fargli un esempio per spiegargli il polimorfismo:

Supponiamo di avere una collezione che può collezionare oggetti di tipo Figura e supponiamo che ognuno di questi oggetti sia stato istanziato differentemente con una classe più specifica. Se per ognuno di questi oggetti si chiama la funzione di calcolo dell'area, supponiamo attraverso un'iteratore associato alla collezione, il polimorfismo è quel meccanismo che consente di vedere ognuno di quegli oggetti come dei tipi Figura, ma mantiene traccia dei metodi più specializzati, come ad esempio quello di calcolo dell'area... è tale meccanismo infatti che ci garantisce che tale operazione andrà a buon fine chiamando sempre, per ognuno, il metodo più specifico.

[f.savarese]

Aggiungerei:
Il polimorfismo comunque, per fare questa magia necessita di un altro meccanismo: Identificazioe dei Tipi a Run Time,ossia RTTI.(Per identificazione dei tipi si intende a quale oggetto vogliamo fare il downcast per poter usare il giusto metodo) è questo il meccanismo che x merito del Dinamic Binding permette la scelta del giusto metodo a RunTime e non a CompileTime.
Senza questo Meccanismo il Polimorfismo non avrebbe possibilità di esistere o meglio potremmo avere + metodi con la stessa firma e diversa implementazione ma non sapremmo che farcene, in quanto non potremmo scegliere a RUNTIME quale metodo chiamare.
Ovviamente la conoscenza del funzionamente del RTTI non è parte delle nostre conoscenze ed è giusto che sia così (al momento), Tuttavia è importante avere conoscenza almeno della sua esistenza perchè così, come direbbe Marcelli, capiamo che nulla avviene magicamente, ma c'è sempre qualcosa sotto!!!

[eferre]

Aggiungerei:
Il polimorfismo comunque, per fare questa magia necessita di un altro meccanismo: Identificazioe dei Tipi a Run Time,ossia RTTI.(Per identificazione dei tipi si intende a quale oggetto vogliamo fare il downcast per poter usare il giusto metodo) è questo il meccanismo che x merito del Dinamic Binding permette la scelta del giusto metodo a RunTime e non a CompileTime.
Senza questo Meccanismo il Polimorfismo non avrebbe possibilità di esistere o meglio potremmo avere + metodi con la stessa firma e diversa implementazione ma non sapremmo che farcene, in quanto non potremmo scegliere a RUNTIME quale metodo chiamare.
Ovviamente la conoscenza del funzionamente del RTTI non è parte delle nostre conoscenze ed è giusto che sia così (al momento), Tuttavia è importante avere conoscenza almeno della sua esistenza perchè così, come direbbe Marcelli, capiamo che nulla avviene magicamente, ma c'è sempre qualcosa sotto!!!

L'Ing. Savarese mi sorprende ogni giorno di più...

[ildiabolico]

Grazie per il chiarimento alla fine avevo pensato alla risposta adatta o quasi da dare a quella domanda^^ per il fatto del dinamic/late Bynding era già tutto a posto ma meglio riportarlo sempre perchè di solico ci si dimentica di parlarne ^^ grazie ancora Colleghi^^