Perché le strutture e le classi hanno concetti separati in C #?

Durante la programmazione in C #, mi sono imbattuto in una strana decisione di progettazione del linguaggio che non riesco proprio a capire.

Quindi, C # (e CLR) ha due tipi di dati aggregati: struct(tipo-valore, archiviato nello stack, nessuna eredità) e class(tipo di riferimento, memorizzato nell'heap, ha ereditarietà).

All'inizio questa configurazione suona bene, ma poi ti imbatti in un metodo che prende un parametro di un tipo aggregato e per capire se è effettivamente di un tipo di valore o di un tipo di riferimento, devi trovare la dichiarazione del suo tipo. A volte può diventare davvero confuso.

La soluzione generalmente accettata al problema sembra dichiarare tutti struct"immutabili" (impostando i loro campi su readonly) per prevenire possibili errori, limitando l struct'utilità.

Il C ++, ad esempio, utilizza un modello molto più utilizzabile: consente di creare un'istanza di oggetto nello stack o nell'heap e passarla per valore o per riferimento (o per puntatore). Continuo a sentire che C # è stato ispirato da C ++ e non riesco proprio a capire perché non abbia preso questa tecnica. Combinare classe structin un costrutto con due diverse opzioni di allocazione (heap e stack) e passarle come valori o (esplicitamente) come riferimenti tramite le parole chiave refe outsembra una cosa carina.

La domanda è: perché classe structdiventano concetti distinti in C # e il CLR, invece di un tipo di aggregazione con due opzioni di allocazione?

La ragione per cui C # (e Java ed essenzialmente ogni altro linguaggio OO sviluppato dopo C ++) non ha copiato il modello di C ++ in questo aspetto è perché il modo in cui C ++ lo fa è un casino orrendo.

Hai identificato correttamente i punti rilevanti sopra:: structtipo di valore, nessuna eredità. class: tipo di riferimento, ha ereditarietà. I tipi di ereditarietà e di valore (o più specificamente, polimorfismo e pass-by-value) non si mescolano; se si passa un oggetto di tipo Deriveda un argomento di metodo di tipo Basee quindi si chiama un metodo virtuale su di esso, l'unico modo per ottenere un comportamento corretto è assicurarsi che ciò che è stato passato sia un riferimento.

Tra questo e tutti gli altri casini in cui ti imbatti in C ++ avendo oggetti ereditabili come tipi di valore (ti vengono in mente costruttori di copie e divisione di oggetti !) La soluzione migliore è solo dire No.

Una buona progettazione del linguaggio non è solo l'implementazione di funzionalità, ma anche la conoscenza di quali funzionalità non implementare e uno dei modi migliori per farlo è quello di imparare dagli errori di coloro che ti hanno preceduto.

Per analogia, C # è fondamentalmente come un set di strumenti per meccanici in cui qualcuno ha letto che dovresti generalmente evitare pinze e chiavi regolabili, quindi non include affatto chiavi regolabili e le pinze sono bloccate in un apposito cassetto contrassegnato "non sicuro" e può essere utilizzato solo con l'approvazione di un supervisore, dopo aver firmato un disclaimer che assolve il datore di lavoro da qualsiasi responsabilità per la propria salute.

Il C ++, al confronto, include non solo chiavi e pinze regolabili, ma alcuni strumenti piuttosto speciali a sfera speciale il cui scopo non è immediatamente evidente e se non conosci il modo giusto di tenerli, potrebbero facilmente tagliare il tuo pollice (ma una volta che hai capito come usarli, puoi fare cose che sono essenzialmente impossibili con gli strumenti di base nella casella degli strumenti di C #). Inoltre, ha un tornio, una fresatrice, una smerigliatrice di superficie, una sega a nastro per il taglio di metalli, ecc., Per consentirti di progettare e creare strumenti completamente nuovi ogni volta che ne senti la necessità (ma sì, quegli strumenti del macchinista possono e causeranno lesioni gravi se non sai cosa stai facendo con loro - o anche solo se ti trascuri).

Ciò riflette la differenza fondamentale nella filosofia: il C ++ tenta di fornirti tutti gli strumenti di cui potresti aver bisogno essenzialmente per qualsiasi progetto tu voglia. Non fa quasi alcun tentativo di controllare il modo in cui usi questi strumenti, quindi è anche facile usarli per produrre progetti che funzionano bene solo in situazioni rare, così come progetti che sono probabilmente solo un'idea schifosa e nessuno sa di una situazione in cui probabilmente funzioneranno bene. In particolare, gran parte di questo viene fatto disaccoppiando le decisioni di progettazione - anche quelle che in pratica sono quasi sempre accoppiate. Di conseguenza, c'è una grande differenza tra scrivere semplicemente C ++ e scrivere bene C ++. Per scrivere bene C ++, devi conoscere molti modi di dire e regole empiriche (comprese le regole empiriche su quanto seriamente riconsiderare prima di infrangere altre regole empiriche). Di conseguenza, Il C ++ è molto più orientato alla facilità d'uso (da parte degli esperti) che alla facilità di apprendimento. Ci sono anche (troppe) circostanze in cui non è nemmeno terribilmente facile da usare.

C # fa molto di più per cercare di forzare (o almeno suggerire in modo estremamente forte) ciò che i progettisti del linguaggio hanno considerato buone pratiche di progettazione. Molte cose che sono disaccoppiate in C ++ (ma di solito vanno insieme in pratica) sono direttamente accoppiate in C #. Permette al codice "non sicuro" di spingere un po 'i confini, ma onestamente, non molto.

Il risultato è che da un lato ci sono alcuni progetti che possono essere espressi in modo abbastanza diretto in C ++ che sono sostanzialmente più goffi da esprimere in C #. D'altra parte, si tratta di un intero molto più facile da imparare il C #, e le possibilità di produzione di un design davvero orribile che non funzionerà per la vostra situazione (o probabilmente qualsiasi altro) sono drasticamente ridotti. In molti (probabilmente anche nella maggior parte dei casi), è possibile ottenere un design solido e realizzabile semplicemente "seguendo il flusso", per così dire. Oppure, come uno dei miei amici (almeno mi piace pensare a lui come un amico - non sono sicuro che sia davvero d'accordo) piace metterlo, C # rende facile cadere nella fossa del successo.

Quindi, osservando più specificamente la domanda su come classe structottenuto come sono nelle due lingue: oggetti creati in una gerarchia di ereditarietà in cui potresti usare un oggetto di una classe derivata nelle vesti della sua classe / interfaccia di base, sei praticamente bloccato dal fatto che normalmente è necessario farlo tramite una sorta di puntatore o riferimento - a livello concreto, ciò che accade è che l'oggetto della classe derivata contiene qualcosa di memoria che può essere trattato come un'istanza della classe base / interfaccia e l'oggetto derivato viene manipolato tramite l'indirizzo di quella parte della memoria.

In C ++, spetta al programmatore farlo correttamente - quando usa l'ereditarietà, spetta a lui assicurarsi che (ad esempio) una funzione che funzioni con le classi polimorfiche in una gerarchia lo faccia tramite un puntatore o un riferimento alla base classe.

In C #, ciò che è fondamentalmente la stessa separazione tra i tipi è molto più esplicito e applicato dal linguaggio stesso. Il programmatore non ha bisogno di fare alcun passo per passare un'istanza di una classe per riferimento, perché ciò accadrà di default.

Questo è tratto da "C #: perché abbiamo bisogno di un'altra lingua?" - Gunnerson, Eric:

La semplicità era un importante obiettivo di progettazione per C #.

È possibile esagerare con la semplicità e la purezza del linguaggio, ma la purezza per il bene della purezza è di scarsa utilità per il programmatore professionista. Abbiamo quindi cercato di bilanciare il nostro desiderio di avere un linguaggio semplice e conciso con la soluzione dei problemi del mondo reale che i programmatori devono affrontare.

[...]

I tipi di valore , il sovraccarico dell'operatore e le conversioni definite dall'utente aggiungono complessità al linguaggio , ma consentono di semplificare enormemente uno scenario utente importante.

La semantica di riferimento per gli oggetti è un modo per evitare molti problemi (ovviamente e non solo la suddivisione degli oggetti) ma a volte i problemi del mondo reale possono richiedere oggetti con valore semantico (ad esempio dare un'occhiata a Suoni come se non dovessi mai usare la semantica di riferimento, giusto? per un diverso punto di vista).

Quale approccio migliore da adottare, quindi, che segregare quegli oggetti sporchi, brutti e cattivi con valore semantico sotto l'etichetta di struct?

Anziché pensare ai tipi di valore derivanti Object, sarebbe più utile pensare ai tipi di posizione di archiviazione esistenti in un universo completamente separato dai tipi di istanza di classe, ma per ogni tipo di valore avere un tipo di oggetto heap corrispondente. Una posizione di archiviazione del tipo di struttura contiene semplicemente una concatenazione dei campi pubblici e privati ​​del tipo e il tipo di heap viene generato automaticamente secondo uno schema come:

// Defined structure
struct Point : IEquatable<Point>
{
  public int X,Y;
  public Point(int x, int y) { X=x; Y=y; }
  public bool Equals(Point other) { return X==other.X && y==other.Y; }
  public bool Equals(Object other)
  { return other != null && other.GetType()==typeof(this) && Equals(Point(other)); }
  public bool ToString() { return String.Format("[{0},{1}", x, y); }
  public bool GetHashCode() { return unchecked(x+y*65531); }
}        
// Auto-generated class
class boxed_Point: IEquatable<Point>
{
  public Point value; // Fake name; C++/CLI, though not C#, allow full access
  public boxed_Point(Point v) { value=v; }
  // Members chain to each member of the original
  public bool Equals(Point other) { return value.Equals(other); }
  public bool Equals(Object other) { return value.Equals(other); }
  public String ToString() { return value.ToString(); }
  public Int32 GetHashCode() { return value.GetHashCode(); }
}

e per un'istruzione come: Console.WriteLine ("Il valore è {0}", somePoint);

da tradurre come: boxed_Point box1 = new boxed_Point (somePoint); Console.WriteLine ("Il valore è {0}", box1);

In pratica, poiché i tipi di posizione di archiviazione e i tipi di istanza heap esistono in universi separati, non è necessario chiamare i tipi di istanza heap come cose simili boxed_Int32; poiché il sistema saprebbe quali contesti richiedono l'istanza di heap-object e quali richiedono un percorso di archiviazione.

Alcune persone pensano che qualsiasi tipo di valore che non si comporti come un oggetto debba essere considerato "malvagio". Sono dell'opinione opposta: poiché le posizioni di archiviazione dei tipi di valore non sono né oggetti né riferimenti ad oggetti, l'aspettativa che debbano comportarsi come oggetti dovrebbe essere considerata inutile. Nei casi in cui una struttura può comportarsi utilmente come un oggetto, non c'è nulla di sbagliato nel farlo, ma ognuno structè nel suo cuore nient'altro che un'aggregazione di campi pubblici e privati ​​attaccati insieme al nastro adesivo.