Propriedades automáticas do C# 3.0 – úteis ou não?[fechado]

Question

Observação:Isso foi postado quando eu estava começando em C#.Com o conhecimento de 2014, posso realmente dizer que as propriedades automáticas estão entre as melhores coisas que já aconteceram com a linguagem C#.

Estou acostumado a criar minhas propriedades em C# usando um campo privado e um campo público:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Agora com .LÍQUIDO 3.0, obtivemos propriedades automáticas:

public string Title { get; set; }

Eu sei que esta é uma questão mais filosófica/subjetiva, mas há algum motivo para usar essas propriedades automáticas, exceto salvar cinco linhas de código para cada campo?Minha reclamação pessoal é que essas propriedades estão escondendo coisas de mim, e não sou um grande fã de magia negra.

Na verdade, o campo privado oculto nem aparece no depurador, o que é bom, dado o fato de que as funções get/set não fazem nada.Mas quando eu quero realmente implementar alguma lógica getter/setter, tenho que usar o par privado/público de qualquer maneira.

Vejo o benefício de salvar muito código (uma contra seis linhas) sem perder a capacidade de alterar a lógica getter/setter posteriormente, mas já posso fazer isso simplesmente declarando um campo público "Título da string pública" sem a necessidade de {get;definir;} bloco, economizando ainda mais código.

Então, o que estou perdendo aqui?Por que alguém iria realmente querer usar propriedades automáticas?

Answer 1

Nós os usamos o tempo todo no Stack Overflow.

Você também pode estar interessado em uma discussão sobre Propriedades vs.Variáveis ​​Públicas.IMHO é realmente a isso que isso é uma reação e, para esse propósito, é ótimo.

Answer 2

Sim apenas salve o código.É muito mais fácil de ler quando você tem muitos deles.Eles são mais rápidos de escrever e mais fáceis de manter.Salvar código é sempre um bom objetivo.

Você pode definir escopos diferentes:

public string PropertyName { get; private set; }

Para que a propriedade só possa ser alterada dentro da classe.Isso não é realmente imutável, pois você ainda pode acessar o setter privado por meio de reflexão.

A partir do C#6 você também pode criar verdadeiros readonly propriedades - ou seja,propriedades imutáveis ​​que não podem ser alteradas fora do construtor:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Em tempo de compilação, isso se tornará:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

Em classes imutáveis ​​com muitos membros, isso economiza muito código em excesso.

Answer 3

As três grandes desvantagens de usar campos em vez de propriedades são:

1. Você não pode vincular dados a um campo, mas sim a uma propriedade
2. Se você começar a usar um campo, não poderá mais tarde (facilmente) alterá-los para uma propriedade
3. Existem alguns atributos que você pode adicionar a uma propriedade que não podem ser adicionados a um campo

Answer 4

Eu pessoalmente adoro propriedades automotivas.O que há de errado em salvar as linhas de código?Se você quiser fazer coisas em getters ou setters, não há problema em convertê-los em propriedades normais posteriormente.

Como você disse, você poderia usar campos e, se quisesse adicionar lógica a eles posteriormente, convertê-los-ia em propriedades.Mas isto pode apresentar problemas com qualquer uso de reflexão (e possivelmente em outro lugar?).

Além disso, as propriedades permitem definir diferentes níveis de acesso para o getter e o setter, o que não é possível fazer com um campo.

Acho que é o mesmo que a palavra-chave var.Uma questão de preferência pessoal.

Answer 5

De Bjarne Stroustrup, criador do C++:

Eu particularmente não gosto de classes com muitas funções get e set.Isso geralmente é uma indicação de que, em primeiro lugar, não deveria ter sido uma aula.É apenas uma estrutura de dados.E se for realmente uma estrutura de dados, torne-a uma estrutura de dados.

E sabe de uma coisa?Ele tem razão.Com que frequência você simplesmente agrupa campos privados em um get e set, sem realmente fazer nada dentro do get/set, simplesmente porque é a coisa "orientada a objetos" a ser feita.Esta é a solução da Microsoft para o problema;eles são basicamente campos públicos aos quais você pode vincular.

Answer 6

Uma coisa que ninguém parece ter mencionado é como as propriedades automáticas, infelizmente, não são úteis para objetos imutáveis ​​(geralmente estruturas imutáveis).Porque para isso você realmente deveria fazer:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(onde o campo é inicializado no construtor por meio de um parâmetro passado e depois é somente leitura.)

Então isso tem vantagens sobre um simples get/private set propriedade automática.

Answer 7

Eu sempre crio propriedades em vez de campos públicos porque você pode usar propriedades em uma definição de interface, mas não pode usar campos públicos em uma definição de interface.

Answer 8

As propriedades automáticas são uma magia negra tanto quanto qualquer outra coisa em C#.Uma vez que você pensa sobre isso em termos de compilação para IL, em vez de ser expandido para uma propriedade C # normal, primeiro é muito menos magia negra do que muitas outras construções de linguagem.

Answer 9

Eu uso propriedades automáticas o tempo todo.Antes do C#3 eu não me incomodava com toda a digitação e apenas usava variáveis ​​públicas.

A única coisa que sinto falta é poder fazer isso:

public string Name = "DefaultName";

Você precisa mudar os padrões para seus construtores com propriedades.tedioso :-(

Answer 10

Acho que qualquer construção intuitiva E que reduza as linhas de código é uma grande vantagem.

Esses tipos de recursos são o que torna linguagens como Ruby tão poderosas (isso e recursos dinâmicos, que também ajudam a reduzir o excesso de código).

Ruby sempre teve isso como:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 11

O único problema que tenho com eles é que não vão longe o suficiente.A mesma versão do compilador que adicionou propriedades automáticas, adicionou métodos parciais.Por que eles não juntaram os dois está além da minha compreensão.Um simples "On<PropertyName>Changed parcial" teria tornado essas coisas realmente úteis.

Answer 12

É simples, é curto e se você quiser criar uma implementação real dentro do corpo da propriedade em algum momento, isso não quebrará a interface externa do seu tipo.

Tão simples como isso.

Answer 13

Uma coisa a notar aqui é que, no meu entender, isso é apenas açúcar sintático no final do C # 3.0, o que significa que o IL gerado pelo compilador é o mesmo.Concordo em evitar a magia negra, mas mesmo assim, menos linhas para a mesma coisa costuma ser uma coisa boa.

Answer 14

Na minha opinião, você deve sempre usar propriedades automáticas em vez de campos públicos.Dito isto, aqui está um compromisso:

Comece com um interno campo usando a convenção de nomenclatura que você usaria para uma propriedade.Quando você primeiro

• precisar de acesso ao campo de fora de sua montagem, ou
• precisa anexar lógica a um getter/setter

Fazem isto:

1. renomeie o campo
2. torná-lo privado
3. adicionar uma propriedade pública

Seu código de cliente não precisará ser alterado.

Algum dia, porém, seu sistema crescerá e você o decomporá em montagens separadas e em múltiplas soluções.Quando isso acontecer, todos os campos expostos voltarão para assombrá-lo porque, como Jeff mencionou, mudar um campo público para uma propriedade pública é uma mudança significativa na API.

Answer 15

Eu uso o CodeRush, é mais rápido que as propriedades automáticas.

Para fazer isso:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Requer oito pressionamentos de tecla no total.

Answer 16

Bem, com trechos de código, uma propriedade automática com o mesmo nome teria sete pressionamentos de tecla no total;)

Answer 17

@Domenic:Eu não entendo..você não pode fazer isso com propriedades automáticas?:

public string Title { get; }

ou

public string Title { get; private set; }

É isso que você está se referindo?

Answer 18

Minha maior reclamação com as propriedades automáticas é que elas são projetadas para economizar tempo, mas muitas vezes descubro que preciso expandi-las para propriedades completas posteriormente.

O que falta no VS2008 é um Explodir propriedade automática refatorar.

O fato de termos um encapsular campo refatorar torna meu trabalho mais rápido, usando apenas campos públicos.