2010-01-08 17 views
32

Tengo varias entidades que tienen campos calculados en ellas, como TotalCost. En este momento los tengo a todos como propiedades, pero me pregunto si realmente deberían ser métodos. ¿Hay un estándar de C# para esto?C# propiedades de solo lectura calculadas, ¿deberían ser métodos?

public class WorkOrder 
{ 
    public int LaborHours { get; set; } 
    public decimal LaborRate { get; set; } 

    // Should this be LaborCost()? 
    public decimal LaborCost 
    { 
     get 
     { 
      return LaborHours * LaborRate; 
     } 
    } 
} 
+4

Lo tienes perfectamente correcto. Lo único que agregaría es 'this' antes de' LaborHours' y 'LaborRate', pero eso es solo por legibilidad. –

+11

Y personalmente no añadiría 'esto' ya que mi preferencia es que reduce la legibilidad ... :-) – Cellfish

+0

@Cellfish: De acuerdo, tratemos de reducir la cantidad de verbosidad innecesaria por favor. –

Respuesta

43

Está bien utilizar propiedades calculadas en lugar de métodos, siempre que el cálculo no tome un tiempo notable

Ver Property usage guidelines

+2

+1 para buscar el enlace. –

+1

+1 vinculado directamente desde la fuente –

+0

Me complace escuchar que esto no es una mala práctica. Me gusta bastante después de venir de Java. Gracias por el enlace! –

0

En mi opinión, es una preferencia; es lo que quieres hacer Hago propretios en la mayoría de los casos, a menos que haya lógica involucrada. Además, si necesita pasar parámetros para cambiar la funcionalidad, obviamente se aplicaría un método ...

1

Los dejaría como propiedades. Pero no hay una razón "estándar" para hacer las cosas de una manera u otra. Si estás solo, haz lo que más te guste. Si está en un equipo, siga las convenciones que el resto de su equipo está siguiendo.

14

Creo que los métodos deben realizar acciones en el objeto, generalmente cambian el estado del objeto. Las propiedades deben reflejar el estado actual del objeto incluso si se calcula la propiedad. Entonces deberías mantener tus propiedades IMO.

+0

¿Qué pasa si la operación implica una cantidad significativa de cálculo? –

+7

Los programadores suponen que el acceso a la propiedad es de tiempo constante, por lo que Microsoft sugiere que no se haga ningún cálculo complejo en las propiedades, sino que se usen métodos cuando haya un procesamiento significativo involucrado. –

+1

No importa. Ya sea una propiedad o un método, no le dice nada a la persona que llama. –

0

Depende, si sus "propiedades" se convierten en mamuts y requieren una gran cantidad de lógica comercial, no deberían ser propiedades, debería haber un método. El ejemplo que ha publicado se ve como una propiedad. No hay una forma estándar de hacerlo, vaya con su instinto visceral; si parece que tiene que hacer mucho, probablemente necesites un método.

3

Si son a) livianos yb) no tienen efectos secundarios, los convertiría en Propiedades.

Ligero es un poco confuso, por supuesto, pero la regla general es: si alguna vez me tengo que preocupar de llamar a una propiedad (ya sea en un bucle o en cualquier otro lugar), posiblemente sea un método.

+1

También podría tener una propiedad diferida que puede ser forzada a volver a calcular en función de algún método explícito [como Refesh()] o evento implícito [tal como tiempo de espera o caché sucia]. Esto permitiría propiedades para una fácil unión/serialización y la capacidad de mantener los datos actualizados. –

+0

Muy cierto. Las propiedades de carga lenta son raras, pero útiles. –

6

Creo que todas deberían ser propiedades. Mientras no cambie el estado del objeto, estoy de acuerdo con él como una propiedad.

Además, si estoy utilizando su clase para el enlace de datos (WPF, etc.), entonces puedo enlazar directamente a su propiedad sin tener que modificar/extender la clase.

+2

+1 para la unión de datos – ChrisF

+0

+1 para el enlace de datos también! Bien hecho. –

+1

De acuerdo, aunque es importante recordar que si desea vincularse a la propiedad calculada, los otros adaptadores de propiedad o métodos de mutador relevantes deben generar el evento PropertyChanged para la propiedad calculada. – itowlson

0

Si una propiedad es particularmente costosa de calcular, podría cambiarla por un método GetWhatever(). Esto sirve como una pista para quien utiliza mi clase de que este valor requiere un trabajo importante para llegar, y la persona que llama debe almacenar en caché el valor en lugar de llamar al método varias veces.

Los cálculos triviales son perfectamente apropiados dentro de las propiedades.

0

De todos modos, se trata de azúcar sintáctico, así que quiero que sea convencional en su equipo, o lo que prefiera, siempre y cuando solo devuelva información sobre el objeto y no lo cambie ni interactúe con otros objetos.

0

MSDN contiene información sobre este here

diseñadores biblioteca de clases a menudo deben decidir entre la implementación de un miembro de la clase como una propiedad o un método. En en general, los métodos representan acciones y las propiedades representan datos.

¿Cuál crees que es? Una acción calcular/obtenerLaborCost o datos?

WorkOrder workOrder = new WorkOrder(); 
workOrder.LaborHours = 8; 
workOrder.LaborRate = 20; 

decimal cost = workOrder.LaborCost; // This is OK here 

pero si usted va a hacer esto para el mismo objeto también:

worOrder.LaborHours = 18; 
decimal newCost = workOrder.LaborCost 

Ahora bien, esto puede no ser una propiedad. Sería mucho mejor ser un método.

0

A veces, también debe tener en cuenta lo que está modelando ... En algunos dominios, los valores calculados a menudo o se espera que sean un atributo del modelo: una propiedad. Si este fuera el caso, entonces escríbalo como una propiedad aunque el cálculo no sea del todo trivial o un poco costoso de computar. Solo documente en su API o implemente algún mecanismo de almacenamiento en caché para minimizar el recálculo de esta propiedad.

Cuestiones relacionadas