Sto usando troppi dizionari all'interno dei dizionari nel mio codice, è un odore di codice?

Question

sto usando un sacco di collezioni del dizionario che contengono altre collezioni del dizionario come:

Dictionary<Guid, List<string>>() 

Dictionary<Guid, Dictionary<Guid, List<string>>>() 

Sto scorrendo queste mappe, e passarli in giro nei parametri nel mio codice.

Questa sembra una cattiva idea poiché non è possibile estendere la natura di queste raccolte ora.

Sarebbe meglio avvolgerli in una classe?

Answer 1

Ti imbatti in tali limiti? Il tuo programma è difficile da modificare/eseguire il debug? Se è così, refactoring. Altrimenti, profitto: sei un programmatore pragmatico,

Detto questo, posso vedere margini di miglioramento immediato:

IDictionary<Guid, List<string>> x; 

IDictionary<Guid, IDictionary<Guid, List<string>> y = new Dictionary<Guid, IDictionary<Guid, List<string>>(); 

Answer 2

Direi di sì, creare una classe specifica per questo. Quindi puoi aggiungere/non implementare i metodi secondo il tuo utilizzo, piuttosto che aggirare le limitazioni che trovi con Dictionary con il tuo utilizzo.

Sembra che tu voglia una struttura ad albero.

Answer 3

.NET 4.0 ha introdotto Tuple, una struttura di dati ancora più abusable, così bello come sembra in principio, per quanto il dolore che porta in seguito e dovrebbe essere usato con saggezza.

Il dizionario è in qualche modo meno malvagio qui, perché serve per l'accesso rapido agli elementi, non solo come una colla invece di creare classi. Credo che non vi sia nulla di sbagliato nell'uso dei dizionari se quei dizionari sono usati localmente in un metodo per qualche calcolo o qualcosa del genere, ma diventa meno chiaro quando si inizia a passarli come parametri. Se è così, penso che tu debba creare una classe per questo.

Answer 4

Poiché il tipo di dizionario è un tipo di riferimento, non ci si trova in cattive condizioni qui, ma solo per chiarezza del codice si consideri la definizione di un nuovo tipo, derivato da Dictionary<Guid,List<string>> solo per abbreviare il codice che si sta scrivendo e per renderlo facilmente leggibile . La classe dovrebbe essere simile a questo:

internal class MyWrapper : Dictionary<Guid, List<string>> 
{ 
} 

O se è importante per voi per mantenere con IDictionary, poi andare avanti con il disegno composito avvolgendo un'istanza Dictionary<Guid, List<string>> nella classe che implementa le IDictionary<Guid, List<string>> e solo i delegati di tutti i metodi per il dizionario avvolto.

Answer 5

Almeno, avvolgere la struttura dei dati "puzzolente" in una classe, in modo da poter incapsulare la sua implementazione fornendo un'API pulita per interrogare/modificare i dati senza alcun codice client che ignori qualcosa sui dettagli di archiviazione.

Quindi sarai libero di cambiare l'implementazione della struttura dati in qualsiasi momento in futuro. Se non lo fai ora, potresti pentirtene più tardi se hai 10 o 100 volte più codice cliente, ed è troppo costoso/doloroso per il refactoring.

Potresti scoprire che finché lo trattieni incapsulato in modo ordinato, e funziona, il fatto che tu senta che è maleodorante non è davvero rilevante - finché il codice fa quello che deve fare ed è manutenibile, lì non ha senso investire molto più tempo in esso.(Non sto sostenendo di mantenere il codice sporco, ma dobbiamo bilanciare le realtà commerciali con il nostro desiderio di raggiungere la perfezione teorica - se il codice funziona e non causa problemi, allora potrebbe non essere sempre un buon uso del tuo tempo per Invece, potresti scoprire che semplicemente neutralizzare i rischi incapsulandoli in una classe e isolare l'implementazione sporca dai suoi clienti è sufficiente per ora)