Campos públicos versus propriedades automáticas

Muitas vezes nos dizem que devemos proteger o encapsulamento, criando métodos getter e setter (propriedades em C #) para campos de classe, em vez de expor os campos para o mundo exterior.

Mas há muitas vezes em que um campo está presente apenas para armazenar um valor e não requer nenhum cálculo para obter ou definir. Para estes, todos faríamos este número:

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}

Bem, eu tenho uma confissão, eu não aguentava escrever tudo isso (realmente, não era preciso escrever, era preciso olhar para isso), então fui desonesto e usei campos públicos.

Então vem o C # 3.0 e vejo que eles adicionaram propriedades automáticas:

public class Book
{
    public string Title {get; set;} 
}

o que é mais arrumado, e sou grato por isso, mas realmente, o que há de tão diferente do que apenas criar um campo público?

public class Book
{
    public string Title;
}

Em uma pergunta relacionada que tive há algum tempo, havia um link para uma postagem no blog de Jeff, explicando algumas diferenças.

Propriedades vs. Variáveis ​​Públicas

• A reflexão funciona de maneira diferente entre variáveis ​​e propriedades; portanto, se você confiar na reflexão, é mais fácil usar todas as propriedades.
• Você não pode conectar-se a uma variável.

• Alterar uma variável para uma propriedade é uma mudança de quebra. Por exemplo:

  TryGetTitle(out book.Title); // requires a variable

Ignorando os problemas da API, o que eu acho mais valioso sobre o uso de uma propriedade é a depuração.

O depurador CLR não suporta pontos de interrupção de dados (a maioria dos depuradores nativos suporta). Portanto, não é possível definir um ponto de interrupção na leitura ou gravação de um campo específico de uma classe. Isso é muito limitante em certos cenários de depuração.

Como as propriedades são implementadas como métodos muito finos, é possível definir pontos de interrupção na leitura e gravação de seus valores. Isso lhes dá uma grande vantagem sobre os campos.

Mudar de um campo para uma propriedade quebra o contrato (por exemplo, exige que todo o código de referência seja recompilado). Portanto, quando você tem um ponto de interação com outras classes - qualquer membro público (e geralmente protegido), deseja planejar um crescimento futuro. Faça isso sempre usando propriedades.

Hoje, não é nada para torná-lo uma propriedade automática, e 3 meses depois da linha você percebe que deseja torná-lo lento e coloca uma verificação nula no getter. Se você usou um campo, esta é uma mudança de recompilação na melhor das hipóteses e impossível na pior das hipóteses, dependendo de quem e o que mais depende de suas montagens.

Só porque ninguém mencionou: você não pode definir campos nas interfaces. Portanto, se você precisar implementar uma interface específica que defina propriedades, as propriedades automáticas às vezes são um recurso muito bom.

Uma enorme diferença que geralmente é ignorada e não é mencionada em nenhuma outra resposta: a substituição . Você pode declarar propriedades virtuais e substituí-las, enquanto não pode fazer o mesmo para os campos públicos de membros.

É tudo sobre versionamento e estabilidade da API. Não há diferença na versão 1 - mas mais tarde, se você decidir tornar essa propriedade uma propriedade com algum tipo de verificação de erro na versão 2, não precisará alterar sua API - nenhuma alteração de código, em qualquer lugar, exceto a definição da propriedade.

Outra vantagem das propriedades implementadas automaticamente sobre os campos públicos é que você pode tornar os acessadores definidos privados ou protegidos, fornecendo à classe de objetos onde foi definido um controle melhor do que a dos campos públicos.

Não há nada errado em criar um campo public. Mas lembre-se de criar getter/settercom privatecampos não é encapsulamento. IMO: Se você não se importa com outros recursos de a Property, é melhor fazê-lo public.

Se você decidir posteriormente verificar se o título é exclusivo, comparando-se com uma coleção ou um banco de dados, poderá fazer isso na propriedade sem alterar nenhum código que dependa disso.

Se você optar por apenas um atributo público, terá menos flexibilidade.

A flexibilidade extra sem quebrar o contrato é o mais importante para mim sobre o uso de propriedades e, até que eu realmente precise da flexibilidade, a geração automática faz mais sentido.

Uma coisa que acho muito útil, além de todos os motivos de código e teste, é que, se for uma propriedade versus um campo, o IDE do Visual Studio mostra as referências para uma propriedade, mas não para um campo.

Meu pov depois fiz algumas pesquisas

1. Validação.
2. Permite substituir o acessador para alterar o comportamento de uma propriedade.
3. Objetivo de depuração. Poderemos saber quando e o que a propriedade muda, definindo um ponto de interrupção no acessador.
4. Podemos ter um campo somente conjunto. Por exemplo, set público () e get privado (). Isso não é possível com o campo público.

Realmente nos dá mais possibilidade e extensibilidade.