Perché nessuno accetta campi pubblici in C #?

Question

Sembra che ogni analizzatore statico C # voglia lamentarsi quando vede un campo pubblico. Ma perché? Sicuramente ci sono casi in cui un campo pubblico (o interno) è sufficiente e non ha senso avere una proprietà con i suoi metodi get_ e set_? Cosa succede se so per certo che non dovrò ridefinire il campo o aggiungerlo ad esso (gli effetti collaterali sono cattivi, giusto?) - Non dovrebbe bastare un semplice campo?

Answer 1

Perché interrompe l'incapsulamento - questo è il motivo per cui la maggior parte delle persone usa pesantemente gli accessori. Tuttavia, se ritieni che sia la soluzione giusta per il tuo compito, ignoralo (nel senso dei rigidi reclami sull'incapsulamento) e fai ciò che è giusto per il tuo progetto. Non lasciare che i nazisti OO ti dicano diversamente.

Answer 2

Si tratta davvero di rendere il codice a prova di futuro. Quando dici (enfatizza il mio):

  

E se lo sapessi per certo che non lo farò   ridefinendo il campo o aggiungendo a   (gli effetti collaterali sono cattivi, giusto?) -   un campo semplice non dovrebbe bastare?

È un'affermazione assoluta, e come sappiamo (così come la maggior parte degli analizzatori statici), ci sono solo due assoluti nella vita.

Sta solo cercando di proteggerti da quello. Se si tratta di un problema, dovresti essere in grado di dire all'analizzatore di ignorarlo (tramite attributi che dipendono dallo strumento di analisi che stai utilizzando).

Answer 3

Dato che l'attuale C # 3.0 consente proprietà automatiche la cui sintassi è simile a:

public int Property {get; set;}

il lavoro extra richiesto per l'utilizzo di Proprietà su campi pubblici è quasi zero. Il fatto è che non puoi mai essere completamente sicuro che un campo non verrà utilizzato in modo diverso o che l'accessor non cambierà mai e dato il compromesso nel lavoro non c'è motivo per non implementare una proprietà.

Comunque, l'analizzatore si lamenta di cose che in alta percentuale (in questo caso come il 99,99% dei casi) sono cattive pratiche di programmazione ... ma comunque si sta solo lamentando. I campi possono essere resi pubblici e ci sono alcuni casi estremi in cui il suo uso diretto può essere giustificato. Come sempre, usa il tuo buon senso ... ma tieni presente la regola elementare per le migliori pratiche di programmazione ... C'è davvero un buon motivo per infrangere la convenzione? Se c'è quindi andare avanti, in caso contrario o se la risposta è " comporta più lavoro " quindi attenersi alla pratica ...

Answer 4

Perché la modifica dei campi pubblici in seguito per ottenere / impostare gli accessori interromperà il codice. Vedi questa risposta per maggiori informazioni

Answer 5

In generale, è una buona idea nascondere i campi dietro le proprietà, anche se " conosci sicuramente " che non ridefinirai il campo. Troppo spesso, ciò che & Quot; sai con certezza & Quot; oggi cambia domani. Inoltre, creare una proprietà per fare riferimento a un campo è solo un po 'problematico.

Detto questo, gli analizzatori statici non possono sostituire il pensiero. Se sei soddisfatto del tuo progetto e secondo il tuo giudizio l'analizzatore è sbagliato, allora ignora o (se possibile) elimina quell'avvertimento in quella circostanza.

Answer 6

Penso che il punto sia che in genere non sai con certezza che non dovrai ridefinire il campo o aggiungerlo in un secondo momento. Il punto fondamentale di incapsulare e nascondere i dati è che sei quindi libero di fare queste cose senza cambiare l'interfaccia pubblica e successivamente rompere le classi dipendenti. Se i tuoi accessori di proprietà sono solo semplici get / sets, saranno comunque compilati in questo modo, quindi non ci sono problemi di prestazioni - dato che la tua domanda dovrebbe essere, c'è qualche buon motivo per non usarli?

Answer 7

Un'altra proprietà che porta benefici alla tabella è quando si fa Reflection. Quando rifletti sulla tua classe, puoi ottenere tutte le proprietà in un colpo solo, piuttosto che dover ottenere le proprietà E i campi.

Answer 8

E non dimentichiamo che gli accessori ti offrono flessibilità quando lavori con più thread.