Estoy usando demasiados diccionarios dentro de los diccionarios en mi código, ¿eso es un olor a código?

Question

estoy usando un montón de colecciones de diccionarios que contienen otras colecciones de diccionarios como:

Dictionary<Guid, List<string>>() 

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

estoy bucle a través de estos mapas, y que pasa a su alrededor en los parámetros en mi código.

Esto parece una mala idea ya que no se puede extender la naturaleza de estas colecciones ahora.

¿Sería mejor envolver estos en una clase?

Answer 1

¿Se encuentra con tales limitaciones? ¿Su programa es difícil de alterar/depurar? Si es así, refactor. De lo contrario, beneficio: eres un programador pragmático.

Dicho esto, puedo ver margen de mejora inmediata:

IDictionary<Guid, List<string>> x; 

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

Answer 2

Yo diría que sí, cree una clase específicamente para ello. Luego puede agregar/no implementar métodos según su uso, en lugar de evitar las limitaciones que encuentre con Dictionary con su uso.

Parece que quieres una estructura similar a un árbol.

Answer 3

.NET 4.0 introducido Tupla, una estructura de datos que se puede abusar aún más, es tan bonito como parece en un principio, tanto el dolor que trae posteriormente y debe ser usado sabiamente

El diccionario es de alguna manera menos malvado aquí, porque sirve para acceder rápidamente a los elementos, no solo como un pegamento en lugar de crear clases. Creo que no hay nada de malo en el uso de los diccionarios si esos diccionarios se usan localmente en un método para hacer algún cálculo o algo, pero se vuelve menos claro cuando se los pasa por parámetros. Si ese es el caso, creo que necesitas crear una clase para eso.

Answer 4

Porque el tipo de diccionario es un tipo de referencia, no está mal, pero solo para la claridad del código, considere definir un nuevo tipo, derivado de Dictionary<Guid,List<string>>, solo para acortar el código que está escribiendo y hacerlo más fácil de leer . La clase debe tener este aspecto:

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

O si es importante para que usted mantenga con IDictionary, luego seguir con el diseño de compuestos envolviendo una instancia Dictionary<Guid, List<string>> en la clase que implementa las IDictionary<Guid, List<string>> y sólo delegados todos los métodos a el Diccionario envuelto.

Answer 5

Al menos, envuelva su estructura de datos "huele mal" en una clase, de modo que pueda encapsular su implementación al proporcionar una API limpia para consultar/modificar los datos sin que el código del cliente tenga dudas sobre los detalles de almacenamiento.

A continuación, podrá cambiar la implementación de la estructura de datos en cualquier momento en el futuro. Si no hace esto ahora, puede arrepentirse más tarde cuando tenga 10 o 100 veces más código de cliente, y es demasiado costoso/doloroso para refactorizar.

Puede que mientras lo mantenga encapsulado ordenadamente, y funciona, el hecho de que sienta que huele mal no es realmente relevante, siempre que el código haga lo que necesita hacer y que sea fácil de mantener, allí no tiene sentido invertir mucho más tiempo en ello.(No estoy abogando por mantener el código sucio, pero tenemos que equilibrar las realidades comerciales con nuestro deseo de lograr la perfección teórica; si el código funciona y no está causando ningún problema, puede que no siempre sea un buen uso de su tiempo para mejorar o refactorizar. en lugar de ello, es posible que simplemente neutralizar los riesgos mediante el encapsulado en una clase y aislar la aplicación sucia de sus clientes es suficiente por ahora)