La mejor manera de utilizar una propiedad para hacer referencia a un par clave-valor en un diccionario [cerrado]

Question

Este es un asunto bastante trivial, pero tengo curiosidad por escuchar la opinión de la gente al respecto.

Si tengo un diccionario al que accedo a través de propiedades, ¿cuál de estos formatos preferiría para la propiedad?

/// <summary>
/// This class's FirstProperty property
/// </summary>
[DefaultValue("myValue")]
public string FirstProperty {
    get {
        return Dictionary["myKey"];
    }
    set {
        Dictionary["myKey"] = value;
    }

Esta es probablemente la forma típica de hacerlo.Es bastante eficiente, fácil de entender, etc.La única desventaja es que con una clave más larga o más compleja sería posible escribirla mal o cambiar solo una instancia o algo así, lo que me lleva a esto:

/// <summary>
/// This class's SecondProperty property
/// </summary>
[DefaultValue("myValue")]
private const string DICT_MYKEY = "myKey"
public string SecondProperty {
    get {
        return Dictionary[DICT_MYKEY];
    }
    set {
        Dictionary[DICT_MYKEY] = value;
    }

Lo cual es un poco más complicado, pero parece ofrecer seguridad adicional y está más cerca de lo que yo consideraría la solución "Código completo".La desventaja es que cuando también tienes un bloque /// y un bloque [DefaultValue()] encima de la propiedad, comienza a llenarse un poco allí.

Entonces, ¿cuál te gusta más y por qué?¿Alguien tiene alguna idea mejor?

Answer 1

Me gusta el segundo simplemente porque evitar cadenas/números mágicos en el código es algo bueno.En mi opinión, si necesita hacer referencia a un número o cadena literal en el código más de una vez, debe ser una constante.En la mayoría de los casos, incluso si sólo se usa una vez, debe estar en un estado constante.

Answer 2

Estoy de acuerdo con @Glenn en un punto de vista puramente quisquilloso.La respuesta es lo que funcione para usted.Todo este código se desarrolla en 10 líneas (si incluye la última llave omitida).Nadie se perderá y la posibilidad de escribir mal es bastante pequeña (no imposible, pero sí muy pequeña).Por otro lado, si usó la clave en otro lugar, DEFINITIVAMENTE vaya con la constante.

Personalmente, me enfadaría contigo por tu estilo de tirantes.:) ¡Es una broma!Realmente es una cuestión de estilo.

Answer 3

Esto no responde a su pregunta, pero no creo que "DefaultValue" signifique lo que usted cree que significa.No establece un valor predeterminado para su propiedad.

Ver MSDN y esta pregunta para más detalles.

Answer 4

Mucha gente probablemente argumentaría que la segunda opción es "correcta", porque cualquier valor utilizado más de una vez debe refactorizarse y convertirse en una constante.Lo más probable es que utilice la primera opción.Ya se ha acercado a la solución "Código completo" al encapsular la entrada del diccionario en una propiedad de tipo seguro.Esto reduce la posibilidad de equivocarse al recuperar la entrada incorrecta del Diccionario en su implementación.Sólo hay 2 lugares donde podrías equivocarte al escribir "myKey", en el getter y setter, y esto sería muy fácil de detectar.

La segunda opción sería demasiado complicada.

Answer 5

Cuando solo usas una cuerda mágica en un contexto, como lo haces, creo que está bien.
Pero si alguna vez necesitas usar la clave en otra parte de la clase, ve const.

Answer 6

Puede hacer coincidir los nombres de las propiedades con las claves y utilizar la reflexión para obtener el nombre de la búsqueda.

public string FirstProperty {
get {
    return Dictionary[PropertyName()];
}
set {
    Dictionary[PropertyName()] = value;
}

private string PropertyName()
{
    return new StackFrame(1).GetMethod().Name.Substring(4);
}

Esto tiene el beneficio adicional de hacer que todas las implementaciones de sus propiedades sean idénticas, por lo que puede configurarlas en Visual Studio como fragmentos de código si lo desea.

Answer 7

@Joel, no quieres contar con StackFrame. en línea puede arruinarte el día cuando menos lo esperas.

Pero a la pregunta:De cualquier manera, realmente no importa mucho.