¿Evaluar en captador de propiedades o al crear una instancia?

Question

Ok, una pregunta fácil.

Antes que nada, debo decir que mi preocupación no es rendimiento. Soy totalmente consciente de que cualquier costo de rendimiento que una u otra opción impliquen probablemente carezca de sentido y ni siquiera valga la pena considerarlo en los escenarios normales. Tiene más que ver con los estándares de diseño y la curiosidad sobre cómo lo haría la mayoría de los codificadores.

Ok, así que la pregunta es bastante simple:

Supongamos que tengo un ComplexNumberstruct que podría poner en práctica la siguiente manera:

public struct Complex : IEquatable<Complex>, IFormattable 
{ 
    readonly double realPart, imaginaryPart, magnitude, argument; 
    readonly static Complex j = new Complex(0, 1); 

    public Complex(double realPart, double imaginaryPart) 
    { 
     this.realPart = realPart; 
     this.imaginaryPart = imaginaryPart; 
     this.magnitude = Math.Sqrt(Math.Pow(realPart, 2) + Math.Pow(imaginaryPart, 2)); 
     this.argument = Math.Atan2(imaginaryPart, realPart); 
    } 

    public double RealPart { get { return this.realPart; } } 
    public double ImaginaryPart { get { return this.imaginaryPart; } } 
    public double Magnitude { get { return this.magnitude; } } 
    public double Argument { get { return this.argument; } } 

    public static Complex J { get { return Complex.j; } } 
    ... 
} 

Los Magnitude y Argument propiedades tienen un respaldo campos que se encuentran evaluado en tiempo de construcción. Otra opción sería simplemente evaluar el valor correspondiente en cualquier getter.

¿Cuál es la forma más recomendable de hacerlo? ¿Existe algún estándar de codificación que recomiende alguna opción por el solo hecho de tener un estándar? Y si no hay uno, ¿cuál es normalmente la opción preferida? ¿O depende solo del rendimiento, que en mi caso es irrelevante?

Answer 1

[ACTUALIZADO A CONTINUACIÓN:]

¿Por qué evaluar en el captador y no en la incubadora? Evaluaría el valor tal como se establece. De esta forma, el valor correcto se puede usar en métodos privados.

Establecer valores predeterminados en c'tor, evaluar en setter.

Siempre leerá el valor con más frecuencia que al establecerlo, por lo que, por motivos de rendimiento, debe hacer la evaluación en el colocador; se ejecutará con menos frecuencia.

[ACTUALIZACIÓN:] Si la propiedad es de solo lectura, evalúe en el administrador, por el mismo razonamiento que el anterior (rendimiento: solo hará la evaluación una vez). Sé que dices que el rendimiento no es un problema, pero si no hay motivos para no hacerlo de la mejor manera, debería hacerlo así.

Answer 2

C'tor debe inicializar los miembros con valores predeterminados.

Definitivamente, el rendimiento puede ser un problema si mueve el código a getter porque evaluará cada vez que se invoca getter.

Sin embargo, el contrato de getter dice que obtendrá el valor. por lo que la parte de cálculo debe evitarse tanto como sea posible en el bloque getter.

Y también debe tratar de evitar el uso de valores sucios. si configura el Magnitude (por ejemplo) en getter, pero intente acceder a él dentro de la clase directamente; podrías terminar usando el valor equivocado.

Por lo tanto, si la pregunta es sobre la iniciación de las variables miembro, hágalo en c'tor. es por eso que es creado por diseñadores de idiomas.

Answer 3

Yo preferiría calcular los valores directamente en getters, porque es más legible: si quieres saber qué hace Argument, solo mira su código. Si almacenó en caché el valor en un campo como el que tiene ahora, debe ir a la propiedad Argument → argument campo → constructor.

Si el rendimiento sí importó, obviamente la forma correcta de averiguar qué opción es mejor en su caso es la creación de perfiles. Pero como , supongo que, creo que la versión con valores en caché en los campos también será más lenta, especialmente si no usas los valores calculados con frecuencia. Esto se debe a que struct s se copian todo el tiempo y esos campos hacen que el struct sea el doble de grande.