Best practice sull'uso locale del campo privato x Proprietà

StackOverflow https://stackoverflow.com/questions/833047

Domanda

Quando all'interno di una classe hai un campo privato ed esponi quel campo su una proprietà pubblica, quale dovrei usare dall'interno della classe?

Di seguito è riportato un esempio di ciò che sto cercando di scoprire. Dovrebbe gestire il campo privato _Counter o il contatore proprietà?

Test di classe pubblica 

Private _Counter As Integer

Public Property Counter() As Integer
    Get
        Return _Counter
    End Get
    Set(ByVal value As Integer)
        _Counter = value
    End Set
End Property

Private Sub Dosomething()

    'What is the best practice?
    'Direct access to private field or property?

    'On SET
    _Counter += 1
    'OR
    Me.Counter += 1

    'On Get
    Console.WriteLine(_Counter)
    Console.WriteLine(Me.Counter)

End Sub

Fine classe

Grazie in anticipo per l'aiuto. Edu

È stato utile?

Soluzione

A mio avviso, l'utilizzo interno di un accessor pubblico è un eccesso di incapsulamento: sfoca il codice. Con un tale approccio, altrimenti le semplici operazioni invocano accessori che potrebbero contenere una logica più complessa, quindi è più difficile analizzare il codice delle operazioni.

Nella mia esperienza di programmazione, raramente ho avuto una situazione in cui sarebbe stato di grande aiuto. Preferisco invece accedere direttamente ai campi, e solo se è realmente necessario, per astrarre l'accesso creando un accessor privato , che può essere utilizzato sia dall'accessorio pubblico che da altre funzioni. La logica è che se è necessario collegare una logica speciale nell'accessorio pubblico, è probabile che la logica potrebbe non essere la stessa per l'accesso interno.

Nota anche che la maggior parte degli IDE moderni (come Eclipse) consente di vedere immediatamente tutti i riferimenti a un campo privato e di riformattare il codice per utilizzare una funzione anziché un accesso diretto.

Altri suggerimenti

IMO dovresti utilizzare Accessor proprietà quando possibile. Questo perché non devi preoccuparti di alcuna logica interna che potrebbe essere disponibile quando hai una proprietà.

Un buon esempio di dove questo accade è nel codice dietro in un Linq DataContext.

guarda questo ... 

[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
    get
    {
        return this._ReviewType;
    }
    set
    {
        if ((this._ReviewType != value))
        {
            this.OnReviewTypeChanging(value);
            this.SendPropertyChanging();
            this._ReviewType = value;
            this.SendPropertyChanged("ReviewType");
            this.OnReviewTypeChanged();
        }
    }
}

Notate tutta quella logica nel 'setter'?

Questo è il motivo per cui è importante iniziare a esercitarsi a chiamare le proprietà anziché i campi, IMO.

Grazie a tutti per le risposte e i suggerimenti.

Dopo aver considerato tutti i suggerimenti qui, oltre ad altre ricerche, ho l'impressione che per questa situazione sul campo privato rispetto al perito sia più una scelta personale. Quindi, in sostanza, il più importante è che, indipendentemente da ciò che scegli, sia coerente.

Detto questo; la mia regola personale tende a questo:

  1. Accedi direttamente ai tuoi campi privati.

  2. Se si accede agli accessori utilizzare la parola chiave ME. per migliorare la leggibilità

  3. Utilizza l'accessor solo se implementa la logica logica vitale che si applica anche all'accesso privato. In questo modo sai che se stai utilizzando l'accessor è perché c'è "qualcos'altro" "

  4. Evita di utilizzare i campi protetti. Le classi derivate devono sempre utilizzare l'accessor, non dirigere mai l'accesso al campo.

Fammi sapere cosa ne pensi.

SideNote:

Dopo questo penso che ci manca un nuovo ambito per i campi a livello di classe. Una parola chiave come & # 8220; Limitata & # 8221; dove questo campo era accessibile solo dal suo getter / setter. In questo modo si accede sempre direttamente ai campi privati, ma se è necessario assicurarsi che a determinati campi sia possibile accedervi solo dal proprio accedente, si passa da Privato a Limitato. (che ne dici di " Restricted, RestrictedRead e RestrictedWrite " ;?)

Preferisco usare la proprietà ogni volta che è possibile. Ciò ti offre la flessibilità in futuro di modificare ciò che la proprietà restituisce / imposta senza dover passare attraverso e trovare tutte le posizioni che utilizzavano la variabile privata.

Usa il campo privato perché non stai facendo qualcosa di specifico nel setter.

Vorrei anche raccomandare di rimuovere il settatore di proprietà, in questo modo forzate lo stato del contatore ad essere impostato con il metodo DoSomething ()

A seconda della situazione, può essere preferibile consentire la modifica diretta di un campo su una classe solo privatamente, o tramite un metodo che associa la semantica alla modifica. In questo modo diventa più facile ragionare su questa classe e quel particolare valore, dal momento che si può essere certi che sia modificato solo in un certo modo. Inoltre, ad un certo punto, un'azione come incrementare e int può avere ulteriori conseguenze richieste a quel punto ha più senso esporre l'accesso ad esso attraverso metodi.

Io sempre uso gli accessi alle proprietà, perché sono sicuro nel caso in cui aggiungessi logica nel getter o setter in futuro, sapendo con certezza che nessun codice lo ignora.

Se sei preoccupato per il sovraccarico prestazionale di chiamare gli accessori di proprietà quando vanno direttamente sul campo, non farlo. La maggior parte dei compilatori incorporerà questo genere di cose, dandoti effettivamente le stesse prestazioni. Almeno, è abbastanza improbabile che tu abbia bisogno dei nanosecondi extra di tempo che potresti guadagnare andando direttamente sul campo.

È meglio attenersi agli accessori di proprietà perché a) puoi essere molto coerente in tutto il tuo codice che lo rende più gestibile eb) ottenere i vantaggi indicati da altri qui.

Inoltre, di solito non aggiungo le parole chiave Me. (o this. ), a meno che non ci sia un problema di ambito (che cerco di evitare scegliendo i miei identificatori accuratamente). Non mi confondo perché le mie funzioni e sottotitoli non sono mai così lunghi che non sono sicuro se sto lavorando con una variabile locale (basata su stack) o un membro della classe. Quando hanno troppo tempo per dirlo facilmente, rifletto.

Il poster originale è ESATTAMENTE corretto.

1) Accedi direttamente ai tuoi campi privati.

  • Semplifica il refactoring.

2) Se si accede agli accessori utilizzare la parola chiave ME. per migliorare la leggibilità

  • elencare esplicitamente l'ambito richiede meno pensiero da parte del lettore

3) Utilizzare l'accessorio solo se implementa la logica logica vitale che si applica anche all'accesso privato. In questo modo sai che se stai usando l'accessor è perché c'è "qualcos'altro"

  • questa è l'unica ragione per violare la regola # 1.

4) Evitare di utilizzare i campi protetti. Le classi derivate devono sempre utilizzare l'accessor, non dirigere mai l'accesso al campo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top