Blocco dell’accesso alle variabili dei membri privati? Uso forzato delle proprietà pubbliche?

Sto usando .NET 2.0 quindi non ho accesso alle proprietà automatiche. Quindi devo ricorrere al seguente modo di codificare variabili private e proprietà pubbliche

private string m_hello = null; public string Hello { get{return m_hello;} set{m_hello = value;} } 

Per i metodi della class contenente dei membri privati ​​/ pubblici di cui sopra, c’è comunque un modo per limitare l’accesso alla variabile privata? Non mi piace che io possa usare m_hello o Hello.

Grazie.

No, non c’è un modo per farlo, oltre a seguire semplicemente la tua convenzione e farlo. Salve se hai davvero bisogno di passare attraverso la tua proprietà pubblica.

Non vedo il motivo per cui avresti bisogno / voglio farlo, dato che è la tua class interna, sei tu a controllare il codice e puoi definire cosa / come viene utilizzato, quindi non dovrebbe esserci un problema.

Come altri hanno suggerito, questa dovrebbe essere una risposta …

Puoi ancora utilizzare le proprietà automatiche in C # 3 quando esegui il targeting su .NET 2.0, insieme a molte altre funzionalità del C # 3 . A differenza degli alberi di espressione (ad esempio), le proprietà automatiche non richiedono nulla di speciale dal CLR o dal framework, oltre all’attributo [CompilerGenerated] (introdotto in .NET 2.0).

Quindi se stai usando VS2008 o VS2010, allora varrebbe la pena usare una proprietà automatica.

Per quello che vale però, mi piacerebbe anche questa abilità. Mi piacerebbe essere in grado di gestire le variabili all’interno di una proprietà:

  public string Name { private string name; get { return name; } set { name = value; } } 

Considero questo un po ‘come rendere una variabile privata a sola lettura – non fa alcuna differenza per i client, ma aiuta a far rispettare la correttezza all’interno del codice di class stesso.

Puoi farlo attraverso l’ereditarietà:

 abstract class A // A is not instantiatable due to being abstract { private string m_hello = null; public string Hello { get{return m_hello;} set{m_hello = value;} } } class B : A { // B now cannot access the private variable, use B in your code instead of A } 

Non sto affermando che questo è buono. Solo che può essere fatto.

No. Qualsiasi metodo all’interno della class avrà accesso ad entrambi.

La tua squadra dovrebbe standardizzare su quale usare (proprietà o variabile privata).

Una volta deciso quale usare, potresti provare a utilizzare una regola FxCop personalizzata per far rispettare lo standard.

No, fondamentalmente. Bene, si potrebbe fare qualcosa con gli avvertimenti del compilatore tramite [Obsolete] e #pragma , ma sarebbe eccessivo.

Probabilmente potresti farlo con strumenti, ma alla fine devi avere fiducia nelle persone per non fare cose stupide. Dopotutto, hai delle regole speciali su:

 while(true) { } 

o lo metti solo per “non essere stupido”? ; p

È necessario accedere alla proprietà solo tramite la proprietà pubblica Hello. Questa è la ragione per questo modello. Se si aggiunge una funzionalità al get o al set, se si accede all’istanza privata, si introdurranno errori nel codice. Ma la risposta è NO, non puoi impedire a qualcuno di chiamare il Privato quando si trova all’interno della tua class cambiando il tuo codice.

Personalmente, non vedo nulla di sbagliato nell’accedere al membro privato all’interno della class. In effetti questo è quello che faccio di solito (a meno che non ci sia la logica all’interno del getter / setter della proprietà che voglio sempre sfruttare).

Ha senso per me: il codice all’interno della class costituisce l’implementazione di quella class; perché hide un’implementazione da se stessa?

Ecco un esempio di cosa intendo. Supponiamo che io abbia un membro, m_denominator , e voglio che non sia mai zero:

 private int m_denominator = 1; public int Denominator { get { return m_denominator; } set { if (value == 0) throw new ArgumentException("Denominator must not be zero."); m_denominator = value; } } 

Potrei dire a me stesso: “OK, ovunque imposti questo valore all’interno di questa class, dovrei usare Denominator per assicurarmi che non lo imposti a zero”. Ma ho completamente il controllo di ciò che sto Denominator a Denominator – Sono dentro la class! In questo scenario, il punto della logica nella proprietà Denominator è proteggere la class dai valori non validi impostati dal codice client. Non ci sono scuse per impostare lo stato interno su un valore non valido all’interno dell’implementazione di una class stessa.

Ovviamente questa non è una regola assoluta. Ci sono sicuramente momentjs in cui l’uso della proprietà per la sua logica all’interno di una class può essere una scelta sensata come misura protettiva; in realtà, sto solo sostenendo che non è sbagliato accedere ai membri privati ​​all’interno di una class.

Se ti ritrovi a voler hide i dettagli da te stesso, potrebbe essere un odore di codice che la tua class ha troppe responsabilità. Prendi in considerazione l’estrazione di una delle responsabilità in una nuova class.