Qual é a diferença entre um campo e uma propriedade?
https://stackoverflow.com/questions/295104
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Em C #, o que torna um campo diferente de um imóvel, e quando deve um campo ser usado em vez de uma propriedade?
Solução
Propriedades expor campos. Campos devem (quase sempre) ser mantidas em sigilo a uma classe e acessados ??via get e definir propriedades. Propriedades fornecem um nível de abstração que permite alterar os campos apesar de não afetar o meio externo são acessados ??por meio das coisas que usam sua classe.
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;}
}
pontos @Kent que propriedades não são obrigados a campos de encapsular, eles poderiam fazer um cálculo em outros campos, ou servir para outras finalidades.
pontos @GSS fora, que você também pode fazer outra lógica, como validação, quando uma propriedade é acessado, uma outra característica útil.
Outras dicas
Objeto programação orientada dizer que, o funcionamento interno de uma classe deve ser escondido do mundo exterior. Se você expor um campo que você está em essência expondo a implementação interna da classe. Portanto nós envolvemos campos com Propriedades (ou métodos em caso de Java) para nos dar a capacidade de mudar a implementação sem quebrar o código dependendo de nós. Visto que pode colocar lógica na propriedade também nos permite executar a validação lógica etc se precisar. C # 3 tem a noção possivelmente confundindo de autoproperties. Isso nos permite simplesmente definir a propriedade eo C # 3 compilador irá gerar o campo privado para nós.
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
}
Uma diferença importante é que as interfaces podem ter propriedades, mas não campos. Isso, para mim, sublinha que as propriedades devem ser usadas para definir interface pública de uma classe, enquanto os campos são feitos para serem usados ??nos trabalhos privados, internos de uma classe. Como regra eu raramente criar campos públicos e da mesma forma eu raramente criar propriedades não-pública.
Vou te dar alguns exemplos do uso de propriedades que podem receber as engrenagens girando:
- Inicialização lenta : Se você tem uma propriedade de um objeto que é caro para carga, mas não é acessado tanto assim em corridas normais do código, você pode atrasar a sua carga através da propriedade. Dessa forma, ele está apenas sentado ali, mas a primeira vez outro módulo tenta chamar essa propriedade, ele verifica se o campo subjacente é nulo - se for, ele vai em frente e carrega-o, desconhecido para o módulo de chamada. Isso pode acelerar bastante a inicialização do objeto.
- Acompanhamento sujo: O que eu realmente aprendi sobre do meu própria pergunta aqui em StackOverflow. Quando eu tenho um monte de objetos que os valores podem ter mudado durante uma corrida, eu posso usar a propriedade para controlar se eles precisam ser salvos de volta para o banco de dados ou não. Se não uma única propriedade de um objeto mudou, a bandeira IsDirty não vai tropeçar, e, portanto, a funcionalidade de poupança irá ignorá-lo quando decidir o que precisa voltar para o banco de dados.
Usando propriedades, você pode jogar um evento, quando o valor da propriedade é alterado (aka. PropertyChangedEvent) ou antes que o valor é alterado para cancelamento apoio.
Isto não é possível com (acesso 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);
}
}
}
Uma vez que muitos deles têm explicado com os profissionais técnicos e contras de Properties e Field, é hora de entrar em exemplos em tempo real.
1. Properties permite definir o nível de acesso só de leitura
Considere o caso de dataTable.Rows.Count e dataTable.Columns[i].Caption. Eles vêm do DataTable classe e ambos são públicos para nós. A diferença no acesso de nível para eles é que não podemos definir o valor para dataTable.Rows.Count mas podemos ler e escrever para dataTable.Columns[i].Caption. Isso é possível através Field? Não!!! Isso pode ser feito com apenas Properties.
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. Propriedades em PropertyGrid
Você pode ter trabalhado com Button no Visual Studio. Suas propriedades são mostrados na PropertyGrid como Text, Name etc. Quando arrastar e soltar um botão, e quando clicamos as propriedades, ele irá localizar automaticamente o Button classe e filtros Properties e mostram que em PropertyGrid (onde PropertyGrid não mostrar Field mesmo que eles são públicos).
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;
}
}
Em PropertyGrid, as propriedades Name e Text será mostrado, mas não SomeProperty. Por quê??? Como as propriedades pode aceitar Atributos . Ele não mostra no caso em que [Browsable(false)] é falsa.
3. Pode executar instruções dentro de Propriedades
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. Somente propriedades podem ser utilizadas na ligação da fonte
Encadernação Fonte nos ajuda a diminuir o número de linhas de código. Fields não são aceitos por BindingSource. Devemos usar Properties para isso.
5. modo de depuração
Considere que estamos usando Field para conter um valor. Em algum momento precisamos depurar e verificar onde o valor está ficando nula para esse campo. Vai ser difícil de fazer, onde o número de linhas de código são mais do que 1000. Em tais situações, podemos usar Property e pode definir o modo de depuração dentro Property.
public string Name
{
// Can set debug mode inside get or set
get
{
return _name;
}
set
{
_name = value;
}
}
diferenças - USES (quando e porquê)
A é uma variável que é declarada diretamente em uma classe ou struct. Uma classe ou estrutura pode ter campos de instância ou campos estáticos ou ambos. Geralmente, você deve usar campos somente para variáveis ??que têm acessibilidade privada ou protegida . Dados que seus expõe classe para o código do cliente deve ser fornecida através de métodos, propriedades e indexadores. Ao utilizar essas construções para acesso indirecto aos campos internos, você pode se proteger contra os valores de entrada inválidos.
A propriedade é um membro que fornece um mecanismo flexível para ler, escrever ou calcular o valor de um campo privado. As propriedades podem ser usadas como se fossem membros de dados públicos, mas eles são realmente métodos especiais chamados acessores . Isso permite que os dados sejam acessados ??facilmente e ainda ajuda a promover o segurança e flexibilidade de métodos . Propriedades habilitar uma classe para expor uma forma pública de obter e definir valores, ao esconder implementação ou código de verificação. Uma propriedade get acessador é usado para retornar o valor da propriedade, e um acessor definido é usado para atribuir um novo valor.
Propriedades tem a principal vantagem de permitir que você alterar os dados de forma em um objeto é acessado sem quebrá-lo da interface pública. Por exemplo, se você precisa adicionar validação extra, ou para alterar um campo armazenado em um calculado pode fazê-lo facilmente se você inicialmente expostos no campo como uma propriedade. Se você acabou de expor um campo diretamente, então você teria que alterar a interface pública de sua classe para adicionar a nova funcionalidade. Que a mudança iria quebrar clientes existentes, obrigando-os a ser recompilados antes que eles pudessem usar a nova versão do seu código.
Se você escrever uma biblioteca de classe projetado para o consumo de largura (como o .NET Framework, que é usado por milhões de pessoas), que pode ser um problema. No entanto, se você estiver escrevendo uma classe usado internamente dentro de uma pequena base de código (digamos <= 50 K linhas), não é realmente um grande negócio, porque ninguém seria afetada negativamente por suas mudanças. Nesse caso, ele realmente se resume a preferência pessoal.
Propriedades apoiar o acesso assimétrico, ou seja, você pode ter um getter e um setter ou apenas um dos dois. Propriedades semelhante apoio à acessibilidade individual para getter / setter. Os campos são sempre simétrica, ou seja, você sempre pode obter e definir o valor. Exceção a isso é readonly campos que obviamente não podem ser definidas após a inicialização.
Propriedades pode ser executado por um tempo muito longo, tem efeitos colaterais, e pode até lançar exceções. Os campos são rápidos, sem efeitos colaterais, e nunca vai lançar exceções. Devido a efeitos colaterais uma propriedade pode devolver um valor diferente para cada chamada (como pode ser o caso para DateTime.Now, isto é DateTime.Now não é sempre igual a DateTime.Now). Campos sempre retornar o mesmo valor.
Os campos podem ser usados ??para out / ref parâmetros, as propriedades não podem. Propriedades apoiar lógica adicional - isso pode ser usado para implementar o carregamento lento entre outras coisas
.Propriedades suportar um nível de abstração por encapsular tudo o que significa para obter / definir o valor.
Usar propriedades na maioria / todos os casos, mas tente evitar efeitos colaterais.
No fundo uma propriedade é compilado em métodos. Assim, uma propriedade Name é compilado em get_Name() e set_Name(string value). Você pode ver isso se você estudar o código compilado.
Portanto, há uma (muito) pequena sobrecarga desempenho quando usá-los. Normalmente você vai sempre usar uma propriedade se você expor um campo para o exterior, e muitas vezes você vai usá-lo internamente, se você precisa fazer a validação do valor.
Quando você quiser que sua variável privada (campo) para ser acessível a objeto de sua classe de outras classes que você precisa para criar propriedades para essas variáveis.
Por exemplo, se eu tiver variáveis ??nomeadas como "id" e "name" que é privado mas pode haver situações em que esta variável necessária para leitura / gravação operação fora da classe. Nessa situação, a propriedade pode me ajudar a conseguir essa variável para leitura / gravação dependendo do get / set definido para a propriedade. A propriedade pode ser um readonly / writeonly / READWRITE ambos.
aqui é a demonstração
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";
}
}
A segunda questão aqui "quando deve um campo ser usado em vez de uma propriedade?", Só é brevemente sobre a este outro responder e meio este também , mas não é realmente muito detalhe.
Em geral, todas as outras respostas são spot-on sobre um bom design: Prefere propriedades sobre os campos expondo expondo. Enquanto você provavelmente não vai regularmente encontrar-se dizer "uau, imaginar o quanto as coisas piores seria se eu tivesse feito isso um campo em vez de uma propriedade", é muito mais raro pensar em uma situação onde você diria "wow, graças a Deus eu usei um campo aqui em vez de uma propriedade."
Mas há uma vantagem que os campos têm mais propriedades, e isso é a sua capacidade de ser usado como "ref" / "out" parâmetros. Suponha que você tenha um método com a seguinte assinatura:
public void TransformPoint(ref double x, ref double y);
e supor que você quer usar esse método para transformar um array criado assim:
System.Windows.Point[] points = new Point[1000000];
Initialize(points);
Aqui está Eu acho que a maneira mais rápida de fazê-lo, uma vez que X e Y são propriedades:
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;
}
E isso vai ser muito bom! A menos que você tem medições que provam o contrário, não há nenhuma razão para lançar um fedor. Mas eu acredito que não é tecnicamente garantido para ser tão rápido como este:
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);
}
Fazendo algumas medições mim mesmo, a versão com campos leva cerca de 61% do tempo como a versão com propriedades (.NET 4.6, Windows 7, x64 modo de libertação, sem depurador anexado). Quanto mais caro o método TransformPoint fica, menos pronunciada que a diferença se torna. Para repetir esse mesmo, correr com a primeira linha comentada e com ele não comentou-out.
Mesmo se não houvesse benefícios de desempenho para o acima, existem outros lugares onde ser capaz de usar ref e parâmetros de saída pode ser benéfico, como ao chamar o Interlocked ou família Volatile de métodos. Nota: No caso de isso é novo para você, Volatile é basicamente uma maneira de obter ao mesmo comportamento fornecido pela palavra-chave volatile. Como tal, como volatile, não resolve magicamente todos os problemas thread-segurança, como o próprio nome sugere que ele pode.
Eu definitivamente não quero parecer que estou defendendo que você vai "oh, eu deveria começar a expor campos em vez de propriedades." O ponto é que, se você precisa usar regularmente estes membros em chamadas que levam "ref" ou "out" parâmetros, especialmente em algo que pode ser um tipo de valor simples que é improvável que alguma vez precisar de qualquer dos elementos de valor agregado de propriedades, um argumento pode ser feito.
Além disso, as propriedades permitem que você use lógica ao definir valores.
Então você pode dizer que você só quer definir um valor para um campo inteiro, se o valor for maior do que x, caso contrário, lançar uma exceção.
recurso muito útil.
Se você estiver indo para usar primitivas de rosca você é forçado a campos de uso. As propriedades podem quebrar seu código de rosca. Para além de que, o que Cory disse está correto.
(Isso deve ser realmente um comentário, mas eu não posso postar um comentário, por isso, desculpa se não é apropriado como um post).
Uma vez eu trabalhei em um lugar onde a prática recomendada era usar campos públicos em vez de propriedades quando a propriedade equivalente def seria apenas foram acessando um campo, como em:
get { return _afield; }
set { _afield = value; }
Seu raciocínio era que o campo público pode ser convertida em uma propriedade mais tarde no futuro, se necessário. Parecia um pouco estranho para mim no momento. A julgar por essas mensagens, parece que não muitos aqui concordam também. O que você poderia ter dito para tentar mudar as coisas?
Edit: Devo acrescentar que toda a base de código neste lugar foi compilado, ao mesmo tempo, para que eles possam ter pensado que alterar a interface pública de aulas (alterando um campo público para uma propriedade) não foi um problema .
Tecnicamente, eu não acho que há uma diferença, porque as propriedades são wrappers apenas cerca de campos criados pelo usuário ou automaticamente criados pelo propósito compiler.The de propriedades é impor encapsuation e oferecer um método semelhante leve característica. É apenas uma má prática para campos declarar pública, mas não têm quaisquer problemas.
Esta página no MSDN tem uma comparação e dicas sobre qual usar quando:
https://msdn.microsoft.com /en-us/library/9d65as2e(v=vs.90).aspx
Os campos são variáveis ??de membro ordinário ou instâncias membro de uma classe. As propriedades são um abstração para obter e definir seus valores . Propriedades também são chamados de assessores, porque eles oferecem uma maneira de mudar e recuperar um campo se você expor um campo na classe como privado. Geralmente, você deve declarar suas variáveis ??membro privado, em seguida, declarar ou definir propriedades para eles.
class SomeClass
{
int numbera; //Field
//Property
public static int numbera { get; set;}
}
Propriedades encapsular campos, permitindo-lhe realizar processamento adicional sobre o valor a ser definido ou recuperado. É tipicamente um exagero para propriedades de uso, se você não vai fazer qualquer pré ou pós-processamento no valor do campo.
IMO, as propriedades são apenas a "setXXX ()" "getXXX ()" funções / métodos / interfaces pares que usamos antes, mas eles são mais concisa e elegante.
campos Tradicionalmente privadas são definidas através de métodos get e set. Por uma questão de menos código você pode usar propriedades para definir campos em vez.
quando você tem uma classe que é "Carro". As propriedades são cor, forma ..
Onde como campos são variáveis ??definidas no âmbito de uma classe.
De Wikipedia - orientada a objetos de programação :
de programação orientada para o objecto (OOP) é ??um paradigma de programação com base no conceito de "objectos", que são estruturas de dados que contêm dados <> forte, sob a forma de campos , muitas vezes conhecida como atributos; e
código, sob a forma de procedimentos, muitas vezes conhecida como métodos . (ênfase adicionada)
As propriedades são realmente parte do comportamento de um objeto, mas são projetados para dar aos consumidores do objeto a ilusão / abstração de trabalhar com os dados do objeto.
Meu projeto de um campo é que um campo precisa ser modificado apenas por seu pai, daí a classe. Resultado da variável torna-se privado, em seguida, ser capaz de dar o direito de ler as classes / métodos fora eu ir através do sistema de propriedade com apenas a Get. O campo é então recuperada pela propriedade e somente leitura! Se você quiser modificá-lo você tem que ir através de métodos (por exemplo, o construtor) e acho que, graças a esta forma de fazer você segura, temos um melhor controle sobre o nosso código porque nós "flange". Pode-se muito bem sempre colocar tudo em público, para todos os casos possíveis, a noção de variáveis ??/ métodos / classes etc ... na minha opinião é apenas uma ajuda para o desenvolvimento, a manutenção do código. Por exemplo, se uma pessoa retoma um código com campos públicos, ele pode fazer qualquer coisa e, portanto, as coisas "ilógico" em relação ao objectivo, a lógica de por que o código foi escrito. É o meu ponto de vista.
Quando eu uso um modelo clássico campo privado / propriedades somente leitura pública, por 10 campos privates i deve escrever propriedades 10 publics! O código pode ser realmente grande mais rápido. I descobrir o setter privado e agora eu só uso as propriedades públicas com um setter privado. O setter criar no fundo um campo particular.
Isso por que o meu estilo de programação velho clássico foi:
public class MyClass
{
private int _id;
public int ID { get { return _id; } }
public MyClass(int id)
{
_id = id;
}
}
O meu estilo de programação nova:
public class MyClass
{
public int ID { get; private set; }
public MyClass(int id)
{
ID = id;
}
}
Os campos são as variáveis ??em classes. Os campos são os dados que você pode encapsular através do uso de modificadores de acesso.
As propriedades são semelhantes aos campos em que eles definir estados e os dados associados a um objeto.
Ao contrário de um campo de uma propriedade tem uma sintaxe especial que controla como uma pessoa lê os dados e grava os dados, estes são conhecidos como o get e operadores de conjunto. A lógica set muitas vezes pode ser usado para fazer a validação.
As propriedades são tipo especial de membro de classe, em propriedades que usar um conjunto pré-definido ou obter method.They uso acessores através do qual podemos ler, escrito ou alterar os valores dos campos particulares.
Por exemplo, vamos dar uma classe chamada Employee, com campos particulares para o nome, idade e employee_id. Não podemos aceder a estes campos de fora da classe, mas podemos aceder a estes campos privados através de propriedades.
Por que usamos propriedades?
Fazendo o público campo de classe e expor é arriscado, pois você não terá que controlar o que é atribuído & retornado.
Para entender isso claramente com um exemplo vamos dar uma classe estudante que tem ID, passmark, nome. Agora, neste exemplo, algum problema com o campo público
- ID não deve ser-ve.
- Nome não pode ser definido como nulo
- marca de passagem deve ser somente leitura.
- Se o nome do estudante está faltando No Name deve ser do retorno.
Para remover este problema Usamos Get e método 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
}
}
Agora, vamos dar um exemplo de get e set método
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;
}
}
As propriedades são usadas para expor campo. Eles usam acessores (conjunto, get), através do qual os valores dos campos privados podem ser lidos, escritos ou manipulados.
Propriedades não nomear os locais de armazenamento. Em vez disso, eles têm assessores que ler, escrever ou calcular os seus valores.
Usando propriedades que pode definir a validação do tipo de dados que são definidos em um campo.
Por exemplo, temos idade privado campo inteiro em que devemos permitir valores positivos desde a idade não pode ser negativo.
Nós podemos fazer isso de duas maneiras usando getter e setters e usando propriedade.
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()
}
}
Auto Implementado propriedade se não o fizermos lógica em obter e definir acessores podemos usar auto propriedade implementadas.
Quando u SE compila propriedade implementado automaticamente cria um campo privado, anônimo que só pode ser acessado por meio de obter e definir acessores.
public int Age{get;set;}
Propriedades abstratas Uma classe abstrata pode ter uma propriedade abstrata, que deve ser implementado na classe 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 definir uma propriedade privada Neste podemos definir privada a propriedade auto (conjunto com na classe)
public int MyProperty
{
get; private set;
}
Você pode conseguir mesmo com este código. Neste recurso propriedade conjunto não está disponível como temos de valor definido para o campo diretamente.
private int myProperty;
public int MyProperty
{
get { return myProperty; }
}
Pense nisso: Você tem uma sala e uma porta para entrar nesta sala. Se você quiser verificar como quem está entrando e garantir seu quarto, então você deve usar as propriedades de outra forma não haverá qualquer porta e cada um facilmente entrar em w / o qualquer regulamentação
class Room {
public string sectionOne;
public string sectionTwo;
}
Room r = new Room();
r.sectionOne = "enter";
As pessoas está ficando para sectionOne muito facilmente, não houve qualquer verificação
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";
Agora você verificou a pessoa e saber sobre se ele tem algo mal com ele
A grande maioria dos casos ele vai ser um nome de propriedade que você acessar ao contrário de um nome de variável ( ) A razão para isso é que é considerada uma boa prática em .NET e C # no especial para proteger cada pedaço de dados dentro de uma classe, se é uma variável de instância ou uma variável estática (variável de classe) porque está associado a uma classe.
Proteger todas essas variáveis ??com propriedades que permitem definir, set correspondente e obter acessores e fazer coisas como validação quando você está manipulando aqueles pedaços de dados.
Mas em outros casos, como Math classe (namespace System), há um par de propriedades estáticas que são construídos para a classe. uma das quais é a constante matemática PI
por exemplo. Math.PI
e porque PI é um pedaço de dados que são bem definidas, não precisa ter várias cópias do PI, ele sempre vai ser o mesmo valor. variáveis ??tão estáticas são por vezes usados ??para compartilhar dados entre objeto de uma classe, mas o também são comumente usados ??para obter informações constante onde você só precisa de uma cópia de uma parte dos dados.
Basic ea diferença geral é:
Os campos
- Sempre dar tanto get e set access
- não pode causar efeitos colaterais (lançar exceções, chamando métodos, mudando campos exceto o ser tem / set, etc)
Propriedades
- NÃO SEMPRE dar tanto get e set access
- CAN causar efeitos colaterais
