È corretto utilizzare l'ereditarietà anziché l'aliasing dei nomi in c #?

Question

In altre parole, è corretto usare:

public class CustomerList : System.Collections.Generic.List<Customer>
{
    /// supposed to be empty
}

anziché:

using CustomerList = System.Collections.Generic.List<Customer>

Preferirei usare il primo approccio perché definirei CustomerList una volta, e ogni volta che avevo bisogno di un elenco di clienti userei sempre lo stesso tipo. D'altra parte, l'uso dell'approccio aliasing del nome non solo mi obbliga a ridefinirlo ovunque, ma potrebbe anche essere dato un alias diverso ogni volta che qualcuno voleva usarlo (pensa a una grande squadra), e quindi fa sì che il codice essere meno leggibile.

Si noti che in questo caso l'intenzione non sarebbe mai quella di estendere la classe, solo per creare un alias.

Answer 1

Non farlo. Quando le persone leggono:

List<Customer> 

lo capiscono immediatamente. Quando leggono:

CustomerList

devono andare a capire cos'è un CustomerList e questo rende il tuo codice più difficile da leggere. A meno che tu non sia l'unico a lavorare sul tuo codebase, scrivere codice leggibile è una buona idea.

Answer 2

bene, a meno che tu non stia aggiungendo alcune funzionalità alla classe base non ha senso creare un oggetto wrapper. Vorrei andare con il numero due se ne hai davvero bisogno, ma perché non creare semplicemente una variabile?

List<Customer> customerList = new List<Customer>();

Answer 3

Sono d'accordo con non usando un alias in quel modo. Nessuno nella tua squadra dovrebbe usare gli alias nel modo presentato; non è il motivo per cui è stato fornito l'aliasing. Inoltre, dal modo in cui funzionano i generici, esiste sempre una sola classe List, indipendentemente da quanti posti la usi.

Oltre a dichiarare e utilizzare List<Customer>, alla fine vorrai passare l'elenco a qualcos'altro. Evita di passare il IList<Customer> concreto e passa invece un ICollection<Customer> o <=> in quanto ciò renderà questi metodi più resistenti e più facili da programmare.

Un giorno in futuro, se hai davvero bisogno di una classe di raccolta CustomerList, puoi implementare <=> o <=> su di essa e continuare a passarla a quei metodi senza che cambino o sappiano meglio.

Answer 4

In realtà non dovresti nemmeno usare. L'approccio corretto secondo le linee guida di progettazione del framework è utilizzare o ereditare da System.Collections.ObjectModel.Collection < T > nelle API pubbliche (Elenco < T > deve essere utilizzato solo per l'implementazione interna).

Ma per quanto riguarda il problema specifico della denominazione, la raccomandazione sembra essere quella di utilizzare il nome di tipo generico direttamente senza aliasing a meno che non sia necessario aggiungere funzionalità alla raccolta:

  

Restituisce Collection < T > dall'oggetto   modelli per fornire pianura standard   API collezione vanilla.

     

Restituisce una sottoclasse di Collection < T >   dai modelli di oggetti da fornire   API di raccolta di alto livello.

Answer 5

L'uso dell'ereditarietà per eseguire alias / typedefing ha il problema di richiedere di ridefinire i costruttori pertinenti.

Poiché diventerà rapidamente irragionevole farlo ovunque, probabilmente è meglio evitarlo per motivi di coerenza.

Answer 6

Questa è una di quelle domande "Dipende".

Se ciò di cui hai bisogno è una nuova classe che si comporta come un Elenco di clienti oltre agli altri requisiti, l'eredità è la strada.

Se vuoi solo usare un elenco di clienti, usa la variabile.

Answer 7

Se stai solo cercando di risparmiare sulla digitazione, usa quest'ultimo. In questo modo non incontrerai bizzarri problemi di eredità.

Se vuoi davvero esporre un tipo di raccolta logicamente distinto, usa il primo: puoi tornare indietro e aggiungere elementi ad esso.

Personalmente, userei solo List<Customer> e lo chiamerei un giorno.

Answer 8

Sono sostanzialmente d'accordo con Ed. Se non è necessario estendere effettivamente la funzionalità del costrutto Elenco generico, basta usare un Elenco generico:

List<Customer> customerList = new List<Customer>();

Se è necessario estendere la funzionalità, in genere si dovrebbe guardare l'ereditarietà.

La terza possibilità è quella in cui è necessario modificare in modo significativo la funzionalità rispetto al costrutto generico dell'elenco, nel qual caso si potrebbe voler semplicemente ereditare da IEnumerable. In questo modo rendi la classe utilizzabile in operazioni enumerabili (come & Quot; foreach & Quot;) ma ti consente di definire completamente tutto il comportamento della classe.

Answer 9

Il risparmio di un programmatore sulla digitazione potrebbe benissimo essere l'incubo di manutenzione del programmatore successivo. Direi semplicemente di scrivere correttamente il generico, come hanno già detto molti qui. È più pulito e una descrizione più accurata dell'intento del codice e aiuterà il programmatore di manutenzione. (Chi potresti essere tu, sei mesi e quattro nuovi progetti lungo la strada!)