¿Hay algún beneficio al declarar una propiedad privada con un getter y setter?

Question

estoy revisando el código de otro desarrollador y ha escrito mucho código para las variables de nivel de clase que es similar al siguiente:

/// <summary> 
    /// how often to check for messages 
    /// </summary> 
    private int CheckForMessagesMilliSeconds { get; set; } 

    /// <summary> 
    /// application path 
    /// </summary> 
    private string AppPath { get; set; } 

¿No codificación de esta manera añadir una sobrecarga innecesaria ya que la variable es privado?

¿No estoy considerando una situación en la que este patrón de codificación es necesario para las variables privadas?

Answer 1

Las propiedades privadas le proporcionan un nivel de abstracción cuando asigna el valor a la variable privada (creada por el compilador). No es menos eficiente hacerlo, y si necesita cambiar la forma en que se realiza la tarea en el futuro, solo debe preocuparse de actualizarla en un solo lugar.

También puede proporcionar consistencia en una aplicación. Si todas las asignaciones se realizan a través de propiedades, algunas pueden validar los valores de asignación, mientras que otras no. Para la persona que interactúa con la propiedad, no hay diferencia entre los que validan y los que no. (y de esta forma alguien no asigna accidentalmente un valor a una variable local que no valida.)

Answer 2

IIRC, el compilador optimizará el acceso a las propiedades y terminará siendo referencias directas a las campo de respaldo generado.

Esto dará como resultado la ausencia de gastos generales, limpieza y un código más fácil de mantener.

Answer 3

Eso es como decir que los métodos privados no son beneficiosos, ya que añaden gastos generales innecesarios y nadie fuera de la clase los va a usar.

Las propiedades le dan un punto de contacto entre una variable y el resto de su código. En el futuro, es posible que desee agregar la comprobación de errores o actualizar algún otro valor siempre que la variable cambie, y las propiedades le permitirán hacerlo.

Answer 4

la salida este enlace:

http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/3f580715-9d84-4468-92a1-7cf4831aa3f6

Ellos están discutiendo sobre el mismo tema.

HTH

Answer 5

No, el compilador JIT convertirá propiedad tiene acceso directo en la variable accede en el campo de respaldo, por lo que no es menos eficaz que utilizar directamente una variable miembro.

La ventaja es que si alguna vez desea convertir la propiedad en una implementación no trivial, puede agregar código al get/set para permitir controles o comportamientos adicionales o utilizar un mecanismo de almacenamiento diferente para una propiedad sin tener para refactorizar cualquier código del cliente (en este caso, todos en la misma clase).

Answer 6

Yo diría que es una buena práctica tener el hábito de usar propiedades en lugar de campos.
Es posible que la sobrecarga sea mínima o inexistente, ya que el JIT puede alinear el captador y el colocador. Entonces, aunque no es obligatorio, no hay nada de malo en hacerlo de esta manera.

Answer 7

El problema de rendimiento es probablemente insignificante o inexistente, pero requiere que escriba 9 caracteres más (+ espacios) sin ganancia.Si luego desea convertir sus campos a propiedades, puede hacerlo de todos modos porque los campos y las propiedades son totalmente compatibles con la fuente (siempre que no utilice tipos de valores variables).

Answer 8

No veo ningún beneficio real en esto, aunque tampoco veo ningún daño. Si va a convertir la propiedad en algo público en el futuro, puede ahorrarle un poco de tipeo. ¿Pero con qué frecuencia conviertes miembros privados en propiedades públicas? Y cuando lo haga, probablemente sea solo uno o dos elementos de muchos miembros que su clase contiene. Si va a realizar una implementación no trivial o agregará algún tipo de validación, deberá convertir la propiedad de implementación automática en una con un campo de respaldo real, lo que anula cualquier beneficio de simplicidad que pueda haber pensado que obtuvo en el comienzo.

Para mí, parece una cuestión de preferencia personal, sin impacto en el rendimiento, y un pequeño impacto (tanto positivo como negativo) al realizar cambios en el futuro.