creo que fue en .net 2.0, Microsoft introdujo un descriptor de acceso que se abrevia a algo así comode acceso público .net
public string Name { get; set; }
Pero ¿hay alguna diferencia real entre el código anterior, y simplemente:
public string Name;
La diferencia principal es que si más adelante necesita agregar la lógica en su getter o setter, y otros archivos DLL ya se han compilado con la suya, se puede cambiar fácilmente
public string Name { get; set; }
en
public string Name { get{/*special code*/} set{/*special code*/} }
y no será un cambio decisivo publicar su nueva DLL y no se recompilarán otras DLL.
Mientras que si ha cambiado
public string Name;
en
public string Name { get{/*special code*/} set{/*special code*/} }
entonces usted tendrá que asegurarse de que cualquier DLL que utilizan la suya se vuelven a compilar, ya que cambian el acceso a un campo en acceder a una propiedad.
Esto es obviamente un problema mayor cuando se está DLL a otros programadores de envío (como un proyecto de código abierto o como un proveedor de componentes, por ejemplo) que si usted está construyendo una aplicación para su propia auto/empleador
Interesante, por qué en el segundo caso el código compilado es diferente. ¿Cuál es la intención del campo de compilación para que todos los clientes necesiten reconstruirse tan pronto como un campo sea reemplazado por una propiedad? –
porque en el MSIL, los accesos a propiedades son un tipo especial de llamada a un método, mientras que un acceso de campo es solo un acceso de campo. –
Como un ejemplo de la diferencia: puede usar un campo como parámetro "salir" o "ref" para algún método, pero no puede hacer eso con una propiedad. Entonces, el código que usó el campo de esa manera se romperá si lo cambia a una propiedad. –
es la diferencia entre un Field y una Property. Un campo es solo una variable miembro en la instancia de la clase. Por el contrario, una propiedad es la abreviatura de dos acciones separadas - obtener y definir:
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
private string _name;
Este es un ejemplo demasiado simplista, ya que la propiedad simplemente "envuelve" el campo privado, devolviéndolo en el captador y se establece en el colocador. Sin embargo, las propiedades se vuelven muy útiles cuando se convierten en "puertas de entrada" al valor subyacente. Si el flujo de programa requiere que algo suceda cada vez que se establece el valor de un campo (por ejemplo, se activa un evento), que puede ser disparado desde el colocador de la propiedad:
set
{
this.InvokePropertyChangedEvent();
_name = value;
}
La sintaxis exacta que estás preguntando acerca se llama Auto-Implemented Properties, que es solo una abreviatura del ejemplo simple que proporcioné arriba. El compilador crea un miembro privado que obtiene y establece la propiedad.
@Rex: Pero eso no es lo que se ha preguntado en cuestión. La pregunta es sobre la diferencia entre ambas declaraciones y no sobre la diferencia entre un Campo y Propiedad. –
@curious una explicación completa de la diferencia entre las dos declaraciones requiere información de antecedentes que no podemos suponer que el OP ya tiene. El poco que está buscando está abajo al final. –
Quería escribir sobre criar eventos en mi respuesta, pero nuevamente esa no es la pregunta. –
Las propiedades automáticas se introdujeron por primera vez en C# 3.0. La diferencia entre:
public string Name { get; set; }
y
public string Name;
es que el primero declara un property mientras que el segundo un field. En OOP, las propiedades se usan para encapsular campos. Una propiedad puede tener un setter o un getter o ambos y también puede especificar un nivel de accesibilidad diferente para cada uno.
Sí, el código en la segunda línea lo pone a disposición directamente del miembro en la memoria mientras que en la primera línea tiene un nivel de indirección donde puede agregar algo de lógica en el futuro para validar y asignar de forma diferida.
Además, si usa un reflejo, tendría que buscar Property Setter y Getter para la primera línea de ejemplo y para el segundo necesitaría recuperar directamente una variable miembro.
Normalmente, el uso de propiedades es mucho mejor diseño.
La diferencia entre la declaración de propiedad de taquigrafía es que puede definirla de esta manera.
public string Name { get; private set; }
Significa que la propiedad se puede leer públicamente pero solo los miembros privados pueden escribir en ella. No puedes hacer tal cosa por un campo.
Si nos fijamos en el IL generado de declaraciones de bienes corta a mano, que encontrará que el compilador ha añadido /Miembros campos generados automáticamente a una propiedad va a leer o escribir en.
La capacidad de agregar acceso al modificador hace sentido. Usó acceso diferente en un getter y un setter muchas veces, pero no en una declaración abreviada. También me pregunté sobre esta pregunta, pero no me molesté en preguntar. Ahora está más claro. Aunque no me sorprenderá si hay otras diferencias. –
No existe una diferencia funcional en cuanto a escribir código para obtener el valor o almacenarlo. Pero hay casos en que un llamante podría esperar un campo o una propiedad y solo aceptaría uno u otro mediante el uso de la reflexión. Por ejemplo, WPF solo puede vincularse a una propiedad y no a un campo.
Una diferencia útil que encontré para los usuarios de propertygrid fue que el uso de cadena pública Nombre {get; conjunto; } podríamos establecer los datos de origen en Propertygrid fácilmente.
al declarar cadena pública Nombre; no se utilizará por completo para Propertygrid.
Es posible que desee leer esto: http://stackoverflow.com/questions/1019571/why-do-we-use-net-properties-instead-of-plain-old-get-set-functions –
http: //stackoverflow.com/questions/1272521/propertywith-no-extra-processing-vs-public-field – Groo
es una característica de AC# 3.0 (.NET 3.5) para ser exactos –