convenzione di denominazione della classe C # per un singolo elemento nell'elenco delle voci [chiuso]

Il fatto che tu abbia gli oggetti in una lista è completamente irrilevante. Se stai inviando un elenco di utenti da qualche parte, List<User> sarebbe l'opzione più corretta e non è necessario utilizzare una classe diversa solo perché sta andando in un elenco. Il fatto che la cosa che stai inviando sia diversa da un Utente è la ragione per cui il suo nome (potrebbe) essere diverso, non perché lo stai inserendo in un elenco.

Con ciò, la mia prima raccomandazione è quella di inviare gli interi oggetti User (o oggetti UserDTO se proprio ne hai bisogno) e lasciare che il chiamante ignori ciò che non ha bisogno. Questo non sempre funziona, ma nulla nella domanda indica che non lo farebbe. Questo semplifica la tua applicazione in più modi, con "non c'è bisogno di trovare nuovi nomi per le cose" essendo uno di questi.

Se hai effettivamente bisogno di una classe diversa, il nuovo nome dovrebbe riflettere che è diverso dall'originale. Inoltre, non dovrebbe includere "Elenco" nel suo nome solo perché hai intenzione di inserirlo in un elenco in qualche punto; tutto può andare in una lista. Se si dispone di una classe specifica per contenere un set ridotto di informazioni utente, il nome naturale e conciso per esso sarebbe UserSummary . Se hai una classe specifica per la visualizzazione in un elenco di risultati durante la ricerca di utenti, potrebbe essere chiamata UserSearchResult .

TL; DR Non è necessario separare "Utente" da "Utente, ma in un elenco"; puoi creare un elenco di utenti con List<User> . Se hai ancora bisogno di creare una seconda classe, la ragione della seconda classe è non a causa dell'elenco e devi trovare il motivo reale per chiamarlo.

Il nome è difficile, ma esegui il backup un po '.

Un List è un List . Il tipo che gli dai è per un oggetto in quella lista. vale a dire. una sola cosa.

Per quanto riguarda il nome di quella singola cosa.

• È un utente (anche tagliato), quindi perché non User , e quindi List<User> .
• In alternativa è il numero di telefono di un utente, quindi a proposito di UserPhoneNumber e List<UserPhoneNumber>
• puoi vederlo come contatto utente, quindi a proposito di UserContact e List<UserContact> .

Cerca di evitare la denominazione dei polacchi. Questo è quando si attribuisce la funzione di qualcosa al suo nome. vale a dire. DTO, comando, fabbrica. Proprio dal contesto (e dal sistema dei tipi) sappiamo già di cosa si tratta. Invece guarda lo scopo che sta servendo, quale ruolo ha, nel contesto più ampio. È più facile capire UserPhoneNumber rispetto a UserDTO .

Se hai bisogno di un costrutto di raggruppamento pluralizzi il nome. vale a dire. %codice%. Lascia come internamente riponi il gruppo fuori dal nome, non è importante. Se devi avere due o più strutture interne, trova un'affermazione più generale a riguardo come: UserPhoneNumbers e UserPhoneNumbers per implicare la differenza tra una struttura sequenziale e una serie / mappata.

Sono completamente d'accordo con Kain0_0 qui, basta chiamare quel tipo qualcosa come UserPhoneNumber per far sì che il nome descriva ciò che contiene, non la sua funzione all'interno del codice. Certamente non usare un nome come UserListDTO per qualcosa che non è una lista ma verrà restituito da una lista. Ciò causerà un'enorme confusione a chiunque altro leggendo il codice in quanto il nome suggerisce che è un elenco, non qualcosa che apparirà in un elenco.

Vale anche la pena di affrontare un altro punto che fai:

So we have to create a new class to represent this simplified user details...

No, davvero non devi farlo. In alternativa puoi creare un'interfaccia, IUserPhoneNumber , che ha le proprietà id, name e phone number e avere User implementarlo.

Inoltre, fermati e pensa al motivo per cui stai restituendo List<UserPhoneNumber> . È intenzione che quella lista possa essere modificata dal callee? Se tutto ciò che anticipi è che la lista è enumerata, allora restituisci un tipo più appropriato, ad esempio IEnumerable<IUserPhoneNumber> . Ricorda, secondo "Legge di Postel" , il tuo dovrebbe essere " conservativo in ciò che invii [da un'API] ". Se chiedono un bicchiere d'acqua, non spedirgli un lago e una fabbrica di vetro.

There are only two hard things in Computer Science: cache invalidation and naming things. (Phil Karlton)

Come altri hanno sottolineato, il tuo problema reale non è in realtà correlato ad avere elementi in un elenco, ma piuttosto perché hai un oggetto "Utente" completo con molti campi, ma a volte devi inviare una versione di quell'oggetto con un set limitato di campi attraverso un determinato metodo. Nessun problema, basta nominare la seconda classe 'UserSummary'! Ahhh ma ora hai bisogno di un oggetto di tipo User con un set diverso di campi limitati .... ahhh .... suppongo 'UserSummary2'?

Non esiste una risposta facile per il problema precedente. Soprattutto quando aggiungi nuovi metodi che ti danno un sottoinsieme di proprietà diverso da "Utente". Tuttavia, esiste una nuova funzione linguistica di C # che potrebbe darti un punto di partenza: tuple con nome.

Considera il seguente codice:

// Full User class
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Address { get; set; }
    public DateTime DateOfBirth { get; set; }
    // More fields here.
}

// Get Full User for a given ID
public static User GetUserById(int id)
{
    // get from dbase, includes full User details
    return new User { Id = 3, Name = "Foo bar", Address = "100 Oak St", DateOfBirth = new DateTime(1980, 1, 1) }; 
}

// Get some sub-set of user props
public static IEnumerable<(int Id, string Name)> GetUserSummaries()
{
    // get from dbase, includes just the User properties that you need
    yield return (Id: 1, Name: "Steve Smith");
    yield return (Id: 2, Name: "Bharkat Tahbarat");
    yield return (Id: 3, Name: "Kelly Rodriguez");
}

Hai la classe utente completa quando necessario e ogni metodo che restituisce una raccolta di dati di riepilogo può semplicemente definire un tipo di ritorno di una tupla che corrisponda agli oggetti di scena dell'utente per comodità. Puoi anche aggiungere la tupla restituita a Type prop che rappresenta il tipo a cui si avvicina di più, in questo caso typeof(User) . Non lo farei se non necessario, ma è un'opzione.