Come si chiama quando si impostano le proprietà sull'inizializzazione dell'oggetto?

Si chiama inizializzatore di oggetti o espressioni di inizializzazione dell'oggetto, almeno in C #. La sua implementazione era necessaria per LinQ, per creare dinamicamente tipi anonimi in modo conveniente.

Che si tratti di una buona pratica o meno dipende da come lo si utilizza. Leggi le idee di Jon Skeet su su stackoverflow per ottenere ulteriori informazioni. Jimmy Hoffa ha anche scritto un ottima risposta su coderview . Propone di basare la decisione a favore o contro gli inizializzatori dell'oggetto sulla domanda:

L'oggetto è utilizzabile in modo sicuro se le proprietà sono nulle?

In tal caso, gli inizializzatori dell'oggetto forniscono un modo molto comodo e leggibile per creare un oggetto.

Per aggiungere un po 'alla buona risposta di Falcon:

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

È un "inizializzatore di oggetti". Si noti che la funzione equivalente per le raccolte è chiamata "inizializzatore della raccolta". Cioè, puoi anche dire

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

e questo sarà tradotto in

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

per te. Puoi persino mescolare gli inizializzatori di oggetti e raccolte! Vedi la sezione di specifiche C # 7.6.10.3 per un esempio su come utilizzare un inizializzatore di raccolta all'interno di un inizializzatore di oggetti.

Is it considered good practice?

Non l'abbiamo aggiunto a C # 3.0 perché era una cattiva pratica!

Il vantaggio irresistibile degli inizializzatori di oggetti e raccolte non è solo il fatto che sono un modo molto più compatto e meno "cerimoniale" di creare e inizializzare un oggetto. Il vantaggio convincente è anche che un inizializzatore di oggetti è un'espressione, non una raccolta di istruzioni . Ciò significa che è possibile utilizzarli in contesti in cui le espressioni sono legali, ma le dichiarazioni non sono, come:

• campi e inizializzatori locali
• inizializzatori di array
• espressione lambda
• Comprensione delle query LINQ
• e così via

Sì, è una buona pratica. È più leggibile perché non hai la ripetizione di customer. e = . Potrebbe sembrare un punto secondario, ma ci vuole tempo ed energia per scansionare quelle linee e verificare che in realtà stanno inizializzando tutte customer .

E considera questo:

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!'

Il codice ripetitivo è soggetto a errori taglia e incolla. È molto meglio esprimere un semplice pensiero (Crea un nuovo cliente) in una singola frase (riga di codice) quando possibile.

Is it considered good practice?

Suggerirei che non è una pratica "cattiva", visto che è principalmente solo una caratteristica di comodità. Non c'è differenza tra

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

o

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

Oltre alla cerimonia.

È un bel po 'di zucchero sintattico e non è una pratica "buona" o "cattiva" tanto quanto è una questione di stile. L'approccio che devi sempre scegliere è quello che migliora la leggibilità.

Generalmente userò questo modulo ogni volta che gli incarichi sono semplici, ogni volta che un incarico diventa più che dare un valore o forse un valore e un trim veloce () lo estrometterò e lo assegnerò all'oggetto esplicitamente.

Trovo anche che sia utile quando devo fare un numero maggiore di incarichi e farlo come:

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

Trovo che le parentesi di indentazione e di blocco del codice contribuiscano a rendere più esplicito e più facile sfogliare il codice.

Un vantaggio di questi inizializzatori che nessuno ha menzionato è che impediscono errori stupidi:

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

Questo si compilerà e sarà bacato.

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

Ora questo non , quindi ti aiuterà a individuare che SourcePath viene impostato due volte per errore (invece di TargetPath )

È nuovo con VS2008. Se hai bisogno di scrivere codice portatile che compili anche con VS2005 e versioni precedenti di mono, evita di usarlo.

Diffidare dall'uso della sintassi di Initializer dell'oggetto con qualcosa di diverso dai semplici valori.

Se inizi ad avere chiamate complesse come parte dell'inizializzazione del valore, può essere molto difficile eseguire il debug in quanto un errore in uno dei call di valore può essere segnalato nella chiamata Constructor ed è molto più difficile allenarsi quale valore stia effettivamente causando il problema.