¿Cuál es la diferencia entre un campo y una propiedad?
https://stackoverflow.com/questions/295104
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
En C#, lo que hace que un campo diferente de una propiedad, y cuando un campo se utiliza en lugar de una propiedad?
Solución
Las propiedades exponen los campos. Los campos deberían (casi siempre) mantenerse privados para una clase y acceder a ellos mediante las propiedades get y set. Las propiedades proporcionan un nivel de abstracción que le permite cambiar los campos sin afectar la forma externa a la que acceden las cosas que usan su clase.
public class MyClass
{
// this is a field. It is private to your class and stores the actual data.
private string _myField;
// this is a property. When accessed it uses the underlying field,
// but only exposes the contract, which will not be affected by the underlying field
public string MyProperty
{
get
{
return _myField;
}
set
{
_myField = value;
}
}
// This is an AutoProperty (C# 3.0 and higher) - which is a shorthand syntax
// used to generate a private field for you
public int AnotherProperty{get;set;}
}
@Kent señala que no se requieren propiedades para encapsular campos, podrían hacer un cálculo en otros campos o servir para otros fines.
@GSS señala que también puede hacer otra lógica, como la validación, cuando se accede a una propiedad, otra característica útil.
Otros consejos
Los principios de programación orientados a objetos dicen que el funcionamiento interno de una clase debe estar oculto del mundo exterior. Si expone un campo, en esencia está exponiendo la implementación interna de la clase. Por lo tanto, ajustamos los campos con Propiedades (o métodos en el caso de Java) para darnos la posibilidad de cambiar la implementación sin romper el código dependiendo de nosotros. Ver como podemos poner lógica en la Propiedad también nos permite realizar lógica de validación, etc. si la necesitamos. C # 3 tiene la noción posiblemente confusa de autoproperties. Esto nos permite definir simplemente la Propiedad y el compilador C # 3 generará el campo privado para nosotros.
public class Person
{
private string _name;
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
public int Age{get;set;} //AutoProperty generates private field for us
}
Una diferencia importante es que las interfaces pueden tener propiedades pero no campos. Esto, para mí, subraya que las propiedades deben usarse para definir la interfaz pública de una clase, mientras que los campos deben usarse en el funcionamiento privado e interno de una clase. Como regla, rara vez creo campos públicos y, de manera similar, rara vez creo propiedades no públicas.
Te daré un par de ejemplos de uso de propiedades que pueden hacer que los engranajes giren:
- Inicialización diferida : si tiene una propiedad de un objeto es costoso cargarlo, pero no se accede tanto en las ejecuciones normales del código, puede retrasar su carga a través de la propiedad. De esa manera, solo está allí, pero la primera vez que otro módulo intenta llamar a esa propiedad, comprueba si el campo subyacente es nulo; si lo es, continúa y lo carga, desconocido para el módulo de llamada. Esto puede acelerar enormemente la inicialización de objetos.
- Rastreo sucio: del cual realmente aprendí de mi propia pregunta aquí en StackOverflow. Cuando tengo muchos objetos cuyos valores pueden haber cambiado durante una ejecución, puedo usar la propiedad para rastrear si es necesario volver a guardarlos en la base de datos. Si no ha cambiado una sola propiedad de un objeto, el indicador IsDirty no se activará y, por lo tanto, la funcionalidad de guardado lo omitirá al decidir qué necesita volver a la base de datos.
Usando Propiedades, puede lanzar un evento, cuando se cambia el valor de la propiedad (también conocido como PropertyChangedEvent) o antes de que el valor se cambie para admitir la cancelación.
Esto no es posible con (acceso directo a) campos.
public class Person {
private string _name;
public event EventHandler NameChanging;
public event EventHandler NameChanged;
public string Name{
get
{
return _name;
}
set
{
OnNameChanging();
_name = value;
OnNameChanged();
}
}
private void OnNameChanging(){
EventHandler localEvent = NameChanging;
if (localEvent != null) {
localEvent(this,EventArgs.Empty);
}
}
private void OnNameChanged(){
EventHandler localEvent = NameChanged;
if (localEvent != null) {
localEvent(this,EventArgs.Empty);
}
}
}
Ya que muchos de ellos han explicado con técnica pros y los contras de Properties y Field, es el momento de entrar en ejemplos en tiempo real.
1.Propiedades le permite configurar el acceso de sólo lectura a nivel de
Considere el caso de dataTable.Rows.Count y dataTable.Columns[i].Caption.Ellos provienen de la clase DataTable y ambos son públicos para nosotros.La diferencia en el nivel de acceso a ellos es que no podemos poner el valor a dataTable.Rows.Count pero podemos leer y escribir a dataTable.Columns[i].Caption.Es posible que a través de Field?No!!!Esto se puede hacer con Properties sólo.
public class DataTable
{
public class Rows
{
private string _count;
// This Count will be accessable to us but have used only "get" ie, readonly
public int Count
{
get
{
return _count;
}
}
}
public class Columns
{
private string _caption;
// Used both "get" and "set" ie, readable and writable
public string Caption
{
get
{
return _caption;
}
set
{
_caption = value;
}
}
}
}
2.Propiedades en PropertyGrid
Usted podría haber trabajado con Button en Visual Studio.Sus propiedades se muestran en la PropertyGrid como Text,Name etc.Cuando nos arrastrar y soltar un botón, y cuando hacemos clic en las propiedades, se encuentra automáticamente la clase Button y filtros Properties y muestran que en PropertyGrid (donde PropertyGrid no se mostrará Field aunque son públicas).
public class Button
{
private string _text;
private string _name;
private string _someProperty;
public string Text
{
get
{
return _text;
}
set
{
_text = value;
}
}
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
[Browsable(false)]
public string SomeProperty
{
get
{
return _someProperty;
}
set
{
_someProperty= value;
}
}
En PropertyGrid, las propiedades Name y Text se muestra, pero no SomeProperty.Por qué???Debido a que las Propiedades pueden aceptar Atributos.No show en caso de que [Browsable(false)] es falso.
3.Puede ejecutar instrucciones en el interior de Propiedades
public class Rows
{
private string _count;
public int Count
{
get
{
return CalculateNoOfRows();
}
}
public int CalculateNoOfRows()
{
// Calculation here and finally set the value to _count
return _count;
}
}
4.Sólo las Propiedades pueden ser utilizadas en el Enlace de la Fuente
Origen De Enlace nos ayuda a disminuir el número de líneas de código. Fields no son aceptados por BindingSource.Debemos utilizar Properties por eso.
5.El modo de depuración
Considerar que estamos utilizando Field para mantener un valor.En algún momento tenemos que depurar y comprobar si el valor es llegar nulo para ese campo.Va a ser difícil de hacer cuando el número de líneas de código son más de 1000.En estas situaciones podemos utilizar Property y se puede establecer el modo de depuración en el interior Property.
public string Name
{
// Can set debug mode inside get or set
get
{
return _name;
}
set
{
_name = value;
}
}
DIFERENCIAS - USOS (cuándo y por qué)
Un campo es una variable que se declara directamente en una clase o estructura. Una clase o estructura puede tener campos de instancia o campos estáticos o ambos. En general, debe usar los campos solo para las variables que tienen accesibilidad privada o protegida . Los datos que su clase expone al código de cliente se deben proporcionar a través de métodos, propiedades e indexadores. Al usar estas construcciones para el acceso indirecto a los campos internos, puede protegerse contra valores de entrada no válidos.
Una propiedad es un miembro que proporciona un mecanismo flexible para leer, escribir o calcular el valor de un campo privado. Las propiedades se pueden usar como si fueran miembros de datos públicos, pero en realidad son métodos especiales llamados accesores . Esto permite acceder fácilmente a los datos y aún ayuda a promover la seguridad y flexibilidad de los métodos . Las propiedades permiten que una clase exponga una forma pública de obtener y establecer valores, al tiempo que oculta el código de implementación o verificación. Se utiliza un descriptor de acceso de propiedad get para devolver el valor de la propiedad, y un descriptor de acceso set se utiliza para asignar un nuevo valor.
Las propiedades tienen la ventaja principal de permitirle cambiar la forma en que se accede a los datos de un objeto sin romper su interfaz pública. Por ejemplo, si necesita agregar una validación adicional o cambiar un campo almacenado en un cálculo, puede hacerlo fácilmente si inicialmente expuso el campo como una propiedad. Si acaba de exponer un campo directamente, entonces tendría que cambiar la interfaz pública de su clase para agregar la nueva funcionalidad. Ese cambio rompería los clientes existentes, lo que requeriría que se volvieran a compilar antes de que pudieran usar la nueva versión de su código.
Si escribe una biblioteca de clases diseñada para un amplio consumo (como .NET Framework, que utilizan millones de personas), eso puede ser un problema. Sin embargo, si está escribiendo una clase utilizada internamente dentro de una pequeña base de código (digamos & Lt; = 50 K líneas), realmente no es gran cosa, porque nadie se vería afectado negativamente por sus cambios. En ese caso, todo se reduce a preferencias personales.
Las propiedades admiten acceso asimétrico, es decir, puede tener un getter y un setter o solo uno de los dos. Del mismo modo, las propiedades admiten accesibilidad individual para getter / setter. Los campos son siempre simétricos, es decir, siempre puede obtener y establecer el valor. La excepción a esto son los campos de solo lectura que obviamente no se pueden configurar después de la inicialización.
Las propiedades pueden ejecutarse durante mucho tiempo, tener efectos secundarios e incluso pueden generar excepciones. Los campos son rápidos, sin efectos secundarios y nunca arrojarán excepciones. Debido a los efectos secundarios, una propiedad puede devolver un valor diferente para cada llamada (como puede ser el caso de DateTime.Now, es decir, DateTime.Now no siempre es igual a DateTime.Now). Los campos siempre devuelven el mismo valor.
Los campos se pueden usar para parámetros out / ref, las propiedades no. Las propiedades admiten lógica adicional & # 8211; esto podría usarse para implementar la carga diferida, entre otras cosas.
Las propiedades admiten un nivel de abstracción encapsulando lo que sea que signifique obtener / establecer el valor.
Use las propiedades en la mayoría de los casos, pero trate de evitar los efectos secundarios.
En el fondo de una propiedad se compila en los métodos.Así que un Name la propiedad está compilado en get_Name() y set_Name(string value).Usted puede ver esto si estudio el código compilado.Así que hay una (muy) pequeña sobrecarga en el rendimiento cuando se usan.Normalmente siempre uso una Propiedad si expone un campo para el exterior, y que a menudo se utiliza internamente si usted necesita para hacer la validación del valor.
Cuando desee que su variable privada (campo) sea accesible al objeto de su clase desde otras clases, debe crear propiedades para esas variables.
por ejemplo si tengo variables nombradas como " id " y " nombre " que es privado pero puede haber una situación en la que esta variable sea necesaria para la operación de lectura / escritura fuera de la clase. En esa situación, la propiedad puede ayudarme a obtener esa variable para leer / escribir dependiendo del get / set definido para la propiedad. Una propiedad puede ser de solo lectura / escritura / solo lectura.
aquí está la demostración
class Employee
{
// Private Fields for Employee
private int id;
private string name;
//Property for id variable/field
public int EmployeeId
{
get
{
return id;
}
set
{
id = value;
}
}
//Property for name variable/field
public string EmployeeName
{
get
{
return name;
}
set
{
name = value;
}
}
}
class MyMain
{
public static void Main(string [] args)
{
Employee aEmployee = new Employee();
aEmployee.EmployeeId = 101;
aEmployee.EmployeeName = "Sundaran S";
}
}
La segunda pregunta aquí, " ¿cuándo se debe usar un campo en lugar de una propiedad? " ;, solo se toca brevemente en esta otra respuesta y un poco esta también , pero no mucho detalle.
En general, todas las otras respuestas son acertadas sobre un buen diseño: prefiera exponer propiedades sobre exponer campos. Si bien es probable que no regularmente te encuentres diciendo & "; Wow, imagina cuánto peor serían las cosas si hubiera hecho de esto un campo en lugar de una propiedad &"; Es < fuerte> mucho más raro pensar en una situación en la que dirías " wow, gracias a Dios usé un campo aquí en lugar de una propiedad. "
Pero hay una ventaja que los campos tienen sobre las propiedades, y es su capacidad para usarse como " ref " / " fuera " parámetros Supongamos que tiene un método con la siguiente firma:
public void TransformPoint(ref double x, ref double y);
y suponga que desea utilizar ese método para transformar una matriz creada de esta manera:
System.Windows.Point[] points = new Point[1000000];
Initialize(points);
Aquí creo que es la forma más rápida de hacerlo, ya que X y Y son propiedades:
for (int i = 0; i < points.Length; i++)
{
double x = points[i].X;
double y = points[i].Y;
TransformPoint(ref x, ref y);
points[i].X = x;
points[i].Y = y;
}
¡Y eso va a ser bastante bueno! A menos que tenga medidas que demuestren lo contrario, no hay razón para echar un mal olor. Pero creo que técnicamente no está garantizado que sea tan rápido como esto:
internal struct MyPoint
{
internal double X;
internal double Y;
}
// ...
MyPoint[] points = new MyPoint[1000000];
Initialize(points);
// ...
for (int i = 0; i < points.Length; i++)
{
TransformPoint(ref points[i].X, ref points[i].Y);
}
Haciendo algunas mediciones , la versión con campos toma aproximadamente el 61% del tiempo como la versión con propiedades (.NET 4.6, Windows 7, x64, modo de lanzamiento, sin depurador adjunto). Cuanto más costoso sea el método TransformPoint, menos pronunciada será la diferencia. Para repetir esto usted mismo, ejecute con la primera línea comentada y no comentada.
Incluso si no hubo beneficios de rendimiento para lo anterior, hay otros lugares en los que poder usar los parámetros ref y out podría ser beneficioso, como cuando se llama a Interbloqueado o Familia de métodos volátiles . Nota: en caso de que esto sea nuevo para usted, Volatile es básicamente una forma de obtener el mismo comportamiento proporcionado por la palabra clave volatile. Como tal, como <=>, no resuelve mágicamente todos los problemas de seguridad de hilos como su nombre sugiere que podría.
Definitivamente no quiero parecer que estoy abogando por que vayas & "; oh, debería comenzar a exponer campos en lugar de propiedades. &"; El punto es que si necesita usar regularmente estos miembros en llamadas que toman & Quot; ref & Quot; o " fuera " parámetros, especialmente en algo que podría ser un tipo de valor simple que probablemente no necesite ninguno de los elementos de propiedades de valor agregado, se puede hacer un argumento.
Además, las propiedades le permiten usar la lógica al establecer valores.
Por lo tanto, puede decir que solo desea establecer un valor en un campo entero, si el valor es mayor que x, de lo contrario, arroje una excepción.
Característica realmente útil.
Si va a usar primitivas de subprocesos, está obligado a usar campos. Las propiedades pueden romper su código enhebrado. Aparte de eso, lo que dijo Cory es correcto.
(Esto realmente debería ser un comentario, pero no puedo publicar un comentario, así que disculpe si no es apropiado como una publicación).
Una vez trabajé en un lugar donde la práctica recomendada era usar campos públicos en lugar de propiedades cuando la def de propiedad equivalente simplemente hubiera estado accediendo a un campo, como en:
get { return _afield; }
set { _afield = value; }
Su razonamiento era que el campo público podría convertirse en una propiedad más adelante en el futuro si fuera necesario. Me pareció un poco extraño en ese momento. A juzgar por estas publicaciones, parece que no muchos estarían de acuerdo tampoco. ¿Qué podría haber dicho para intentar cambiar las cosas?
Editar: debo agregar que toda la base de código en este lugar se compiló al mismo tiempo, por lo que podrían haber pensado que cambiar la interfaz pública de clases (cambiando un campo público a una propiedad) no era un problema .
Técnicamente, no creo que haya una diferencia, porque las propiedades son solo envoltorios alrededor de los campos creados por el usuario o creados automáticamente por el compilador. El propósito de las propiedades es forzar la encapsulación y ofrecer un método ligero característica. Es una mala práctica declarar los campos como públicos, pero no tiene ningún problema.
Esta página en MSDN tiene una comparación y consejos sobre cuál usar cuando:
https://msdn.microsoft.com /en-us/library/9d65as2e(v=vs.90).aspx
Los campos son variables miembro ordinarias o instancias miembro de una clase. Las propiedades son una abstracción para obtener y establecer sus valores . Las propiedades también se denominan accesores porque ofrecen una forma de cambiar y recuperar un campo si expone un campo en la clase como privado. En general, debe declarar privadas sus variables miembro, luego declarar o definir propiedades para ellas.
class SomeClass
{
int numbera; //Field
//Property
public static int numbera { get; set;}
}
Las propiedades encapsulan campos, lo que le permite realizar un procesamiento adicional en el valor que se establecerá o recuperará. Por lo general, es excesivo usar propiedades si no va a realizar ningún procesamiento previo o posterior en el valor del campo.
IMO, las propiedades son solo " SetXXX () " " GetXXX () " pares de funciones / métodos / interfaces que usamos antes, pero son más concisos y elegantes.
Tradicionalmente, los campos privados se configuran mediante métodos getter y setter. En aras de menos código, puede usar propiedades para establecer campos en su lugar.
cuando tienes una clase que es " Car " ;. Las propiedades son color, forma ...
Donde como campos son variables definidas dentro del alcance de una clase.
De Wikipedia - Programación orientada a objetos :
La programación orientada a objetos (OOP) es un paradigma de programación basado en el concepto de " objetos " ;, que son estructuras de datos que contienen datos , en forma de campos , a menudo conocidos como atributos; y el código , en forma de procedimientos, a menudo conocidos como métodos . (énfasis agregado)
Las propiedades son en realidad parte del comportamiento de un objeto, pero están diseñadas para dar a los consumidores del objeto la ilusión / abstracción de trabajar con los datos del objeto.
Mi diseño de un campo es que un campo necesita ser modificado solo por su padre, de ahí la clase. Como resultado, la variable se vuelve privada, luego para poder dar el derecho de leer las clases / métodos fuera, paso por el sistema de propiedad solo con Get. ¡El campo es recuperado por la propiedad y solo lectura! Si desea modificarlo, debe pasar por métodos (por ejemplo, el constructor) y creo que gracias a esta forma de asegurarlo, tenemos un mejor control sobre nuestro código porque & "; Flange &" ;. Uno siempre podría poner todo en público, por lo que cada caso posible, la noción de variables / métodos / clases, etc., en mi opinión, es solo una ayuda para el desarrollo y el mantenimiento del código. Por ejemplo, si una persona reanuda un código con campos públicos, puede hacer cualquier cosa y, por lo tanto, cosas & Quot; illogical & Quot; en relación con el objetivo, la lógica de por qué se escribió el código. Es mi punto de vista.
Cuando uso un campo clásico modelo privado / propiedades públicas de solo lectura, ¡para 10 campos privados debería escribir 10 propiedades públicas! El código puede ser realmente grande más rápido. Descubro el setter privado y ahora solo uso propiedades públicas con un setter privado. El setter crea en segundo plano un campo privado.
Por eso mi antiguo estilo clásico de programación era:
public class MyClass
{
private int _id;
public int ID { get { return _id; } }
public MyClass(int id)
{
_id = id;
}
}
Mi nuevo estilo de programación:
public class MyClass
{
public int ID { get; private set; }
public MyClass(int id)
{
ID = id;
}
}
Los campos son las variables en las clases. Los campos son los datos que puede encapsular mediante el uso de modificadores de acceso.
Las propiedades son similares a los campos en que definen estados y los datos asociados con un objeto.
A diferencia de un campo, una propiedad tiene una sintaxis especial que controla cómo una persona lee los datos y los escribe, estos se conocen como operadores get y set. La lógica establecida a menudo se puede usar para validar.
Las propiedades son un tipo especial de miembro de la clase. En las propiedades usamos un método predefinido Set u Get. Usan accesores a través de los cuales podemos leer, escribir o cambiar los valores de los campos privados.
Por ejemplo, tomemos una clase llamada Employee, con campos privados para nombre, edad y Id. de empleado. No podemos acceder a estos campos desde fuera de la clase, pero podemos acceder a estos campos privados a través de propiedades.
¿Por qué usamos propiedades?
Hacer público el campo de clase & amp; exponerlo es arriesgado, ya que no tendrá control sobre lo que se le asigna & amp; devuelto.
Para entender esto claramente con un ejemplo, tomemos una clase de estudiante que tenga ID, contraseña, nombre. Ahora, en este ejemplo, algún problema con el campo público
- ID no debe ser -ve.
- El nombre no se puede establecer en nulo
- La marca de aprobación debe ser de solo lectura.
- Si falta el nombre del alumno, no debe devolverse ningún nombre.
Para eliminar este problema, utilizamos el método Get and set.
// A simple example
public class student
{
public int ID;
public int passmark;
public string name;
}
public class Program
{
public static void Main(string[] args)
{
student s1 = new student();
s1.ID = -101; // here ID can't be -ve
s1.Name = null ; // here Name can't be null
}
}
Ahora tomamos un ejemplo del método get y set
public class student
{
private int _ID;
private int _passmark;
private string_name ;
// for id property
public void SetID(int ID)
{
if(ID<=0)
{
throw new exception("student ID should be greater then 0");
}
this._ID = ID;
}
public int getID()
{
return_ID;
}
}
public class programme
{
public static void main()
{
student s1 = new student ();
s1.SetID(101);
}
// Like this we also can use for Name property
public void SetName(string Name)
{
if(string.IsNullOrEmpty(Name))
{
throw new exeception("name can not be null");
}
this._Name = Name;
}
public string GetName()
{
if( string.IsNullOrEmpty(This.Name))
{
return "No Name";
}
else
{
return this._name;
}
}
// Like this we also can use for Passmark property
public int Getpassmark()
{
return this._passmark;
}
}
Las propiedades se utilizan para exponer el campo. Utilizan accesores (set, get) a través de los cuales los valores de los campos privados se pueden leer, escribir o manipular.
Las propiedades no nombran las ubicaciones de almacenamiento. En cambio, tienen accesores que leen, escriben o calculan sus valores.
Usando propiedades podemos establecer la validación en el tipo de datos que se establece en un campo.
Por ejemplo, tenemos una edad de campo de entero privado en la que debemos permitir valores positivos ya que la edad no puede ser negativa.
Podemos hacer esto de dos maneras usando getter y setters y usando la propiedad.
Using Getter and Setter
// field
private int _age;
// setter
public void set(int age){
if (age <=0)
throw new Exception();
this._age = age;
}
// getter
public int get (){
return this._age;
}
Now using property we can do the same thing. In the value is a key word
private int _age;
public int Age{
get{
return this._age;
}
set{
if (value <= 0)
throw new Exception()
}
}
Propiedad implementada automáticamente si no tenemos lógica en obtener y establecer accesores podemos usar la propiedad implementada automáticamente.
Cuando usted compila propiedades de implementación automática crea un campo privado y anónimo al que solo se puede acceder a través de los accesos get y set.
public int Age{get;set;}
Propiedades abstractas Una clase abstracta puede tener una propiedad abstracta, que debe implementarse en la clase derivada
public abstract class Person
{
public abstract string Name
{
get;
set;
}
public abstract int Age
{
get;
set;
}
}
// overriden something like this
// Declare a Name property of type string:
public override string Name
{
get
{
return name;
}
set
{
name = value;
}
}
Podemos establecer una propiedad en privado En esto podemos configurar de forma privada la propiedad automática (establecida con en la clase)
public int MyProperty
{
get; private set;
}
Puede lograr lo mismo con este código. En esta propiedad, la función de configuración no está disponible, ya que tenemos que establecer el valor en el campo directamente.
private int myProperty;
public int MyProperty
{
get { return myProperty; }
}
Piénsalo: tienes una habitación y una puerta para entrar a esta habitación. Si desea comprobar cómo entra y asegurar su habitación, debe usar las propiedades, de lo contrario no serán ninguna puerta y todas entrarán fácilmente sin ninguna regulación
class Room {
public string sectionOne;
public string sectionTwo;
}
Room r = new Room();
r.sectionOne = "enter";
La gente está entrando en la sección Una muy fácilmente, no hubo ninguna comprobación
class Room
{
private string sectionOne;
private string sectionTwo;
public string SectionOne
{
get
{
return sectionOne;
}
set
{
sectionOne = Check(value);
}
}
}
Room r = new Room();
r.SectionOne = "enter";
Ahora has verificado a la persona y sabes si tiene algo malvado con ella
La gran mayoría de los casos será un nombre de propiedad al que acceda en lugar de un nombre de variable ( campo ). La razón de esto es que se considera una buena práctica en .NET y en C # en particularmente para proteger cada pieza de datos dentro de una clase, ya sea una variable de instancia o una variable estática (variable de clase) porque está asociada con una clase.
Proteja todas esas variables con las propiedades correspondientes que le permiten definir, establecer y obtener accesores y hacer cosas como la validación cuando se manipulan esos datos.
Pero en otros casos como Clase de matemáticas (espacio de nombres del sistema), hay un par de propiedades estáticas que se integran en la clase. una de ellas es la constante matemática PI
ej. Math.PI
y dado que PI es un dato bien definido, no necesitamos tener múltiples copias de PI, siempre será el mismo valor. Por lo tanto, las variables estáticas a veces se usan para compartir datos entre objetos de una clase, pero también se usan comúnmente para obtener información constante donde solo se necesita una copia de un dato.
La diferencia básica y general es:
Campos
- SIEMPRE da acceso a obtener y establecer
- NO PUEDE causar efectos secundarios (lanzar excepciones, llamar a métodos, cambiar campos excepto el que se obtiene / establece, etc.)
Propiedades
- NO SIEMPRE da acceso a obtener y establecer
- PUEDE causar efectos secundarios
