Newsgroup: it.comp.java
Titolo: getter/setter o variabile public?

[ESEMPIO 1]
public class persona
{
 private String nome;
 private String cognome;
 private int eta;
 // Costruttore
 // Getter e Setter
}
[ESEMPIO 2]
public class persona
{
 public String nome;
 public String cognome;
 public int eta;
 // Costruttore
}
Come mai non si fa praticamente mai uso di variabili public ma si creano 
sempre geter/setter? In questo esempio non ce ne sarebbe bisogno (cioč 
esempio2 funziona bene tanto quanto esempio1, giusto?)
Mi spiego....se non devo compiere operazioni sull'assegnazione/ritorno di 
valori dalle variabili di istanza (tipo portare il nome tutto maiuscolo) non 
e' piu' efficiente/meno "verboso" non utilizzare i metodi getter/setter? 

usa sempre la variabile privata con i getter e setter pubblici come da
specifica javabean.
-- 
Davide Consonni

 ai get/set.
E su questo sono perfettamente d'accordo, ma in termini "prestazionali" 
accedere direttamente alla variabile piuttosto che utilizzare un metodo come 
tramite e' piu' efficiente? 

 specifica javabean.
Sempre contro le regole!!!!!
(scherzo! :) )

 tramite e' piu' efficiente?
C'è un clock in meno ad accedere direttamente, ma avendo per le mani  
applicazioni di centinaia di mega d'occupazione, non credo che un clock in  
più o in meno faccia la differenza.
Senza contare che l'indirettezza porta numerosi vantaggi
-- 
Mail to: anforagimailpuntocom²
http://www.hostingjava.it/-SaThot/mail/me

 sempre geter/setter? 
perchè questa è la convenzione per le properties dei java bean.
esporre i membri della classe non è la stessa cosa di definire delle 
properties, tant'è che se da specifica ti chiedessi di rendere una di 
quelle proprietà read-only tu non potresti farlo (ad esempio).
-- 
? Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

tramite e' piu' efficiente? 
Programmi in Java e ti preoccupi delle prestazioni? :-)
I tempi si allungano - a meno di ottimizzazioni di cui non sono al
corrente - nell'accedere mediante getter()/setter(). In altri
linguaggi esiste una parola chiave (inline) che annulla di fatto
questa differenza. Ma sono appunto quei linguaggi che si scelgono
quando si ha necessitą di buone performance.

 quando si ha necessità di buone performance.
Le performance non sono (solitamente) peggiori, in quanto
l'ottimizzatore java fa automaticamente l'inline se il corpo del
metodo è banale, come per il 99% dei getter e dei setter. Scrivo
solitamente proprio peché è una feature dell'ottimizzatore, quindi se
non usi il compilatore sun, in teoria potresti non avere questa
ottimizzazzione, ma credo che in realtà ce la abbiano tutti,,,,

metodo è banale, come per il 99% dei getter e dei setter.
Infatti lo sospettavo. Quello che mi chiedo è come faccia
l'ottimizzatore a riconoscere che è un getter()/setter()...
In base a convenzioni di nome?

 specifica javabean.
si, o ancora meglio solo un getter, non ci deve per forza sempre essere 
anche il setter (si puo' settare nel costruttore ed avere la classe come 
immutable).
Tommy

Tommy wrote:

questo credo dipenda da caso a caso ..
-- 
Davide Consonni

immutable).
..stai parlando probabilmente di un 10% delle esigenze. In generale, è
molto improbabile che se c'è un getter, non serva un setter.

 In base a convenzioni di nome?
probabilmente fa l'inline se il metodo e' piu' piccolo di un tot.
Ciao Jack

On Jun 18, 12:54 am, Andrea Laforgia

mah. Direi che puo' capitare spesso. Ad esempio la classe Rettangolo,
avra' i setter di lunghezza e larghezza, ma di area o di diagonale
avra' solo il getter.
Ciao Jack


Concordo. Addirittura ci sono dei casi in cui è appropriato solo il
setter (sono rari, ma mi è capitato...).



che palle, possono servire tutti e due o no, non è che vi dovete mettere a
trovare il capillo ogni volta XD
(in tono scherzoso)
-- 
Davide Consonni


wrote:

mmhh, e' che non abbiano un cazzo da fare... :)
Ciao Jack

 mah. Direi che puo' capitare spesso.
Non mi devi fare esempi, non sto dicendo che NON può capitare. Sto dicendo
che non capita SPESSO di dover usare solo il getter. Non si può dire:
"ancora meglio non usare il setter", perché si sottolinea una regola
generale, cosa ben lontana dalla maggioranza dei casi. 
Per Davide: non è che ogni volta si voglia spaccare il capello in quattro,
ma è che di fronte a certe affermazioni non si può far a meno di
controbattere, sopratutto per il bene di chi ha posto la domanda
inizialmente.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 probabilmente fa l'inline se il metodo e' piu' piccolo di un tot.
Questo, semmai, è un problema successivo. La regola che citi può valere
quando si ha una keyword (come in C++) che suggerisce l'inline. Il
compilatore, a sua sola discrezione (i.e.: tra le tante cose, se il codice
non è troppo grande), può espandere in loco o generare una call. Se fosse
come dici, in Java dovrebbe valere la regola per tutti i metodi, perché
non c'è modo, formalmente, di distinguere tra un getter/setter e un metodo
qualsiasi. Il problema è a monte: come fa l'ottimizzatore a capire che si
tratta di un getter e quindi valutare l'espansione inline? dovrebbe
intervenire solo sul nome del metodo, il che mi sembra abbastanza
astruso...
Inoltre: se in Java TUTTI i metodi sono virtuali, l'espansione inline
cozza parecchio, per ovvi motivi...



Certo dipende, ma è bene sapere che il piu' delle volte puoi 
riprogettare una classe con getter/setter in una classe con immutabile 
con soli getter. Le classi immutable sono molto piu' facili da usare in 
ambiente multithreading.
-- 
Andrea Francia
http://www.andreafrancia.it/

ambiente multithreading.
Se non scrivi mai, è ovvio che è più facile lavorare in ambiente MT.
Non è vero che "il più delle volte" una classe con getter/setter si
può riprogettare come immutabile, perché non è vero che "il più delle
volte" è richiesto/consentito che la classe sia immutabile.

 volte" è richiesto/consentito che la classe sia immutabile.
Le seghe mentali sul fatto che sia il più delle volte, o una parte delle 
volte le lascio a chi ha voglia di farsele.
Le stringhe per esempio all'inizio puoi pensare di doverle implementare 
come oggetti mutable, poi ti accorgi che puoi implementarle come immutable.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/macross-frontier.html

 quelle proprietà read-only tu non potresti farlo (ad esempio).
In piu' molti framework e librerie richiedono che le proprietà siano 
definite con la convenzione JavaBean (ad esempio beansbinding).


volte le lascio a chi ha voglia di farsele.
Veramente finora tu sei proprio uno di quelli che ha detto "il più
delle volte". Io sto proprio invitando a non farsi seghe mentali; sto
dicendo, infatti, che non è "il più delle volte" così, senza entrare
nello specifico di quando è così o non è così.

 ugualmente necessarie.
Il bello delle classi immutable è che sono thread safe senza dover fare 
sincronizzazioni.
Se la classe ha solo getter ma è non immutable è ovvio che le 
sincronizzazioni ci vogliono.


sincronizzazioni.
E' ridicolo pensare di poter usare sempre (o nella maggior parte dei
casi) classi immutable. Quando parli di stringhe, non dici che per
farci qualcosa di minimamente utile, devi usare uno StringBuffer. 

 farci qualcosa di minimamente utile, devi usare uno StringBuffer. 
Va bene, la classe java.lang.String è praticamente inutile, chissà cosa 
l'han messo a fare?


 molto improbabile che se c'è un getter, non serva un setter.
In Java le immutable sono invece piuttosto frequenti (Long, Integer, Short, 
Boolean, BigInteger, BigDecimial, String, etc...).
Ad ogni modo so bene che non tutte le classi possono essere immutable, ma 
quando questo e' possibile e non ha effetti collaterali, bisognerebbe 
cercare di rendere le classi immutable.
In C++ le cose sono diverse in quanto puoi avere sia getters che setters e 
poi puoi fare in modo che il setter non venga chiamato su oggetti consts (o 
tramite const&). In java questo non esiste e quindi fare classi immutable 
diventa una cosa piuttosto importante.
Tommy

 questo credo dipenda da caso a caso ..
certo, questo lo davo per scontato.... mah!
intendevo dire che quando la classe puo' essere immutable e' bene renderla 
immutable e non metterci per forza il setter. Noto che molti li mettono 
sempre in coppia anche quando non e' necessario, anche quando la classe 
dovrebbe essere immutable.
Tommy

 generale, cosa ben lontana dalla maggioranza dei casi.
Si puo' dire se uno la sa leggere nel modo giusto:
se la classe puo' essere immutable, ancora meglio sarebbe non avere proprio 
il setter e renderla immutable.
La linea guida generale di rendere le classi immutable quando possible e' 
una ottima linea guida.
Tommy

 ugualmente necessarie.
ma nella stra-grande maggior parte dei casi non e' affatto richiesto, mentre 
la sincronizzazione e' *quasi* sempre richiesta quando si cambia lo state 
dell'oggetto.
Tommy

 farci qualcosa di minimamente utile, devi usare uno StringBuffer.
StringBuilder se possibile...
E' abbastanza comune avere una classe mutable (StringBuilder) usata per 
costruire una classe immutable (String). In questo modo puoi passare in giro 
una istanza della classe immutable (sicura) ma fare operazioni locali 
costose sulla classe mutable (piu' efficiente).
In altri casi una classe immutabe basta ed avanza anche senza il suo 
builder.
Ti consiglio di leggerti effective java (e' appena uscita la seconda 
versione). In alternativa ti consiglio di leggere qualche buon articolo su 
google. Come gia' ho scritto nell'altro post, so che tu conosci bene il C++. 
In C++ ti crei una istanza normale (mutable) e poi la passi in giro come 
const&. In java non lo puoi fare, quindi si usano le classi immutable per 
assicurarti che i metodi che chiami e gli altri threads non cambino lo state 
del oggetto. Poi la discussione non si limiterebbe a questo esempio....
Tornando ad effective Java 2nd edition... Item 15 dice:
Item 15: Minimize mutability
...
Immutable classes are easier to design, implement and use then mutable 
classes. They are less prone to errors and more secure.
...
An immutable object can be exactly in one state, the state in which it was 
created.
...
Immutable objects are inherently thread-safe; they require no 
syncrhonization. They cannot be corrupted by multiple threads accessing them 
concurently. ... Therefore immutable objects can be shared freely.
...
A consequence of the fact that immutable objects can be shared freely is 
taht you never have to make defensive copies. In fact, you never have to 
make any copies at all......
...
Immutable objects make great building blocks for other objects.
...
To summarize, resist the urge to write a set method for every get method. 
Classes should be immutable unless there's a very good reason to make them 
mutable.
....
Di questo l'ultima frase dice quello che avevo detto io e che e' stato 
criticato:
To summarize, resist the urge to write a set method for every get method. 
Classes should be immutable unless there's a very good reason to make them 
mutable.
No?! Questo e' quello che penso Io, Joshua Bloch e la community Java in 
generale. Se poi la pensi diversa il mondo e' bello perche' e' vario!
Tommy

 molto improbabile che se c'è un getter, non serva un setter.
Come ho scritto in un altro post, leggiti effective java 2nd edition, item 
15:
"To summarize, resist the urge to write a set method for every get method. 
Classes should be immutable unless there's a very good reason to make them 
mutable."
Non mi sembra di aver detto nulla di diverso.
Tommy

 state dell'oggetto.
mi sono dimenticato di aggiungere che io non dicevo solo di non mettere il 
setter ma di rendere, quando possibile ed indicato, la classe immutable. Se 
la classe e' immutable, la sincronizzazione non dovrebbe essere richiesta.
certo che se non metti il setter, ma il getter ti ritorna un mutable 
internal object che puoi cambiare di state allora non hai una classe 
immutable e quindi ti serve la sincronizzazione.
Il mio messaggio diceva:
"si, o ancora meglio solo un getter, non ci deve per forza sempre essere
anche il setter (si puo' settare nel costruttore ed avere la classe come
immutable)."
rendendo chiaro che consigliavo di rendere la classe immutable (quando 
indicato) e non solo di non mettere il setter.
Tommy

 cozza parecchio, per ovvi motivi...
Beh, ribadisco che l'espansione inline la può benissimo fare il JIT,
dopo il binding...
Inoltre potresti rendere il metodo final, questo non dovrebbe porre
problemi per il binding.