Newsgroup: it.comp.java
Titolo: Dubbio sulla OOP

Salve ragazzi,.
Stavo dando un occhiata ai metodi delle classi del package java.util.*,
prese da un libro di Java.
Nell'atto di chiuderlo mi è saltato l'occhio sull'argomento "la
semidefinizione di oggetti ed il loro incapsulamento".
Adesso vi riporto il pezzo (incolla):
"Ogni qual volta che si istanzia un oggetto a partire da una qualsiasi
classe non viene mai creata un entità complessa come ci viene logico di
pensare. 
String str = new String();
Tale dichiarazione in effetti non crea un oggetto stringa ma solo un
riferimento dinamico alla classe String e con tale riferimento essa può
accedere ai metodi e alle variabili contenuti in essa.
Per esempio se voi istanziate 10 oggetti della stesso tipo non vengono mai
duplicate le variabili istanza ma è l'interprete di Java che in fase di
esecuzione le tiene separate permettendo che contengano diversi valori. Per
concludere una dichiarazione di oggetto non crea alcunché, semplicemente
dice di fare riferimento alle definizioni (variabili e metodi) di quella
classe.
[cut]
"
L'incapsulamento come lo intendevo io era la possibilità che ha un oggetto
di mostrare le proprie caratteristiche e personalmente non credo che
coincida con quanto detto sopra.
Ciao a tutti.
PS: Castagna, finalmente sei ritornato. Ma potevi dirlo, ho già mandato in
stampa gli annunci mortuari.:-)
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
J++, la copiatura più riuscita.
Windows, il più instabile.
Visual Basic, un esempio di prodotto decente della MS - forse l'unico -.
OutlookExpress, scandali su scandali.
 

 ha scritto nel messaggio
news:01c06393$b927a7a0$LocalHost@libero...


 
Facendo un doppio errore, però. Non è detto che la virtual machine
utilizzi un "pool" di stringhe, versioni diverse della stessa potrebbero
comportarsi in maniera diversa. Comunque l'incapsulamento c'entra poco:
il pattern in questione è molto simile al "resource pooling" ed ha
qualcosa in comune con "lazy initialization".
In pratica, ogniqualvolta la "creazione" di un oggetto e/o il suo
mantenimento sia particolarmente dispendioso, potrebbe essere
conveneiente tenere un pool di risorse da assegnare man mano al
richiedente. Cosi', se si assegna ad una stringa un valore già esistente
in un'altra, può essere conveniente "condividerlo" fra le varie istanze
e risparmiare heap. 
Cosa succede se cambio il valore di un oggetto? Devo ovviamente creare
un'istanza separata, facendo quello che ho evitato di fare all'inizio:
la dispendiosa creazione dell'oggetto (inizializzazione "pigra", ossia
all'ultimo momento).
Per complicare le cose, le stringhe non possono mai essere variate, e
dunque il problema non sussiste perchè ad ogni apparente variazione
viene in realtà creata una nuova stringa (cosa da tenere in
considerazione per le prestazioni). Quest'ultimo pattern si chiama
"Immutable".
Per chi volesse approfondire, una bella ricerca su "Design patterns" e
passa la paura.
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail:	
ugo.l...@flashnet.it
@work:	
ugo.l...@sun.com
Home Page: 
http://www.ugolandini.net
Home Page: 
http://ugolandini.hypermart.net
 (DNS is changing)
Fax Phone: 06/233207542 
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

infatti puoi usare l'== per fare confronti
Si, ma quello che viene confrontato è il riferimento contenuto nelle
variabili oggetto.

 
Leggi il mio msg precedente per approfondimenti. In effetti funziona
come affermato da Gianni, ma la situazione è un po' più complicata di
quello che sembra.
ciao


quello che sembra.
Non lo avevo notato. Quindi quanto detto precedentemente risulta un non
senso?

 senso?
beh, il codice che hai postato crea in effetti due puntatori allo stesso
oggetto, anche se il tuo discorso fila in generale (non nel particolare
per String). E' un'ottimizzazione della classe String che perň porta il
discorso dell'opeartore == a funzionare e a far decadere la tua
affermazione (ma potrebbe dipendere dall'implementazione: non sono
sicuro che tutte le vm si comportino nello stesso modo).
Comunque, non č mai un buono stile di codifica non utilizzare .equals()
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'č nient'altro da aggiungere, 
 bensě quando non c'č piů niente da togliere." Antoine de Saint-Exupéry


Comunque, non č mai un buono stile di codifica non utilizzare .equals()
Da me il confronto tra i due oggetti sopra creati restituisce false.
Inoltre il mio vecchio libro di Java 1.2 (dato che molte cose che me
ricordo a quasi a memoria) diceva che gli oggetti istanziati con new sono
sempre separati.
Convengo anch'io che se avessi un caso simile a:
String a = new String("ciao");
String b = a;
l'operatore == mi avrebbe restituito true dato che ho fatto la copia del
riferimento e non dell'oggetto, ma questo non mi sembra il nostro caso.
Cmq ringrazio tutti per l'aiuto che mi avete dato.
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
J++, la copiatura piů riuscita.
Windows, il piů instabile.


Ciao,
Per ottenere l'uguaglianza tra due stringhe:
String a = "ciao";
String b = "ciao";
in questo caso (a==b) ritorna true, perché la stringa "ciao" é un'oggetto
conosciuto alla compilazione e quindi é piu' efficace riutilizzarlo,
considerato che é immutabile. Il compilatore crea dunque un pool di stringhe
di questo tipo.
Invece:
String a = new String("ciao");
String b = new String("ciao");
qui (a==b) da' false perché si creano dei nuovi oggetti con new durante
l'esecuzione. Quindi si tratta a tutti gli effetti di due istanze ben
separate. Detto tra noi questo modo di dichiarare le String non é efficace,
anche se piu' OO. Infatti esisteranno 3 instanze in memoria (a, b e "ciao")
con lo stesso valore immutabile, contro una sola instanza dell'oggetto
"ciao" utilizzando la prima tecnica.
bye
Carlo

di questo tipo.
Cavolo, hai ragione.

 Da me il confronto tra i due oggetti sopra creati restituisce false.
sorry non avevo visto il new()... 
usando l'operatore new forzi il compilatore a creare una nuova stringa
comunque. Utilizzando l'assegnamento diretto di una stringa avresti
utilizzato il pool di cui ti parlavo nel post precedente. Spero di non
averti complicato le idee con la mia risposta.
ad esempio prova:
...
String uno = "uno";
String due = "uno";
...
e vedi cosa succede.
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry


e vedi cosa succede.
Che sono lo stesso oggetto. Personalmente non l'avrei mai detto e pensare
che uso le stringhe così tanto. Cmq preferisco allocarle tutte con new()
per questioni di leggibilità e filosofia OOP.
Grazie.