example - params comments c#

C#Propiedades automáticas

Question

Estoy un poco confundido sobre el punto de propiedades automáticas en C # por ejemplo

public string Forename{ get; set; }

Me da que está guardando código al no tener que declarar una variable privada, pero ¿cuál es el sentido de una propiedad cuando no está utilizando ninguna lógica get o set? ¿Por qué no solo usar

public string Forename;

No estoy seguro de cuál es la diferencia entre estas dos afirmaciones. ¿Siempre pensé que usabas propiedades si querías una lógica de obtención / configuración adicional?

Answer 1

No estoy seguro de cuál es la diferencia entre estas dos afirmaciones. ¿Siempre pensé que usabas propiedades si querías una lógica de obtención / configuración adicional?

En el primer caso, el compilador agregará automáticamente un campo y ajustará la propiedad. Básicamente es el equivalente a hacer:

private string forename;
public string Forename
{
get
{
return this.forename;
}
set
{
this.forename = value;
}
}

Hay muchas ventajas en usar propiedades sobre campos. Incluso si no necesita algunas de las razones específicas, como la vinculación de datos, esto ayuda a proteger su API en el futuro.

El principal problema es que, si crea un campo, pero en la v2 de su aplicación necesita una propiedad, romperá la API. Al usar una propiedad automática por adelantado, tiene el potencial de cambiar su API en cualquier momento, sin preocuparse por problemas de compatibilidad de fuente o binario.

Answer 2

Al agregar propiedades automáticas, el compilador agregará la lógica de establecer conjuntos en la aplicación, esto significa que si luego agrega esta lógica, y las referencias a su propiedad desde las bibliotecas externas seguirán funcionando.

Si migraste de una variable pública a una propiedad, esto sería un cambio radical para otras bibliotecas que hacen referencia a la tuya, por lo tanto, ¿por qué no comenzar con una propiedad de auto? :)

Answer 3

Considere la posibilidad de ver algunos temas relacionados sobre la diferencia entre las propiedades automáticas y los campos públicos , campos vs propiedades , propiedades automáticas, ¿útiles o no? , Por qué no utilizar los campos públicos

Answer 4

Eche un vistazo al siguiente código y explicación.
The most common implementation for a property is getter or a setter that simply reads and writes to a private field of the same type as a property. An automatic property declaration instructs the compiler to provide this implementation. The compiler automatically generates a private backing field.
Mira en el siguiente código: -

 public class Stock
{
decimal currentPrice ; // private backing field.
public decimal CurrentPrice
{
get { return currentPrice ; }
set { currentPrice = value ; }
}
}

El mismo código se puede volver a escribir como:

 public class Stock
{
public decimal CurrentPrice { get ; set ; } // The compiler will auto generate a backing field.
}

FUENTE: - C # en pocas palabras

Answer 5

Las propiedades pueden tener código puesto en ellas sin romper el contrato, los campos no pueden tener código puesto en ellos sin cambiarlos a propiedades (y romper la interfaz). Las propiedades se pueden leer solo o solo escribir, los campos no. Las propiedades pueden estar vinculadas a datos, los campos no pueden.

Answer 6

Los miembros de datos públicos son malvados (dado que el objeto no controla la modificación de su propio estado: se convierte en una variable global). Rompe la encapsulación: un principio de OOP.

Las propiedades automáticas están ahí para proporcionar encapsulamiento y evitar el trabajo pesado de escribir código de placa de caldera para propiedades simples.

public string ID { get; set;}

Puede cambiar las propiedades automáticas a propiedades no automáticas en el futuro (por ejemplo, tiene alguna validación en un sistema por ejemplo) ... y no romper clientes existentes.

string m_ID;
public string ID
{
get { return m_ID; }
set
{
//validate value conforms to a certain pattern via a regex match
m_ID = value;
}
}

No puede hacer lo mismo con los atributos de datos públicos. Cambiar un atributo de datos a una propiedad obligará a los clientes existentes a recompilar antes de que puedan interactuar de nuevo.

Answer 7

No todas las propiedades necesitan una lógica get / set. Si lo hacen, usas una variable privada. Por ejemplo, en un patrón MV-something, su modelo no tendría mucha lógica. Pero puedes mezclar y combinar según sea necesario.

Si tuviera que usar un campo como el que sugirió en lugar de una propiedad, no puede, por ejemplo, definir una interfaz para describir su clase correctamente, ya que las interfaces no pueden contener campos de datos.

Answer 8

Por un lado, puede establecer la propiedad en virtual e implementar lógica en una clase heredada. También puede implementar lógica en la misma clase después y no habrá efectos secundarios en ningún código que dependa de la clase.

Answer 9

Puedes escribir

public string Forename{ get; private set; }

para obtener propiedades de solo lectura ... Aún no es tan versátil como las propiedades reales, pero es un compromiso que para algunas obras.

Answer 10

Se supone que esperas agregar la lógica más tarde.

Si lo hace y lo tiene como propiedad desde el principio, no tendrá que volver a generar el código dependiente. Si lo cambia de una variable a una propiedad, entonces deberá hacerlo.

Answer 11

Una propiedad es como un contrato, y puede cambiar la implementación de una propiedad sin afectar a los clientes que usan sus clases y propiedades. Puede que hoy no tenga ninguna lógica, pero a medida que cambien los requisitos del negocio y si desea introducir algún código, las propiedades son su apuesta más segura. Los siguientes 2 enlaces son excelentes tutoriales en video de c #. El primero explica la necesidad de propiedades sobre solo usar campos y el segundo video explica diferentes tipos de propiedades. Los encontré muy útiles.

Necesidad de las propiedades en C #

Propiedades en C #, Solo lectura, Solo escritura, Lectura / escritura, Implementación automática