O que é chamado quando você define propriedades na inicialização do objeto?

4

Como é chamado quando você define propriedades na inicialização de objetos?

var customer = new Customer() {RequestID = request.ID, AddressID = 5};

Considera-se boa prática?

    
por Tom Squires 28.09.2011 / 18:21
fonte

8 respostas

12

É chamado inicializador de objetos ou expressões de inicialização de objeto, em pelo menos em C #. Sua implementação foi necessária para o LinQ, para criar dinamicamente tipos anônimos de uma maneira conveniente.

Se é uma boa prática ou não depende de como você a usa. Leia as reflexões sobre de Jon Skeet no stackoverflow para obter mais informações. Jimmy Hoffa também escreveu uma excelente resposta em codereview . Ele propõe basear a decisão a favor ou contra os inicializadores de objetos na questão:

O objeto é seguramente utilizável se as propriedades forem nulas?

Em caso afirmativo, os inicializadores de objeto fornecem uma maneira muito conveniente e legível de criar um objeto.

    
por 28.09.2011 / 18:24
fonte
10

Para adicionar um pouco à boa resposta de Falcon:

What is the name for setting properties when an object is instantiated?

É um "inicializador de objeto". Observe que o recurso equivalente para coleções é chamado de "inicializador de coleção". Ou seja, você também pode dizer

x = new List<int>() { 10, 30, 20 };

e isso será traduzido em

var temp = new List<int>();
temp.Add(10);
temp.Add(30);
temp.Add(20);
x = temp;

para você. Você pode até mesmo misturar inicializadores de objetos e coleções! Veja a seção de especificação C # 7.6.10.3 para um exemplo de como usar um inicializador de coleção dentro de um inicializador de objeto.

Is it considered good practice?

Não o adicionamos ao C # 3.0 porque era uma prática ruim!

O benefício atraente dos inicializadores de objeto e coleção não é apenas que eles são uma forma muito mais compacta, menos "cerimonial" de criar e inicializar um objeto. O benefício atraente é também que um inicializador de objeto é uma expressão, não uma coleção de instruções . Isso significa que você pode usá-los em contextos onde as expressões são legais, mas as declarações não são, como:

  • inicializadores de campo e locais
  • inicializadores de matriz
  • expressão lambdas
  • Compreensões de consulta LINQ
  • e assim por diante
por 29.09.2011 / 18:31
fonte
4

Sim, é uma boa prática. É mais legível porque você não tem a repetição de customer. e = . Pode parecer um ponto menor, mas é preciso tempo e energia para escanear essas linhas e verificar se, de fato, elas estão inicializando customer .

E considere isto:

var customer1 Customer();
customer1.RequestId = request.id1;
customer1.AddressId = 3;
customer1.Name = 'Nick Nicely'

var customer2 = new Customer();
customer2.RequestId = request.id2;
customer2.AddressId = 5;
customer1.Name = 'Poor Nick!'

O código repetitivo é propenso a erros de recortar e colar. É muito melhor expressar um pensamento simples (criar um novo cliente) em uma única frase (linha de código) sempre que possível.

    
por 28.09.2011 / 18:44
fonte
2

Is it considered good practice?

Eu sugeriria que não é uma prática "ruim", sendo que é principalmente apenas um recurso de conveniência. Não há diferença entre

var customer = new Customer() {RequestID=request.ID, AddressID = 5 };

ou

var customer = new Customer();
customer.RequestId = request.ID;
customer.AddressID = 5;

Além da cerimônia.

    
por 28.09.2011 / 18:31
fonte
2

É um pouco de açúcar sintático e não é realmente uma prática "boa" ou "ruim", mas é uma questão de estilo. A abordagem que você deve sempre seguir é o que melhorou a legibilidade.

Geralmente eu usarei este formulário sempre que as atribuições forem diretas, sempre que uma atribuição se tornar mais do que dar um valor ou possivelmente um valor e um ajuste rápido () eu retirarei e atribuirei ao objeto explicitamente.

Eu também acho que é útil quando eu tenho que fazer um número maior de tarefas e fazer como:

var customer = new Customer(){
    RequestID = request.ID,
    AddressID = 5,
    Firstname = "Bob",
    Lastname = "Jones",
    FavouriteColor = "Blue",
    someOtherProperty = "Maybe"
}

Acho que os parênteses de indentação e codeblock apenas ajudam a tornar mais explícito e mais fácil passar o seu código.

    
por 28.09.2011 / 19:01
fonte
1

Uma vantagem desses inicializadores que ninguém mencionou é que eles evitam erros bobos:

FileTransfer transfer = new FileTransfer();
transfer.ID = request.ID;
transfer.SourcePath = request.DownloadLink;
transfer.FileName = FileNameFromLink(request.DownloadLink);
transfer.SourcePath = request.Destination;

Isso irá compilar e ter bugs.

FileTransfer transfer = new FileTransfer
{
    ID = request.ID,
    SourcePath = request.DownloadLink,
    FileName = FileNameFromLink(request.DownloadLink),
    SourcePath = request.Destination
};

Agora, isso não será , e isso ajudará você a identificar que SourcePath está sendo definido duas vezes por engano (em vez de TargetPath )

    
por 05.03.2015 / 12:03
fonte
0

É novo no VS2008. Se você precisar escrever código portátil que também compila sob o VS2005 e o mono anterior, evite usá-lo.

    
por 28.09.2011 / 20:42
fonte
0

Desconfie de usar a sintaxe do Object Initializer com algo diferente de valores simples.

Se você começar a fazer chamadas complexas como parte das inicializações de valor, pode ser muito difícil depurá-lo, já que um erro em um dos valores pode ser informado na chamada Constructor e é muito mais difícil exercitar qual valor realmente está causando problema.

    
por 25.10.2011 / 13:17
fonte

Tags