Sono protetti soci / campi davvero così male?

Question

Ora, se si leggono le convenzioni di denominazione in MSDN per C # si noterà che si afferma che le proprietà sono sempre preferito su campi pubblici e protetti. Mi è stato anche detto da alcune persone che non si dovrebbe mai usare i campi pubblici o protetti. Ora sono d'accordo devo ancora trovare un motivo in cui ho bisogno di avere un campo pubblico, ma sono campi protetti davvero così male?

I può vedere se è necessario fare in modo che certi controlli di convalida vengono eseguite quando ottiene / impostazione del valore comunque un sacco di tempo sembra che solo in più in testa a mio parere. Voglio dire Diciamo che ho un GameItem classe con campi per baseName, prefixName e suffixName. Perché dovrei prendere la testa di entrambi creare le proprietà (C#) o metodi di accesso e la prestazione ha colpito mi sarebbe verificato (se faccio questo per ogni singolo campo in un'applicazione, sono sicuro che sarebbe aggiunge fino a meno di un po 'particolare in alcune lingue come PHP o certe applicazioni con prestazioni è fondamentale come i giochi)?

Answer 1

  

Sono protetti soci / campi davvero così male?

No. Sono molto, molto peggio.

Non appena un utente è più accessibile di quanto private, si stanno facendo garanzie ad altre classi di come quel membro si comporterà. Dal momento che un campo è del tutto incontrollata, mettendolo "in the wild" apre la classe e le classi che ereditano da o interagire con la classe di rischio più elevato di bug. Non c'è modo di sapere quando un campo cambia, non c'è modo di controllare chi o che cosa cambia.

Se la società, o ad un certo punto, in futuro, qualsiasi del codice mai dipende da un campo un po 'di certo valore, è ora di aggiungere controlli di validità e la logica di fallback nel caso in cui non è il valore atteso - ogni luogo lo si utilizza . Questo è un enorme quantità di sforzo sprecato quando si potrebbe hai appena fatto una proprietà maledetto invece;)

Il più modo di condividere le informazioni con le classi derivate è il proprietà di sola lettura :

protected object MyProperty { get; }

Se è assolutamente sono per renderlo di lettura / scrittura, non lo fanno. Se davvero, hanno veramente a rendere lettura-scrittura, ripensare il vostro disegno. Se hai ancora bisogno di essere in lettura-scrittura, scusarsi con i tuoi colleghi e non farlo di nuovo:)

Un sacco di sviluppatori credono - e vi dirà - che questo è troppo rigida. Ed è vero che si può cavarsela bene senza essere questo rigoroso. Ma questo approccio vi aiuterà a passare da solo arrangiarsi al software straordinariamente robusto. Si spenderà molto meno tempo correggere i bug.

E per quanto riguarda eventuali problemi di prestazione - non lo fanno. Vi garantisco che non sarà mai, in tutta la tua carriera, scrivere il codice così velocemente che il collo di bottiglia è la chiamata stack di sé.

Answer 2

OK, il tempo downvote.

• Prima di tutto, le proprietà saranno le prestazioni mai male (a condizione che non fanno molto). Questo è ciò che chiunque altro dice, e sono d'accordo.

• Un altro punto è che le proprietà sono buone in quanto è possibile inserire punti di interruzione in loro per la cattura di ottenere / impostare eventi e scoprire da dove vengono.

Il resto degli argomenti mi preoccupa in questo modo:

• Suonano come "argomento dal prestigio". Se MSDN dice, o qualche famoso sviluppatore o autore che piace a tutti, dice, è deve essere così.

• Si basano sull'idea che le strutture di dati hanno un sacco di stati incoerenti, e devono essere protetti contro vagare o della messa in quegli stati. Dal momento che (mi sembra) strutture di dati sono il modo troppo enfatizzata nell'insegnamento corrente, quindi tipicamente hanno do hanno bisogno di quelle protezioni. Molto più preferibile è quello di minimizzare struttura dati in modo che esso tende ad essere normalizzato e non avere stati incoerenti. Quindi, se un membro di una classe viene modificato, viene semplicemente modificate piuttosto danneggiato. Dopo tutto, in qualche modo un sacco di buon software è stato / è scritto in C, e che non hanno sofferto in maniera massiccia dalla mancanza di protezioni.

• Si basano sulla difensiva codifica portato agli estremi. Essa si basa sull'idea che le tue lezioni saranno utilizzati in un mondo in cui il codice di nessun altro si può fidare di non oca tua roba. Sono sicuro che ci sono situazioni in cui questo è vero, ma ho mai visto. Quello che sono visto è situazioni in cui le cose sono state fatte terribilmente complicato per aggirare le protezioni per i quali non c'era bisogno, e cercare di custodire la consistenza di strutture di dati che sono stati orribilmente troppo complicato e non normalizzata .

Answer 3

Per quanto riguarda i campi vs. proprietà, posso pensare a due ragioni per preferendo proprietà nell'interfaccia pubblica (protetta è anche pubblico, nel senso che qualcun altro non solo la vostra classe può vederlo).

• L'esposizione proprietà ti dà un modo per nascondere l'implementazione. Esso permette anche di cambiare l'implementazione senza modificare il codice che l'utilizza (ad esempio, se si decide di cambiare il modo in cui i dati vengono memorizzati nella classe)

• Molti strumenti che lavorano con le classi che usano la riflessione concentrarsi solo sulle proprietà (ad esempio, penso che alcune librerie per il lavoro di serializzazione in questo modo). Uso delle proprietà rende sempre più facile da usare questi strumenti .NET standard.

Per quanto riguarda le spese generali:

• Se il getter / setter è la solita linea di un pezzo di codice che legge semplicemente / imposta il valore di un campo, poi il JIT dovrebbe essere in grado di inline la chiamata, quindi non c'è overhad prestazioni.

• sintattica testa è in gran parte ridotta quando si utilizza le proprietà implementate automaticamente (C # 3.0 e successive), quindi non credo che questo è un problema:

  protected int SomeProperty { get; set; }
  

  In realtà, questo ti permette di fare per esempio set protetto e get pubblico molto facilmente, quindi questo può essere ancora più elegante rispetto all'utilizzo di campi.

Answer 4

pubblica e / o campi protetti sono cattivi perché possono essere manipolate dall'esterno della classe dichiarando senza convalida; così si può dire per rompere il principio incapsulamento della programmazione orientata agli oggetti.

Quando si perde l'incapsulamento, si perde il contratto della classe dichiarare; Non si può garantire che le si comporta di classe come previsto o previsto.

Utilizzo di un immobile o di un metodo per accedere al campo consente di mantenere l'incapsulamento, e rispettare il contratto della classe dichiarare.

Answer 5

Sono d'accordo con la risposta proprietà di sola lettura. Ma per giocare l'avvocato del diavolo, in realtà dipende da quello che stai facendo. Sarò felice di ammettere che scrivere il codice con i membri pubblici per tutto il tempo (anche io non commento, seguire le linee guida, o una qualsiasi delle formalità).

Ma quando sono al lavoro, che è una storia diversa.

Answer 6

E 'in realtà dipende se la classe è una classe di dati o di una classe di comportamento.

Se mantenere il vostro comportamento e dati separati , è bene esporre i dati dei vostri dati classi, fino a quando non hanno un comportamento.

Se la classe è una classe comportamento, allora non dovrebbe esporre tutti i dati.