Propiedades vs Campos en VB 2010
Una de las nuevas características de VB 2010 ó VB 10 es la nueva declaración de lo que son las Propiedades. Dicho de otra forma, las propiedades autoimplementadas.
Ahora, en VB 10 podemos declarar una propiedad de la siguiente forma:
Public Property Name() As String
La discusión más lógica que puede salir de nuestros labios es la que una persona le hizo a Jonathan Aneja (Microsoft y responsable de VB) sobre este asunto.
¿Para qué usar Public Property Name() As String en lugar de Public Name As String?.
Por esa razón, Jonathan ha escrito una entrada en su blog indicando el porqué es mejor usar Properties (Propiedades) en lugar de Fields (Campos), así como sus ventajas.
Os recomiendo la lectura de este artículo en la sección de referencias de esta entrada porque le aclarará a más de uno esas dudas.
No obstante, añadiré algunas anotaciones personales sobre «lo que no se ve», sobre la parte «posterior» de las propiedades autoimplementadas.
Al declarar una propiedad autoimplementada como por ejemplo Public Property Name() As String, en realidad y de cara al compilador, la estaremos declarando como hemos hecho siempre, indicando su Get y su Set.
De hecho, si miramos el código en Reflector, veremos que éste tiene el siguiente aspecto:
Public Property Name As String
Get
Return Me._Name
End Get
Set(ByVal AutoPropertyValue As String)
Me._Name = AutoPropertyValue
End Set
End Property
Curiosamente, el compilador se ha encargado de crear las propiedades en su manera general, e implícitamente una variable privada que permita almacenar y establecer el valor de la propiedad:
<CompilerGenerated, DebuggerBrowsable(DebuggerBrowsableState.Never)> _
Private _Name As String
Ahora bien, ¿qué ocurre si definimos una variable del tipo Private _Name As String?.
En este caso el compilador tiene un problema, ya que internamente, la propiedad Name define implícitamente a _Name, y por sí solo, es incapaz de definir implícitamente a otra variable.
De hecho, el compilador de Visual Studio 2010 indica en tiempo de diseño el siguente mensaje de error:
property ‘Name’ implicitly defines ‘_Name’, which conflicts with a member of the same name in class ‘Form1’.
Esto es así porque el compilador de Visual Basic declara implícitamente a las variables de las propiedades con el caracter de subrayado seguido del nombre de la propiedad.
Comento esto para que únicamente se tenga en cuenta cuando trabajemos con Visual Basic 2010, y por si a alguien se le ocurre declarar variables con el caracter subrayado delante del nombre de la declaración, para que no lo hagan porque no sería una buena práctica de acuerdo a lo que hace «por debajo» el compilador. 😉
Referencia: