Perché Microsoft non ha fornito un'implementazione generica di OrderedDictionary?
Esistono alcune implementazioni personalizzate che ho visto, tra cui: link
Ma perché Microsoft non l'ha incluso nella libreria .net di base? Sicuramente avevano una ragione per non costruire un generico .... ma che cos'è?
Prima di pubblicare questo messaggio, ho visto: link
Ma ciò conferma che non esiste. Non perché non esiste.
Grazie
In C # 4.0 In a Nutshell ho letto questo:
OrderedDictionary è una combinazione di HashTable e ArrayList
ArrayList
ArrayList viene utilizzata principalmente per la compatibilità con versioni precedenti con Framework 1.x ..." ArrayList è funzionalmente simile a List<object> " Conclusione?
Nessun generico ArrayList perché il suo costrutto sottostante è una classe (non ufficiale) ammortizzata che non ha una versione generica stessa.
Il OrderedDictionary sovraccarica l'operazione di indicizzazione in modo che l'indicizzazione con un intero N ottenga l'elemento in posizione N , mentre l'indicizzazione con Object recupererà l'elemento corrispondente a quell'oggetto. Se si dovesse creare un OrderedDictionary<int, string> chiamato myDict e aggiunto elementi (1, "George") e (0, "Fred") in quell'ordine, dovrebbe myDict[0] restituire "George" o "Fred"?
Tale problema avrebbe potuto essere risolto imponendo un vincolo di classe sul tipo di chiave. D'altra parte, gran parte dell'utilità delle raccolte generiche deriva dalla loro capacità di lavorare efficientemente con i tipi di valore. Imporre un vincolo di classe sul tipo di chiave sembrerebbe un po 'brutto.
Se la classe non doveva essere compatibile con CLS ma doveva semplicemente funzionare con vb.net, un progetto ragionevole avrebbe potuto essere utilizzato per le proprietà indicizzate con nome. Pertanto, nell'esempio precedente, myDict.ByKey[0] avrebbe restituito "Fred" e myDict.BySequence[0] avrebbe restituito "George". Sfortunatamente, linguaggi come C # non supportano le proprietà indicizzate con nome. Mentre si potrebbe avere qualcosa che permetta l'uso della sintassi precedente anche senza tali proprietà, la sfortunata decisione di avvolgere i campi di strutture come Point e Rectangle significa che per myDict.ByKey[0] = "Wally" funzionare, myDict.ByKey dovrebbe restituisce un nuovo oggetto di classe. Una struct sarebbe più efficiente, ma i compilatori rifiuterebbero quella che sembrava una scrittura in una struttura di sola lettura (nonostante la proprietà non modificasse la struct restituita da ByKey , ma modificasse invece la collection a cui tiene un riferimento ).
Personalmente, penso che un oggetto dizionario-ish che è stato specificato per tenere traccia dell'ordine di inserimento sarebbe una cosa carina da avere; Mi piacerebbe anche avere un oggetto dizionario-ish che potrebbe facilmente restituire la chiave associata a una particolare chiave (in modo che, ad esempio, se uno abbia un dizionario insensibile alle maiuscole e minuscole e abbia aggiunto un record con una chiave di "GEORGE", uno potrebbe chiedere al dizionario quale chiave è associata a "George" senza dover cercare tra tutti gli oggetti KeyValuePair restituiti in un'enumerazione.
Poiché l'ordine di mantenimento impedisce la ricerca O (1) implicita da IDictionary a meno che non si avvolgano due raccolte (una per ordine, una per ricerca), che rende l'aggiunta / eliminazione meno performante e aumenta l'utilizzo della memoria. Oppure potresti avere una ricerca più lenta in cambio di un minore utilizzo della memoria.
La mia ipotesi è che non ci fosse una scelta "chiaramente migliore" qui, quindi non è entrato nella libreria standard. Soprattutto intorno al 2.0, C # stava ancora imparando dagli errori di Java. Non sarei sorpreso se l'approccio di Java "tutto e il kitchen sink" alle collezioni nella loro libreria standard fosse visto come qualcosa da evitare.