visual una studio sirve que propiedades propiedad para metodos entre diferencia crear clase campo automaticamente accesores c# standards

c# - studio - propiedad en una clase



C#propiedades de solo lectura calculadas, ¿deberían ser métodos? (11)

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?

public class WorkOrder { public int LaborHours { get; set; } public decimal LaborRate { get; set; } // Should this be LaborCost()? public decimal LaborCost { get { return LaborHours * LaborRate; } } }


A veces, debe considerar también 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.


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.


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 usando su clase para el enlace de datos (WPF, etc.), entonces puedo enlazar directamente a su propiedad sin tener que modificar / extender la clase.


Depende, si sus "propiedades" se convierten en mamuts y requieren una gran cantidad de lógica empresarial, no deberían ser propiedades, debería haber un método. El ejemplo que publicaste está bien para ser 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.


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 ...


En su mayor parte, se trata de azúcar sintáctico, por lo que quiero que sea una convención 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.



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.


MSDN brinda información sobre esto here

Los diseñadores de la biblioteca de clase a menudo deben decidir entre implementar un miembro de la clase como una propiedad o un método. 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 vas a hacer esto para el mismo objeto también:

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

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


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

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


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.