Newsgroup: it.comp.java
Titolo: Garbage Collector e

Se e' una questione da polli insultatemi pure, ma per favore datemi una 
dritta.
Se ho capito bene quando un oggetto non e' piu referenziato il GC provvede
a recuperare la memoria dello stesso (se non subito, prima o poi)
Per cui ...
   Paperino istanza1 = new Paperino();
Adesso l'oggetto della classe Paperino e' referenziato.
   istanza1 = null;
Adesso l'oggetto non e' piu' referenziato e il GC puo' recuperare la ram
Giusto ????
Se e' giusto andiamo avanti, poniamo le due classi seguenti
class Pippo
{
   private Max mx;
   public Pippo()
   {
   ...
   mx = new Max(this);
   }
}
class Max
{
   private Pippo pp
   public Max(Pippo p)
   {
      pp = p;
   }
}
A queso punto come per sopra...
   Pippo istanza1 = new Pippo()
Adesso l'oggetto della classe Pippo e' referenziato, ma
   istanza1 = null;
Non e' sufficente per permettere al GC si recuperare la ram in quanto
ho ancora pp che referenzia l'istanza.
Giusto ????
Se e' giusto che sistema posso usare per permettere a Max di accedere ai
metodi di Pippo senza incorrere nell'inconveniente ?
Se non e' giusto dove e' l'errore ?
Grazie a chi mi dedichera' del tempo.
-- 
Stefano L.

 Giusto ????



-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 metodi di Pippo senza incorrere nell'inconveniente ?
????
Puoi chiarire meglio?


 Puoi chiarire meglio?
Un metodo di Max ha bisogno di conoscere dei dettagli sullo stato di Pippo
per agire correttamente, non posso passargli questi dati come argomenti 
quando eseguo new Max(....) poiche' essi possono variare in seguito.
Il sistema migliore mi sembra quello di passare a Max il riferimento di 
Pippo in modo che posssa, tramite dei metodi get...(), consultare questi 
dati quando gli occorre.
In pratica Pippo e' una sottoclasse di JTextField mentre Max e una 
sottoclasse di PlainDocument.
Ora Max deve conoscere alcuni dettagli sullo stato di Pippo per decidere
nel suo metodo insertString se accettare o meno l'input.
Non mi sembra una situazione tanto strana, un altro esempio potremme essere 
costituito dalle due classi
   OrdineCliente e RigaOrdine
OrdineCliente esegue
   RigaOrdine riga1 = new RigaOrdine(...)
   RigaOrdine riga2 = new RigaOrdine(...)
   RigaOrdine riga3 = new RigaOrdine(...)
   ...
   RigaOrdine rigaN = new RigaOrdine(...)
Un metodo di RigaOrdine calcola il proprio valore ma per fare questo
ha bisogno di conosere la % di sconto e il listino che sono memorizzati
una sola volta in OrdineCliente.
In sintesi una classe usata puo' variare il suo comportamento in base a
dettagli della classe che la usa.
Sono nuovo alla OOP e forse esiste un approccio diverso per implementare 
queste situazioni, che mi dici ?
Grazie.
-- 
Stefano L.

 qual è in questo caso l'inconveniente?
Temevo fosse quello di rendere ''eterne'' le istanze delle classi impedendo
al GC di eliminarle quando non piu' necessarie.
-- 
Stefano L.

 queste situazioni, che mi dici ?
Di solito questo design e' sconsigliato, in quanto accoppia troppo
strettamente le due classi, mentre di solito e' desiderabile un basso
accoppiamento per poter sostituire le classi in caso di necessita'.
Ad esempio, in questo caso la dipendenza di RigaOrdine da OrdineCliente
puo' essere eliminata assegnando opportunamente le responsabilita' di
calcolare il prezzo scontato e quella di conoscere il listino.
La prima (prezzo scontato): se lo sconto e' assegnato al singolo ordine e'
quindi conosciuto dall'oggetto della classe OrdineCliente. Allora si
potrebbe far calcolare a RigaOrdine il prezzo non scontato e lasciare a
OrdineCliente l'onere di applicargli lo sconto (che probabilmente deve
essere applicato al totale piu' che alla singola riga, ma comunque e' una
responsabilita' di OrdineCliente).
La seconda (conoscenza del listino): se il listino e' unico (cioe' non e'
legato al singolo ordine), non e' responsabilita' di OrdineCliente
mantenerne la conoscenza, quindi RigaOrdine non lo deve richiedere a
OrdineCliente, ma probabilmente alla classe Listino stessa, implementata
come singleton. Se invece il listino e' veramente specifico per ogni
ordine, allora sara' responsabilita' della classe OrdineCliente calcolare
il prezzo delle singole righe (che invece avranno solo la responsabilita'
di fornire il tipo di prodotto e la sua quantita'), oppure (forse meglio)
fornire alla classe RigaOrdine le informazioni (solo quelle strettamente
necessarie, non il listino) per poter calcolare il valore, passandole nel
momento in cui il calcolo viene richiesto (in pratica passando il prezzo
come parametro).
Nota che con questo design la classe RigaOrdine non dipende dalla classe
OrdineCliente e quindi puo' essere riutilizzata in tutti i contesti in cui
puo' servire, senza la necessita' di portarsi dietro anche la classe
OrdineCliente. Inoltre la classe OrdineCliente puo' essere
modificata e sostituita piu' facilmente, dato che non deve piu' soddisfare
le dipenenze richieste precedentemente dalla classe RigaOrdine.
-- 
Lucio Benfante
Java User Group Padova: 
http://www.jugpadova.it
Brainbench MVP for Java 1: 
http://www.brainbench.com
MyTranscript: 
http://www.brainbench.com/transcript.jsp?pid=167064

 ha scritto nel messaggio
news:cD75b.286213$Ny5.8...@twister2.libero.it...
