Aunque los campos y las propiedades parecen ser similares entre sí, son 2 elementos de lenguaje completamente diferentes.
Los campos son el único mecanismo para almacenar datos a nivel de clase. Los campos son variables conceptuales en el ámbito de clase. Si desea almacenar algunos datos en instancias de sus clases (objetos), debe usar campos. No hay otra opción. Sin embargo, las propiedades no pueden almacenar ningún dato, puede parecer que pueden hacerlo. Ver abajo.
Las propiedades, por otro lado, nunca almacenan datos. Son solo los pares de métodos (get y set) que se pueden llamar sintácticamente de forma similar a los campos y en la mayoría de los casos acceden a los campos (para leer o escribir), lo que es fuente de cierta confusión. Pero debido a que los métodos de propiedad son (con algunas limitaciones, como el prototipo fijo) métodos regulares de C #, pueden hacer lo que puedan hacer los métodos regulares. Significa que pueden tener 1000 líneas de código, pueden lanzar excepciones, llamar a otros métodos, pueden ser incluso virtuales, abstractos o anulados. Lo que hace que las propiedades sean especiales es el hecho de que el compilador de C # almacena algunos metadatos adicionales en ensamblajes que se pueden usar para buscar propiedades específicas, característica ampliamente utilizada.
Obtener y establecer métodos de propiedad tiene los siguientes prototipos.
PROPERTY_TYPE get();
void set(PROPERTY_TYPE value);
Por lo tanto, significa que las propiedades se pueden 'emular' definiendo un campo y 2 métodos correspondientes.
class PropertyEmulation
{
private string MSomeValue;
public string GetSomeValue()
{
return(MSomeValue);
}
public void SetSomeValue(string value)
{
MSomeValue=value;
}
}
Dicha emulación de propiedades es típica para lenguajes de programación que no admiten propiedades, como C ++ estándar. En C #, siempre debe preferir las propiedades como la forma de acceder a sus campos.
Debido a que solo los campos pueden almacenar datos, significa que más campos contiene la clase, más objetos de memoria de esa clase consumirán. Por otro lado, agregar nuevas propiedades a una clase no hace que los objetos de esa clase sean más grandes. Aquí está el ejemplo.
class OneHundredFields
{
public int Field1;
public int Field2;
...
public int Field100;
}
OneHundredFields Instance=new OneHundredFields() // Variable 'Instance' consumes 100*sizeof(int) bytes of memory.
class OneHundredProperties
{
public int Property1
{
get
{
return(1000);
}
set
{
// Empty.
}
}
public int Property2
{
get
{
return(1000);
}
set
{
// Empty.
}
}
...
public int Property100
{
get
{
return(1000);
}
set
{
// Empty.
}
}
}
OneHundredProperties Instance=new OneHundredProperties() // !!!!! Variable 'Instance' consumes 0 bytes of memory. (In fact a some bytes are consumed becasue every object contais some auxiliarity data, but size doesn't depend on number of properties).
Aunque los métodos de propiedad pueden hacer cualquier cosa, en la mayoría de los casos sirven como una forma de acceder a los campos de los objetos. Si desea que un campo sea accesible para otras clases, puede hacerlo de 2 maneras.
- Hacer que los campos sean públicos, no es aconsejable.
- Usando propiedades.
Aquí hay una clase que usa campos públicos.
class Name
{
public string FullName;
public int YearOfBirth;
public int Age;
}
Name name=new Name();
name.FullName="Tim Anderson";
name.YearOfBirth=1979;
name.Age=40;
Si bien el código es perfectamente válido, desde el punto de vista del diseño, tiene varios inconvenientes. Debido a que los campos pueden ser leídos y escritos, no puede evitar que el usuario escriba en los campos. Puede aplicar la readonlypalabra clave, pero de esta manera, debe inicializar los campos de solo lectura solo en el constructor. Además, nada le impide almacenar valores no válidos en sus campos.
name.FullName=null;
name.YearOfBirth=2200;
name.Age=-140;
El código es válido, todas las asignaciones se ejecutarán aunque sean ilógicas. Agetiene un valor negativo, YearOfBirthestá lejos en el futuro y no corresponde a Age y FullNamees nulo. Con los campos no puede evitar que los usuarios class Namecometan tales errores.
Aquí hay un código con propiedades que corrige estos problemas.
class Name
{
private string MFullName="";
private int MYearOfBirth;
public string FullName
{
get
{
return(MFullName);
}
set
{
if (value==null)
{
throw(new InvalidOperationException("Error !"));
}
MFullName=value;
}
}
public int YearOfBirth
{
get
{
return(MYearOfBirth);
}
set
{
if (MYearOfBirth<1900 || MYearOfBirth>DateTime.Now.Year)
{
throw(new InvalidOperationException("Error !"));
}
MYearOfBirth=value;
}
}
public int Age
{
get
{
return(DateTime.Now.Year-MYearOfBirth);
}
}
public string FullNameInUppercase
{
get
{
return(MFullName.ToUpper());
}
}
}
La versión actualizada de la clase tiene las siguientes ventajas.
FullNamey YearOfBirthse verifican los valores no válidos.AgeNo es escribible. Se calcula a partir del YearOfBirthaño en curso.- Una nueva propiedad se
FullNameInUppercaseconvierte FullNameen CASO SUPERIOR. Este es un pequeño ejemplo artificial del uso de propiedades, donde las propiedades se usan comúnmente para presentar valores de campo en el formato más apropiado para el usuario, por ejemplo, usando la configuración regional actual en un DateTimeformato numérico específico .
Además de esto, las propiedades se pueden definir como virtuales o anuladas, simplemente porque son métodos regulares de .NET. Se aplican las mismas reglas para los métodos de propiedad que para los métodos regulares.
C # también admite indexadores, que son las propiedades que tienen un parámetro de índice en los métodos de propiedad. Aquí está el ejemplo.
class MyList
{
private string[] MBuffer;
public MyList()
{
MBuffer=new string[100];
}
public string this[int Index]
{
get
{
return(MBuffer[Index]);
}
set
{
MBuffer[Index]=value;
}
}
}
MyList List=new MyList();
List[10]="ABC";
Console.WriteLine(List[10]);
Desde C # 3.0 le permite definir propiedades automáticas. Aquí está el ejemplo.
class AutoProps
{
public int Value1
{
get;
set;
}
public int Value2
{
get;
set;
}
}
Aunque class AutoPropssolo contiene propiedades (o parece), puede almacenar 2 valores y el tamaño de los objetos de esta clase es igual a sizeof(Value1)+sizeof(Value2)= 4 + 4 = 8 bytes.
La razón de esto es simple. Cuando define una propiedad automática, el compilador de C # genera un código automático que contiene un campo oculto y una propiedad con métodos de propiedad que acceden a este campo oculto. Aquí está el compilador de código produce.
Aquí hay un código generado por ILSpy a partir del ensamblado compilado. La clase contiene campos y propiedades ocultos generados.
internal class AutoProps
{
[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private int <Value1>k__BackingField;
[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private int <Value2>k__BackingField;
public int Value1
{
[CompilerGenerated]
get
{
return <Value1>k__BackingField;
}
[CompilerGenerated]
set
{
<Value1>k__BackingField = value;
}
}
public int Value2
{
[CompilerGenerated]
get
{
return <Value2>k__BackingField;
}
[CompilerGenerated]
set
{
<Value2>k__BackingField = value;
}
}
}
Entonces, como puede ver, el compilador todavía usa los campos para almacenar los valores, ya que los campos son la única forma de almacenar valores en los objetos.
Como puede ver, aunque las propiedades y los campos tienen una sintaxis de uso similar, son conceptos muy diferentes. Incluso si utiliza propiedades o eventos automáticos, el compilador genera campos ocultos donde se almacenan los datos reales.
Si necesita hacer que un valor de campo sea accesible para el mundo exterior (usuarios de su clase), no use campos públicos o protegidos. Los campos siempre deben marcarse como privados. Las propiedades le permiten realizar comprobaciones de valor, formateo, conversiones, etc. y, en general, hacen que su código sea más seguro, más legible y más extensible para futuras modificaciones.