Lawrence

# re: Proprietà e variabili pubbliche

Sì... poi voglio vedere come fai il databinding...

Anche il discorso sulla case-sensitivity è piuttosto fasullo: essa deve servire solo per distinguere membri private dai NON private. Quindi, è CLS Compliant e soprattutto è totalmente trasparente all'utilizzatore della classe. Quindi non vedo la ragione per il "m_" o il "_" di turno, tranne al massimo la comodità di far sì che l'intellisense raggruppi tutti i fields.

Mah...

# re: Proprietà e variabili pubbliche

Ehm Marco. Atwood ha appunto evidenziato la questione del fatto che è la CLS a costringerti ad usare le properties _proprio_ perchè non puoi fare databinding e perchè a livello binario sono due cose differenti. Tutto qui.

# Re: Proprietà e variabili pubbliche

bè... sono totalmente in disaccordo con quanto riporta l'autore, elenca una serie di motivazioni che non condivido affatto. a me basta una considerazione di base per non pubblicare _mai_ un field: se basassi la dipendenza di eventuali consumatori della mia classe sul field, il giorno che dovessi eseguire anche una banalissima validazione sul valore dello stesso dovrei cambiare il codice di tutti i client, invece usando sin da subito la proprierty ho la possibilità in qualsiaisi momento, senza intaccare i client, di eseguire operazioni di validazione (o altro) sul value all'interno della mia classe. rimango d'accordo sul fatto che il codice all'interno di una proprierty deve essere ridotto all'osso altrimenti sarebbe meglio un metodo.
saluti

# re: Proprietà e variabili pubbliche

@Roberto: è proprio il problema evidenziato da Atwood nel suo post. Forse a me che uso linguaggi dinamici il tutto è molto chiaro. In Python ad esempio usualmente si usa un normale attributo dell'istanza, se poi deve diventare qualcosa di "calcolato" lo si tramuta in una property. Ciò non cambia di una virgola il codice client che usa la tua libreria o roba del genere. E' questo tipo di comportamento totalmente differente in .NET che Atwood voleva evidenziare. Per me era chiarissimo, forse non è stato altrettanto chiaro il mio post

# Re: Proprietà e variabili pubbliche

in effetti non ho capito quanto dici che lui intendesse... anche se la prima parte del suo pezzo è abbastanza ingannevole a riguardo, insomma mi sembra abbia usato un panegirico strano per dire quello che voleva dire.
saluti

# re: Proprietà e variabili pubbliche

io l'ho interpretata come una speranza di semplificazione :)

# re: Proprietà e variabili pubbliche

Mah... forse sono io che non ci arrivo...

Secondo me è semplicemente una questione di corretta strutturazione del codice: i fields devono rappresentare lo stato interno di un oggetto, le property, che non sono altro che coppie di metodi, devono fornire punti di accesso all'esterno, per consentire ad esempio una validazione del valore assegnato, come dice anche Roberto.

Detto ciò, quindi, mi sembra ragionevole anche il constraint del databinding che funziona solo sulle proprietà e non sui fields, non la vedo come una forzatura del CLR.

# re: Proprietà e variabili pubbliche

@Marco: per me corretta strutturazione significa semplicemente che se un campo è privato lo si marca come tale e se è pubblico idem. All'utente del mio codice non dovrebbe importare se è un semplice attributo, una proprietà, un attributo creato dinamicamente o vattelapesca. Questa per me è corretta strutturazione del codice. La questione proprietà "dovunque" è semplicemente una interpretazione un pò forzata dell'information hiding IMHO.

Poi alla fine si riduce sempre tutto a questo: http://www.oluyede.org/blog/2006/02/23/freedom-languages/

# re: Proprietà e variabili pubbliche

Ciao Lawrence, nel mio piccolo, concordo con Marco (soprattutto l'ultimo commento) e Roberto.

Viene da chiedersi comunque quale sarebbe il "reale" e "concreto" svantaggio di usare una proprietà rispetto ad un campo pubblico...