Informazioni sui membri condivisi (statici) e sul relativo comportamento

1

Ho appena realizzato che posso accedere ai membri condivisi da istanze di classi (probabilmente questo non è corretto, ma compilare ed eseguire), e anche imparare / scoprire che, posso modificare i membri condivisi, quindi creare una nuova istanza e accedere al nuovo valore del membro condiviso.

La mia domanda è, cosa succede ai membri condivisi, quando ritorna al valore "predefinito" (dichiarazione di classe), quanto è pericoloso farlo? è completamente cattivo? è valido in alcuni casi?.

Se vuoi testare il mio punto ecco il codice (progetto console vb.net) che ho usato per testare i membri condivisi, come puoi vedere / compilare / eseguire, il membro condiviso "x" della classe "Hello" ha valore predefinito stringa "Default", ma in fase di esecuzione lo modifica, e dopo aver creato un nuovo oggetto di quella classe, questo oggetto ha il nuovo valore del membro condiviso.

Module Module1
    Public Class hello

        Public Shared x As String = "Default"

        Public Sub New()

        End Sub
    End Class

    Sub Main()

         Console.WriteLine("hello.x=" & hello.x)
         Dim obj As New hello()

         Console.WriteLine("obj.x=" & obj.x)
         obj.x = "Default shared memeber, modified in object"
         Console.WriteLine("obj.x=" & obj.x)

         hello.x = "Defaul shared member, modified in class"
         Console.WriteLine("hello.x=" & hello.x)

         Dim obj2 As New hello()
         Console.WriteLine("obj2.x=" & obj2.x)

          Console.ReadLine()

     End Sub

End Module

AGGIORNAMENTO: Innanzitutto, grazie a tutti, ogni risposta fornisce un feedback, suppongo, per rispetto dovrei sceglierne una come "la risposta", non voglio essere offensivo con nessuno , quindi per favore non prendertela così male se non scegliessi la tua risposta.

    
posta Allende 02.03.2012 - 20:13
fonte

4 risposte

3

I membri condivisi (o statici) non hanno un'istanza. Non sono "parte" di un oggetto. Pensa a membri o funzioni condivisi come comunali. Se un pezzo di codice aggiorna un membro condiviso, il prossimo pezzo di codice per accedervi vedrà il nuovo valore. Shared significa 'memoria condivisa'. È importante capire di chi è la memoria. La memoria condivisa è condivisa da tutti i thread all'interno dello spazio del processo. Quindi, potresti essere ancora più sorpreso se avvii un altro thread e tenti di accedere allo spazio di memoria condiviso. Il thread secondario aggiornerà la memoria del thread principale.

In alcune lingue (ad esempio, C), non è necessario associare tutto a una classe o un modulo contenente. In altre lingue (ad es. VB) fornisci un contesto per il tuo membro sotto forma di classe, ma in realtà solo così puoi a) trovarlo e b) nasconderlo se lo desideri.

I membri privati condivisi saranno visibili solo ai membri di una classe, ma sono comunque condivisi. Con funzioni condivise, ogni chiamante riceve una copia di tutti i parametri passati alla funzione, ma il gioco è fatto. Se la funzione utilizza membri condivisi, questi sono potenziali problemi per due motivi. Per prima cosa, più avanti nel tuo codice, potresti dimenticare chi / cosa ha aggiornato per ultimo il membro condiviso in modo che possa avere un valore inaspettato. In secondo luogo, se il tuo programma è multithread, puoi creare conflitti di risorse che sono molto difficili da diagnosticare.

I membri e le funzioni condivisi sono assolutamente validi in molti casi. Si dovrebbe prendere in considerazione ciò che si sta tentando di fare, se potrebbero esserci conflitti di scrittura per una determinata risorsa e se ci sono considerazioni sulle prestazioni (ad es. Memorizzazione nella cache). Se sei un programmatore principiante, ti suggerirei di comprendere appieno i membri / le funzioni condivisi prima di abituarti a usarli. Un buon posto per usarli è con funzioni che non hanno effetti collaterali (cioè, che non cambiano lo stato del programma impostando altri membri). Quindi potresti usarli per cose come cache (se proprio ne hai bisogno) tra le altre cose. Basta non abusarne.

    
risposta data 02.03.2012 - 21:32
fonte
2

In generale, mi raccomando contro l'uso di variabili condivise / statiche. Ove possibile, utilizzare le variabili di istanza. Ci sono rare eccezioni, a mio avviso.

Uno dei casi in cui una variabile condivisa / statica può avere senso è quando si vogliono introdurre le costanti, sebbene alcune delle costanti del supporto linguistico siano concetti separati. In VB.NET e C # (e possibilmente in altri linguaggi .NET), tieni presente che esiste una differenza tra una costante e una variabile di sola lettura (dichiarata come "ReadOnly" in VB.NET o "readonly" in C #).

Una variabile condivisa / statica è in un certo senso una variabile "globale", sebbene sia possibile limitare l'accesso ad essa utilizzando appropriati modificatori di accesso. Le variabili globali sono considerate come cattive prassi e possono essere estremamente difficili da eseguire il debug, ad es. quando ci sono luoghi in cui il tuo codice scrive o legge da quella variabile, e in particolare se il contenuto della variabile condivisa / statica influenza la logica del tuo codice, ad es. se usato in una dichiarazione if.

Da una prospettiva orientata agli oggetti si potrebbe sostenere che una variabile condivisa / statica sta rompendo l'incapsulamento.

Ci sono molti altri aspetti e fattori che potrebbe essere necessario prendere in considerazione. In generale, consiglio le mie squadre contro di loro anche se ci sono ragionevoli eccezioni dove hanno senso. In breve:

  • Sì, la variabile condivisa / statica è pericolosa
  • No, non sono male come tali
  • Sì, il loro utilizzo è un approccio valido e appropriato in casi selezionati
risposta data 03.03.2012 - 02:34
fonte
1

what happens to the shared members, when it comes back to the "default" value (class declaration), how dangerous is it do this ?

Una classe non statica può contenere metodi, campi, proprietà o eventi statici. Il membro statico è richiamabile su una classe anche se non è stata creata alcuna istanza della classe. Il membro statico è sempre accessibile dal nome della classe, non dal nome dell'istanza. Esiste solo una copia di un membro statico, indipendentemente dal numero di istanze della classe create.

È più tipico dichiarare una classe non statica con alcuni membri statici, piuttosto che dichiarare un'intera classe come statica.

Due usi comuni dei campi statici sono di tenere un conteggio del numero di oggetti che sono stati istanziati, o di memorizzare un valore che deve essere condiviso tra tutte le istanze.

Citato da MSDN - Classi statiche e membri di classi statiche .

is it totally bad ? is it valid in some cases ?.

No, non è male, basta fare attenzione e usarlo quando è appropriato. Tutto dipende da cosa vuoi fare.

    
risposta data 02.03.2012 - 20:34
fonte
1

In diversi linguaggi di programmazione con classi che supportano "membri statici", ogni singola classe viene gestita internamente come se fosse uno spazio dei nomi e i suoi "membri statici" come variabili globali. Questo accade senza che la classe sia istanziata.

    
risposta data 02.03.2012 - 20:40
fonte

Leggi altre domande sui tag