Dovresti mai usare privato su campi e metodi in C #?

Solo perché puoi omettere i linefeed e le indentazioni e il tuo compilatore C # capirà ancora cosa vuoi dire, non è automaticamente una buona idea farlo.

using System; namespace HelloWorld{class 
Hello{static void Main(){Console.WriteLine
("Hello World!");}}}

è molto meno leggibile per il umano lettore di:

using System;
namespace HelloWorld
{
    class Hello 
    {
        static void Main() 
        {
            Console.WriteLine("Hello World!");
        }
    }
}

E questo è il punto qui: i programmi sono scritti per due segmenti di pubblico:

• Il compilatore o interprete.
• te stesso e altri programmatori.

Quest'ultimo è colui che ha bisogno di capire e comprendere rapidamente il significato di ciò che è scritto. Per questo motivo ci sono alcune buone pratiche emerse nel corso degli anni e sono quasi-standard più o meno comunemente accettati. Uno di questi sta inserendo parole chiave con ambito esplicito, un altro esempio consiste nel mettere parentesi aggiuntive attorno a espressioni complesse, anche nei casi in cui non sarebbero necessarie sintatticamente, come:

(2 + 5) & 4

C # non è l'unico linguaggio di programmazione per .NET; altre lingue possono avere e hanno accessibilità predefinita diversa in vari contesti. Specificando private si renderà chiaro a chiunque legga il codice che tale accessibilità è intesa, mentre omettere le specifiche lascia aperta la questione se il membro potrebbe essere stato, ad es. inteso per essere utilizzabile all'interno dell'assembly [come sarebbe l'impostazione predefinita in VB.NET]. Essere espliciti può essere particolarmente utile se si utilizzano più lingue con regole diverse.

Per quanto riguarda il fatto che sia preferibile private o protected in assenza di un argomento particolarmente convincente a favore dell'altro, la decisione dovrebbe basarsi sul fatto che sia più probabile che l'esposizione di un membro possa renderlo possibile per una classe derivata fare qualcosa di utile che altrimenti non sarebbe possibile, o che impedirebbe alle versioni future di una classe di modificare le loro strutture di dati interne in un modo che sarebbe più efficiente. Si possono vedere esempi di entrambe le situazioni in List<T> .

In alcuni casi, se uno ha un elenco di aggregati (ad esempio Point strutture) può essere utile aggiornare gli elementi sul posto. Se List<T> ha esposto il suo backing store alle classi derivate, si potrebbe facilmente definire un EditableList<T> con un metodo:

delegate void ActByRef<T1,T2>(ref T1 p1, ref T2 p2);

void ActOnItem<TParam>(int index, ref TParam param, ActByRef<TParam> proc)
{
  .. test index, then...
  proc(ref _arr[index], ref proc);
}

che potrebbe essere invocato usando qualcosa come:

int adjustmentAmount = ...;
myList.ActOnItem(index, ref adjustmentAmount, 
  (ref Point pt, ref int dx) => pt.X += dx );

Un tale metodo potrebbe consentire aggiornamenti efficienti anche con tipi di struttura relativamente grandi [poiché non sarebbe necessaria alcuna copia]. Il fatto che List<T> non esponga i suoi interni rende impossibile ricavare una classe che potrebbe implementare un tale operatore in modo efficiente.

Il rovescio della medaglia, anche se finora so che Microsoft non ha ancora sfruttato questa capacità, avere il backing store privato renderebbe possibile una versione futura di List<T> per dividere il backing store in pezzi più piccoli di 85 K quando si utilizzano la maggior parte dei tipi di dati o meno di 1000 elementi quando si utilizza double . Tale suddivisione non sarebbe possibile se List<T> avesse esposto il backing store alle classi derivate.

Sì dovresti usarlo:) La parola chiave private è usata perché è una pratica generalmente accettata e rimuove tutti i dubbi sull'ambito previsto di un membro della classe.

La leggibilità è molto importante con il codice, specialmente quando si lavora in una squadra. Se si desidera esaminare ulteriormente la leggibilità del codice, un buon libro di riferimento che posso raccomandare è Gli elementi di stile C # .

Domanda:

"Dovresti mai usare privato su campi e metodi in C #?"

Risposta rapida:

Sì, ma dipende dalla logica del codice.

Risposta estesa a lunga noia:

Suggerisco di specificare sempre la fruibilità per i membri.

Penso che sia un buon approccio per dichiarare i membri, per impostazione predefinita, come "privato".

Nel mondo reale, uso "protetto", invece.

Prima o poi, quel membro nascosto, potrebbe essere usato da una sottoclasse.

A volte, una buona domanda, può essere una risposta migliore, ponendo la domanda opposta.

La domanda opposta, alla tua domanda, potrebbe essere qualcosa di simile:

"Devo usare sempre il modificatore di accesso pubblico sui campi e sui metodi in C #"

In altri linguaggi di programmazione puoi "promuovere" protetto per il pubblico, a seconda del tuo design.

Uso molte librerie di gerarchia profonda (visiva) di controllo, dove, alcuni membri (proprietà, methos) sono richiesti.

A volte, è meglio renderle pubbliche, a volte no.