Diferencias entre campos privados y propiedades privadas

Question

¿Cuál es la diferencia entre usar propiedades privadas en lugar de campos privados?

private String MyValue { get; set; }

// instead of

private String _myValue;

public void DoSomething()
{
   MyValue = "Test";

   // Instead of

   _myValue = "Test";
}

¿Hay algún problema de rendimiento? o simplemente una convención de nomenclatura?

Answer 1

Las propiedades privadas le permiten abstraer sus datos internos para que los cambios en la representación interna no tengan que afectar otras partes de su implementación, incluso en la misma clase. Los campos privados no ofrecen esta ventaja. Con las propiedades automáticas en C # 3.0, rara vez veo la necesidad de implementar campos directamente, privados o públicos.

Answer 2

La gran ganancia que puede obtener de una propiedad (privada, pública, ...) es que puede producir un valor calculado frente a un valor establecido. Por ejemplo

class Person { 
  private DateTime _birthday;
  private int _age { get { return (DateTime.Now - _birthday).TotalYears; }
}

La ventaja de este patrón es que solo se debe actualizar un valor para N otros valores para reflejar el cambio. Esto es cierto para las propiedades independientemente de la accesibilidad. No hay una ventaja específica de una propiedad privada frente a una propiedad no privada (aparte de ser privada, por supuesto)

Answer 3

Rara vez querría hacer que una propiedad sea privada. La disposición para que una propiedad sea privada se proporciona solo en aras de la integridad. Y si su propiedad es simplemente obtener / establecer el valor del campo, entonces no hay diferencia de rendimiento porque lo más probable es que el compilador JIT lo incorpore.

Answer 4

Aparte de lo que ya se ha respondido, rendimiento, sintaxis y completitud, he visto un caso válido para propiedades privadas en lugar de un campo privado:

public class Item
{
    private Item _parent;
    private List<Item> _children;

    public void Add(Item child)
    {
        if (child._parent != null)
        {
            throw new Exception("Child already has a parent");
        }
        _children.Add(child);
        child._parent=this;
    }
}

Digamos que no queremos exponer Parent por cualquier razón, pero también podríamos querer hacer verificaciones de validación. ¿Se debe poder agregar un padre como hijo a uno de sus hijos?

Para resolver esto, puede convertir esto en una propiedad y realizar una comprobación de referencias circulares.

Answer 5

El acceso a la propiedad será (fraccionalmente) más lento ya que llamará al getter / setter. El beneficio es que puede hacer la validación de datos, que luego puede filtrarse a herederos si cambia la propiedad a proteger, por ejemplo.

Answer 6

Cuando se trata de acceso privado, las diferencias son muy pequeñas. Sí, hay un impacto en el rendimiento (que puede ser optimizado por el JIT). Las propiedades de envío representan una llamada al método, en lugar de un acceso directo a la dirección.

La principal ventaja de usar propiedades es permitir cambiar la implementación sin cambiar la firma externa requerida. Dado que estos son de acceso privado, cualquier cambio en la implementación solo afecta el código local.

Cuando trato con miembros privados, no veo ninguna ventaja obtenida de las propiedades, excepto por las convenciones de su equipo.