jankyBlog

"e quindi, secondo lui

Fattura1.Cliente.RagioneSociale = Fattura2.Cliente.RagioneSociale;
sarebbe meno leggibile di:
Fattura1.getCliente().setRagioneSociale(Fattura2.getCliente().getRagioneSociale());
bah...contento lui! :-)"

E' cmq la stessa cosa che se non sbaglio sostiene il Richter nel suo CLR via C#, che aggiunge pure che fosse per lui le proprietà le farebbe sparire dal C#...
Anche a me all'inizio ha fatto specie, ma Richter dice proprio quello, cioè che è concettualmente sbagliato e fuorviante chiamare dei metodi come se fossero variabili.

Beh, il merito maggiore che hanno le properties è proprio quello di riuscire ad esporre verso l'esterno lo stato dell'oggetto in maniera "controllata" senza per questo perdere in leggibilità.

E se il getter e il setter di una property sono "semplici", francamente nn vedo alcuna controindicazione al loro utilizzo, se questo è fatto con un certo senno; è vero, sono pur metodi, ma son metodi "particolari", che spesso vanno a coppie e che sono utilizzati prettamente per modificare lo stato interno di un oggetto:
Fattura1.Cliente
è qualcosa di profondamente diverso da
myStream.Write(..)
o da
thisAwesomeThread.Start();

Morale: il mio punto di vista è opposto... Più che pensare alla proprietà come un metodo con una sintassi un po' particolare, mi piace pensare ad essa come un qualcosa di diverso, che il compilatore poi fa digerire al CLR utilizzando una coppia di metodi in IL. E poi le Dependency Properties di WPF non sarebbero la stessa cosa se non ci fossero le proprietà ;-)