Dopo le discussioni qui su SO ho già letto più volte l'osservazione che le strutture mutabili sono "malvagie" (come nella risposta a questa domanda ).

Qual è il vero problema con la mutabilità e le strutture in C #?

Le strutture sono tipi di valore, il che significa che vengono copiate quando vengono passate in giro.

Quindi, se cambi una copia, stai cambiando solo quella copia, non l'originale e non altre copie che potrebbero essere presenti.

Se la tua struttura è immutabile, tutte le copie automatiche risultanti dal passaggio per valore saranno le stesse.

Se si desidera modificarlo, è necessario farlo consapevolmente creando una nuova istanza della struttura con i dati modificati. (non una copia)

Da dove iniziare ;-p

Il blog di Eric Lippert è sempre buono per un preventivo:

Questa è un'altra ragione per cui i tipi di valori mutabili sono malvagi. Cerca di rendere sempre immutabili i tipi di valore.

Innanzitutto, tendi a perdere le modifiche abbastanza facilmente ... ad esempio, togliendo le cose da un elenco:

Foo foo = list[0];
foo.Name = "abc";

che cosa è cambiato? Niente di utile ...

Lo stesso con le proprietà:

myObj.SomeProperty.Size = 22; // the compiler spots this one

costringendoti a fare:

Bar bar = myObj.SomeProperty;
bar.Size = 22;
myObj.SomeProperty = bar;

meno criticamente, c'è un problema di dimensioni; gli oggetti mutabili tendono ad avere più proprietà; ma se hai uno struct con due ints, a string, a DateTimee a bool, puoi bruciare molto rapidamente molta memoria. Con una classe, più chiamanti possono condividere un riferimento alla stessa istanza (i riferimenti sono piccoli).

Non direi il male, ma la mutabilità è spesso un segno di reazione eccessiva da parte del programmatore per fornire il massimo della funzionalità. In realtà, questo spesso non è necessario e ciò, a sua volta, rende l'interfaccia più piccola, più facile da usare e più difficile da usare in modo errato (= più robusto).

Un esempio è rappresentato dai conflitti di lettura / scrittura e scrittura / scrittura nelle condizioni di gara. Questi semplicemente non possono verificarsi in strutture immutabili, poiché una scrittura non è un'operazione valida.

Inoltre, sostengo che la mutabilità non è quasi mai realmente necessaria , il programmatore pensa solo che potrebbe essere in futuro. Ad esempio, semplicemente non ha senso cambiare una data. Piuttosto, crea una nuova data in base a quella precedente. Questa è un'operazione economica, quindi le prestazioni non sono da tenere in considerazione.

Le strutture mutevoli non sono cattive.

Sono assolutamente necessari in circostanze ad alte prestazioni. Ad esempio, quando le righe della cache e la garbage collection diventano un collo di bottiglia.

Non definirei "malvagio" l'uso di una struttura immutabile in questi casi d'uso perfettamente validi.

Vedo il punto che la sintassi di C # non aiuta a distinguere l'accesso di un membro di un tipo di valore o di un tipo di riferimento, quindi sono tutto per preferire le strutture immutabili, che impongono l'immutabilità, piuttosto che le strutture mutabili.

Tuttavia, invece di etichettare semplicemente le strutture immutabili come "malvagie", consiglierei di abbracciare il linguaggio e sostenere una regola dei pollici più utile e costruttiva.

Ad esempio: "le strutture sono tipi di valore, che vengono copiati per impostazione predefinita. È necessario un riferimento se non si desidera copiarli" o "provare prima a lavorare con le strutture di sola lettura" .

Le strutture con campi o proprietà mutabili pubblici non sono malvagie.

I metodi Struct (distinti dai setter di proprietà) che mutano "questo" sono in qualche modo malvagi, solo perché .net non fornisce un mezzo per distinguerli da metodi che non lo fanno. I metodi Struct che non mutano "questo" dovrebbero essere invocabili anche su strutture di sola lettura senza necessità di copia difensiva. I metodi che mutano "questo" non dovrebbero essere affatto invocabili su strutture di sola lettura. Poiché .net non vuole vietare i metodi di struttura che non modificano "this" dall'essere invocati su strutture di sola lettura, ma non vuole permettere che le strutture di sola lettura vengano mutate, copia difensivamente le strutture in lettura- solo contesti, probabilmente ottenendo il peggio di entrambi i mondi.

Nonostante i problemi con la gestione dei metodi auto-mutanti in contesti di sola lettura, tuttavia, le strutture mutabili offrono spesso una semantica di gran lunga superiore ai tipi di classe mutabili. Considera le seguenti tre firme di metodo:

struct PointyStruct {public int x, y, z;};
class PointyClass {public int x, y, z;};

void Method1 (PointyStruct foo);
void Method2 (ref PointyStruct foo);
void Method3 (PointyClass foo);

Per ciascun metodo, rispondi alle seguenti domande:

1. Supponendo che il metodo non utilizzi alcun codice "non sicuro", potrebbe modificare foo?
2. Se non esistono riferimenti esterni a "pippo" prima che venga chiamato il metodo, potrebbe esistere un riferimento esterno dopo?

_risposte:

Domanda 1::
  Method1()no (intento chiaro)
  Method2() : sì (intento chiaro)
  Method3() : sì (intento incerto)
Domanda 2
  Method1():: no
  Method2(): no (a meno che non sia sicuro)
  Method3() : sì

Method1 non può modificare foo e non ottiene mai un riferimento. Method2 ottiene un riferimento di breve durata a foo, che può utilizzare per modificare i campi di foo un numero qualsiasi di volte, in qualsiasi ordine, fino a quando non ritorna, ma non può persistere quel riferimento. Prima che il metodo 2 ritorni, a meno che non utilizzi un codice non sicuro, tutte le copie che potrebbero essere state fatte del suo riferimento "foo" saranno scomparse. Method3, a differenza di Method2, ottiene un riferimento promiscuamente condivisibile a foo, e non si può dire cosa potrebbe farci. Potrebbe non cambiare affatto foo, potrebbe cambiare foo e poi tornare, oppure potrebbe dare un riferimento a foo a un altro thread che potrebbe mutarlo in qualche modo arbitrario in un futuro futuro arbitrario.

Le matrici di strutture offrono una meravigliosa semantica. Dato RectArray [500] di tipo Rectangle, è chiaro ed ovvio come ad esempio copiare l'elemento 123 nell'elemento 456 e poi qualche tempo dopo impostare la larghezza dell'elemento 123 su 555, senza disturbare l'elemento 456. "RectArray [432] = RectArray [321 ]; ...; RectArray [123] .Width = 555; ". Sapere che Rectangle è una struttura con un campo intero chiamato Larghezza ti dirà tutto ciò che devi sapere sulle affermazioni di cui sopra.

Supponiamo ora che RectClass fosse una classe con gli stessi campi di Rectangle e si volesse fare le stesse operazioni su un RectClassArray [500] di tipo RectClass. Forse l'array dovrebbe contenere 500 riferimenti immutabili preinizializzati a oggetti RectClass mutabili. in tal caso, il codice corretto sarebbe simile a "RectClassArray [321] .SetBounds (RectClassArray [456]); ...; RectClassArray [321] .X = 555;". Forse si presume che l'array contenga istanze che non cambieranno, quindi il codice corretto sarebbe più simile a "RectClassArray [321] = RectClassArray [456]; ...; RectClassArray [321] = New RectClass (RectClassArray [321 ]); RectClassArray [321] .X = 555; " Per sapere cosa si dovrebbe fare, si dovrebbe sapere molto di più sia su RectClass (ad es. Supporta un costruttore di copie, un metodo di copia da, ecc. ) e l'uso previsto dell'array. Da nessuna parte pulito come usare una struttura.

A dire il vero, sfortunatamente non esiste un buon modo per qualsiasi classe di container diversa da un array di offrire la semantica pulita di un array di strutture. Il migliore che si potrebbe fare, se si volesse indicizzare una raccolta con ad esempio una stringa, sarebbe probabilmente quello di offrire un metodo "ActOnItem" generico che accetterebbe una stringa per l'indice, un parametro generico e un delegato che verrebbe passato per riferimento sia il parametro generico che l'elemento di raccolta. Ciò consentirebbe quasi la stessa semantica degli array di struttura, ma a meno che le persone vb.net e C # non possano essere perseguite per offrire una bella sintassi, il codice apparirà goffo anche se è ragionevolmente prestazioni (passare un parametro generico sarebbe consentire l'uso di un delegato statico ed evitare qualsiasi necessità di creare istanze di classe temporanee).

Personalmente, sono irritato dall'odio Eric Lippert et al. vomitare per quanto riguarda i tipi di valori mutabili. Offrono una semantica molto più pulita rispetto ai promiscui tipi di riferimento utilizzati ovunque. Nonostante alcune limitazioni con il supporto di .net per i tipi di valore, ci sono molti casi in cui i tipi di valori mutabili si adattano meglio di qualsiasi altro tipo di entità.

I tipi di valore rappresentano fondamentalmente concetti immutabili. Fx, non ha senso avere un valore matematico come un numero intero, un vettore ecc. E quindi poterlo modificare. Sarebbe come ridefinire il significato di un valore. Invece di modificare un tipo di valore, ha più senso assegnare un altro valore univoco. Pensa al fatto che i tipi di valore vengono confrontati confrontando tutti i valori delle sue proprietà. Il punto è che se le proprietà sono le stesse allora è la stessa rappresentazione universale di quel valore.

Come Konrad menziona, non ha nemmeno senso cambiare una data, poiché il valore rappresenta quel particolare punto nel tempo e non un'istanza di un oggetto tempo che ha uno stato o una dipendenza dal contesto.

Spero che questo abbia senso per te. Si tratta più del concetto che si tenta di acquisire con tipi di valore che di dettagli pratici, per essere sicuri.

Ci sono un paio di altri casi angolari che potrebbero portare a comportamenti imprevedibili dal punto di vista del programmatore.

Tipi di valori immutabili e campi di sola lettura

    // Simple mutable structure. 
    // Method IncrementI mutates current state.
    struct Mutable
    {
        public Mutable(int i) : this() 
        {
            I = i;
        }

        public void IncrementI() { I++; }

        public int I { get; private set; }
    }

    // Simple class that contains Mutable structure
    // as readonly field
    class SomeClass 
    {
        public readonly Mutable mutable = new Mutable(5);
    }

    // Simple class that contains Mutable structure
    // as ordinary (non-readonly) field
    class AnotherClass 
    {
        public Mutable mutable = new Mutable(5);
    }

    class Program
    {
        void Main()
        {
            // Case 1. Mutable readonly field
            var someClass = new SomeClass();
            someClass.mutable.IncrementI();
            // still 5, not 6, because SomeClass.mutable field is readonly
            // and compiler creates temporary copy every time when you trying to
            // access this field
            Console.WriteLine(someClass.mutable.I);

            // Case 2. Mutable ordinary field
            var anotherClass = new AnotherClass();
            anotherClass.mutable.IncrementI();

            // Prints 6, because AnotherClass.mutable field is not readonly
            Console.WriteLine(anotherClass.mutable.I);
        }
    }

Tipi di valori mutevoli e array

Supponiamo di avere una matrice della nostra Mutablestruttura e di chiamare il IncrementImetodo per il primo elemento di quella matrice. Che comportamento ti aspetti da questa chiamata? Dovrebbe cambiare il valore dell'array o solo una copia?

    Mutable[] arrayOfMutables = new Mutable[1];
    arrayOfMutables[0] = new Mutable(5);

    // Now we actually accessing reference to the first element
    // without making any additional copy
    arrayOfMutables[0].IncrementI();

    // Prints 6!!
    Console.WriteLine(arrayOfMutables[0].I);

    // Every array implements IList<T> interface
    IList<Mutable> listOfMutables = arrayOfMutables;

    // But accessing values through this interface lead
    // to different behavior: IList indexer returns a copy
    // instead of an managed reference
    listOfMutables[0].IncrementI(); // Should change I to 7

    // Nope! we still have 6, because previous line of code
    // mutate a copy instead of a list value
    Console.WriteLine(listOfMutables[0].I);

Quindi, le strutture mutabili non sono malvagie fintanto che tu e il resto della squadra capite chiaramente cosa state facendo. Ma ci sono troppi casi angolari in cui il comportamento del programma sarebbe diverso da quello che ci si aspetta, che potrebbe portare a errori difficili da produrre e da capire.

Se hai mai programmato in un linguaggio come C / C ++, le strutture vanno bene come mutabili. Basta passarli con ref, in giro e non c'è nulla che possa andare storto. L'unico problema che riscontro sono le restrizioni del compilatore C # e che, in alcuni casi, non sono in grado di forzare la cosa stupida a usare un riferimento alla struttura, anziché una copia (come quando una struttura fa parte di una classe C # ).

Quindi, le strutture mutabili non sono malvagie, C # le ha rese malvagie. Uso sempre strutture mutabili in C ++ e sono molto comode e intuitive. Al contrario, C # mi ha fatto abbandonare completamente le strutture come membri delle classi a causa del modo in cui gestiscono gli oggetti. La loro convenienza ci è costata la nostra.

Se ti attieni a ciò a cui sono destinate le strutture (in C #, Visual Basic 6, Pascal / Delphi, tipo di struttura C ++ (o classi) quando non sono usate come puntatori), scoprirai che una struttura non è più di una variabile composta . Questo significa: li tratterai come un insieme impacchettato di variabili, con un nome comune (una variabile record da cui fai riferimento ai membri).

So che confonderebbe molte persone profondamente abituate alla OOP, ma non è una ragione sufficiente per dire che tali cose sono intrinsecamente malvagie, se usate correttamente. Alcune strutture sono immutabili come intendono (questo è il caso di Pythonnamedtuple ), ma è un altro paradigma da considerare.

Sì: le strutture implicano molta memoria, ma non sarà precisamente più memoria facendo:

point.x = point.x + 1

rispetto a:

point = Point(point.x + 1, point.y)

Il consumo di memoria sarà almeno lo stesso, o anche di più nel caso immutabile (anche se quel caso sarebbe temporaneo, per lo stack corrente, a seconda della lingua).

Ma, infine, le strutture sono strutture , non oggetti. In POO, la proprietà principale di un oggetto è la sua identità , che il più delle volte non è altro che il suo indirizzo di memoria. Struct sta per struttura dei dati (non un oggetto appropriato, quindi non hanno comunque identità) e i dati possono essere modificati. In altre lingue, record (invece di struct , come nel caso di Pascal) è la parola e ha lo stesso scopo: solo una variabile di record di dati, destinata a essere letta da file, modificata e scaricata in file (questo è il principale utilizzare e, in molte lingue, è anche possibile definire l'allineamento dei dati nel record, mentre ciò non è necessariamente il caso di oggetti correttamente chiamati).

Vuoi un buon esempio? Le strutture vengono utilizzate per leggere facilmente i file. Python ha questa libreria perché, poiché è orientata agli oggetti e non ha supporto per le strutture, ha dovuto implementarla in un altro modo, il che è piuttosto brutto. Le strutture che implementano le lingue hanno questa caratteristica ... integrata. Prova a leggere un'intestazione bitmap con una struttura appropriata in linguaggi come Pascal o C. Sarà facile (se la struttura è costruita e allineata correttamente; in Pascal non utilizzeresti un accesso basato su record ma funzioni per leggere dati binari arbitrari). Quindi, per i file e l'accesso diretto (locale) alla memoria, le strutture sono migliori degli oggetti. Ad oggi, siamo abituati a JSON e XML, e quindi dimentichiamo l'uso di file binari (e come effetto collaterale, l'uso di strutture). Ma sì: esistono e hanno uno scopo.

Non sono cattivi. Usali solo per lo scopo giusto.

Se pensi in termini di martelli, vorrai trattare le viti come chiodi, per scoprire che le viti sono più difficili da immergere nel muro, e sarà colpa delle viti, e saranno quelle malvagie.

Immagina di avere una matrice di 1.000.000 di strutture. Ogni struttura che rappresenta un'equità con elementi come bid_price, offer_price (forse decimali) e così via, questo viene creato da C # / VB.

Immagina che l'array sia creato in un blocco di memoria allocato nell'heap non gestito in modo che qualche altro thread di codice nativo sia in grado di accedere contemporaneamente all'array (forse un codice high-perf che fa matematica).

Immagina che il codice C # / VB stia ascoltando un feed di mercato delle variazioni di prezzo, che il codice potrebbe dover accedere ad alcuni elementi dell'array (per qualsiasi sicurezza) e quindi modificare alcuni campi di prezzo.

Immagina che ciò avvenga decine o addirittura centinaia di migliaia di volte al secondo.

Bene, affrontiamo i fatti, in questo caso vogliamo davvero che queste strutture siano mutabili, devono essere perché sono condivise da qualche altro codice nativo, quindi la creazione di copie non aiuta; devono esserlo perché fare una copia di una struttura di circa 120 byte a queste velocità è folle, specialmente quando un aggiornamento può effettivamente avere un impatto solo su uno o due byte.

Hugo

Quando qualcosa può essere mutato, acquisisce un senso di identità.

struct Person {
    public string name; // mutable
    public Point position = new Point(0, 0); // mutable

    public Person(string name, Point position) { ... }
}

Person eric = new Person("Eric Lippert", new Point(4, 2));

Perché Personè mutevole, è più naturale pensare di cambiare la posizione di Eric che clonare Eric, spostare il clone e distruggere l'originale . Entrambe le operazioni sarebbero riuscite a modificare il contenuto dieric.position , ma una è più intuitiva dell'altra. Allo stesso modo, è più intuitivo passare Eric (come riferimento) per i metodi per modificarlo. Dare un metodo a un clone di Eric sarà quasi sempre sorprendente. Chiunque desideri mutare Persondeve ricordarsi di chiedere un riferimento Persono farà la cosa sbagliata.

Se si rende immutabile il tipo, il problema scompare; se non riesco a modificare eric, non fa differenza se ricevoeric o un clone di eric. Più in generale, un tipo è sicuro per passare per valore se tutto il suo stato osservabile è contenuto in membri che sono:

• immutabile
• tipi di riferimento
• sicuro passare per valore

Se tali condizioni sono soddisfatte, un tipo di valore modificabile si comporta come un tipo di riferimento poiché una copia superficiale consentirà comunque al destinatario di modificare i dati originali.

L'intuitività di un immutabile Persondipende da cosa stai cercando di fare. Se Personrappresenta solo un insieme di dati su una persona, non c'è nulla di non intuitivo al riguardo; Personle variabili rappresentano veramente valori astratti , non oggetti. (In tal caso, probabilmente sarebbe più appropriato rinominarlo PersonData.) Se in Personrealtà modella una persona stessa, l'idea di creare e spostare costantemente cloni è sciocca anche se hai evitato la trappola di pensare che stai modificando l'originale. In tal caso, sarebbe probabilmente più naturale fare semplicementePerson un tipo di riferimento (ovvero una classe).

Certo, poiché la programmazione funzionale ci ha insegnato che ci sono vantaggi nel rendere tutto immutabile (nessuno può segretamente aggrapparsi a un riferimento erice mutarlo), ma dal momento che non è idiomatico in OOP non sarà ancora intuitivo per chiunque lavori con il tuo codice.

Non ha nulla a che fare con le strutture (e nemmeno con C #) ma in Java potresti avere problemi con oggetti mutabili quando sono, ad esempio, chiavi in ​​una mappa hash. Se li cambi dopo averli aggiunti a una mappa e cambia il suo codice hash , potrebbero accadere cose cattive.

Personalmente, quando guardo il codice, mi sembra abbastanza goffo:

data.value.set (data.value.get () + 1);

piuttosto che semplicemente

data.value ++; o data.value = data.value + 1;

L'incapsulamento dei dati è utile quando si passa una classe in giro e si desidera assicurarsi che il valore venga modificato in modo controllato. Tuttavia, quando si dispone di un set pubblico e si ottengono funzioni che fanno poco più che impostare il valore su ciò che viene mai passato, come può essere un miglioramento rispetto al semplice passaggio di una struttura di dati pubblici?

Quando creo una struttura privata all'interno di una classe, ho creato quella struttura per organizzare un insieme di variabili in un gruppo. Voglio essere in grado di modificare quella struttura nell'ambito della classe, non ottenere copie di quella struttura e creare nuove istanze.

Per me questo impedisce un uso valido delle strutture utilizzate per organizzare le variabili pubbliche, se volessi il controllo degli accessi userei una classe.

Ci sono diversi problemi nell'esempio di Eric Lippert. È inventato per illustrare il punto in cui le strutture vengono copiate e come ciò potrebbe costituire un problema se non si presta attenzione. Guardando l'esempio, lo vedo come conseguenza di una cattiva abitudine di programmazione e non di un vero problema con la struttura o la classe.

1. Una struttura dovrebbe avere solo membri pubblici e non dovrebbe richiedere alcun incapsulamento. Se lo fa, allora dovrebbe davvero essere un tipo / classe. Non hai davvero bisogno di due costrutti per dire la stessa cosa.

2. Se hai classe che racchiude una struttura, chiameresti un metodo nella classe per mutare la struttura membro. Questo è ciò che farei come una buona abitudine di programmazione.

Una corretta attuazione sarebbe la seguente.

struct Mutable {
public int x;
}

class Test {
    private Mutable m = new Mutable();
    public int mutate()
    { 
        m.x = m.x + 1;
        return m.x;
    }
  }
  static void Main(string[] args) {
        Test t = new Test();
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
    }

Sembra che sia un problema con l'abitudine alla programmazione piuttosto che un problema con la struttura stessa. Le strutture dovrebbero essere mutabili, questa è l'idea e l'intenzione.

Il risultato delle modifiche voila si comporta come previsto:

1 2 3 Premere un tasto qualsiasi per continuare. . .

Ci sono molti vantaggi e svantaggi per i dati mutabili. Lo svantaggio di un milione di dollari è l'aliasing. Se lo stesso valore viene utilizzato in più punti e uno di essi lo modifica, sembrerà che sia magicamente cambiato negli altri luoghi che lo utilizzano. Ciò è legato, ma non identico, alle condizioni di gara.

Il vantaggio di milioni di dollari è la modularità, a volte. Lo stato mutevole può consentire di nascondere le informazioni modificabili dal codice che non è necessario conoscere.

L'Arte dell'Interprete approfondisce questi dettagli in alcuni dettagli e fornisce alcuni esempi.

Non credo che siano cattivi se usati correttamente. Non lo inserirò nel mio codice di produzione, ma preferirei qualcosa come simulazioni di test di unità strutturate, in cui la durata di una struttura è relativamente piccola.

Usando l'esempio Eric, forse vuoi creare una seconda istanza di quell' Eric, ma apportare modifiche, poiché questa è la natura del tuo test (cioè duplicazione, quindi modifica). Non importa cosa succede con la prima istanza di Eric se stiamo solo usando Eric2 per il resto dello script di test, a meno che tu non stia pianificando di usarlo come confronto di test.

Ciò sarebbe utile soprattutto per testare o modificare il codice legacy che shallow definisce un particolare oggetto (il punto delle strutture), ma avendo una struttura immutabile, questo ne impedisce l'uso in modo fastidioso.