È buona prassi ereditare da tipi generici?

È meglio usare List<string>nelle annotazioni dei tipi o StringListdoveStringList

class StringList : List<String> { /* no further code!*/ }

Mi sono imbattuto in molti di questi in Irony .

C'è un altro motivo per cui potresti voler ereditare da un tipo generico.

Microsoft consiglia di evitare l'annidamento di tipi generici nelle firme dei metodi .

È una buona idea, quindi, creare tipi denominati di dominio aziendale per alcuni dei tuoi generici. Invece di avere un IEnumerable<IDictionary<string, MyClass>>, crea un tipo MyDictionary : IDictionary<string, MyClass>e il tuo membro diventa un IEnumerable<MyDictionary>, che è molto più leggibile. Inoltre, consente di utilizzare MyDictionary in diversi punti, aumentando l'esplicitazione del codice.

Questo potrebbe non sembrare un enorme vantaggio, ma nel codice aziendale del mondo reale ho visto generici che ti faranno rizzare i capelli. Cose come List<Tuple<string, Dictionary<int, List<Dictionary<string, List<double>>>>>. Il significato di quel generico non è affatto ovvio. Tuttavia, se fosse costruito con una serie di tipi creati esplicitamente, l'intenzione dello sviluppatore originale sarebbe molto più chiara. Inoltre, se quel tipo generico dovesse cambiare per qualche motivo, trovare e sostituire tutte le istanze di quel tipo generico potrebbe essere una vera seccatura, rispetto a cambiarlo nella classe derivata.

Infine, c'è un altro motivo per cui qualcuno potrebbe voler creare i propri tipi derivati ​​dai generici. Considera le seguenti classi:

public class MyClass
{
    public ICollection<MyItems> MyItems { get; private set; }
    // plumbing code here
}

public class MyOtherClass
{
    public ICollection<MyItems> MyItemCache { get; private set; }
    // plumbing code here
}

public class MyConsumerClass
{
    public MyConsumerClass(ICollection<MyItems> myItems)
    {
        // use the collection
    }
}

Ora come facciamo a sapere quale ICollection<MyItems>passaggio nel costruttore per MyConsumerClass? Se creiamo classi derivate class MyItems : ICollection<MyItems>e class MyItemCache : ICollection<MyItems>, MyConsumerClass può quindi essere estremamente specifico su quale delle due raccolte desidera effettivamente. Funziona quindi molto bene con un contenitore IoC, che può risolvere molto facilmente le due raccolte. Inoltre, consente al programmatore di essere più preciso: se ha senso MyConsumerClasslavorare con qualsiasi ICollection, può prendere il costruttore generico. Se, tuttavia, non ha mai senso dal punto di vista economico utilizzare uno dei due tipi derivati, lo sviluppatore può limitare il parametro del costruttore al tipo specifico.

In sintesi, spesso vale la pena derivare tipi da tipi generici: consente un codice più esplicito laddove appropriato e aiuta la leggibilità e la manutenibilità.

In linea di principio non c'è differenza tra ereditare da tipi generici ed ereditare da qualsiasi altra cosa.

Tuttavia, perché mai dovresti derivare da una classe e non aggiungere altro?

Non conosco molto bene C #, ma credo che questo sia l'unico modo per implementare un typedef, che i programmatori C ++ usano comunemente per alcuni motivi:

• Mantiene il tuo codice dall'aspetto come un mare di parentesi angolari.
• Ti consente di scambiare diversi contenitori sottostanti se le tue esigenze cambiano in seguito, e chiarisce che ti riservi il diritto di farlo.
• Ti consente di assegnare a un tipo un nome più pertinente nel contesto.

Fondamentalmente hanno gettato via l'ultimo vantaggio scegliendo nomi noiosi e generici, ma gli altri due motivi sono ancora validi.

Mi viene in mente almeno un motivo pratico.

La dichiarazione di tipi non generici che ereditano da tipi generici (anche senza aggiungere nulla), consente a tali tipi di essere referenziati da luoghi in cui altrimenti non sarebbero disponibili o disponibili in un modo più contorto di quanto dovrebbero essere.

Uno di questi casi è quando si aggiungono impostazioni tramite l'editor Impostazioni in Visual Studio, in cui sembrano essere disponibili solo tipi non generici. Se ci vai, noterai che tutte le System.Collectionsclassi sono disponibili, ma nessuna raccolta da System.Collections.Genericappare come applicabile.

Un altro caso è rappresentato dall'istanza di tipi tramite XAML in WPF. Non è supportato il passaggio di argomenti di tipo nella sintassi XML quando si utilizza uno schema precedente al 2009. Ciò è aggravato dal fatto che lo schema del 2006 sembra essere il default per i nuovi progetti WPF.

Penso che tu abbia bisogno di esaminare un po 'di storia .

• C # è stato usato per molto più tempo di quanto non abbia avuto tipi generici.
• Mi aspetto che il software in questione abbia un proprio StringList a un certo punto della storia.
• Questo potrebbe essere stato implementato avvolgendo un ArrayList.
• Quindi qualcuno a refactoring per spostare in avanti la base di codice.
• Ma non volevo toccare 1001 file diversi, quindi finisci il lavoro.

Altrimenti Theodoros Chatzigiannakis ha avuto le risposte migliori, ad esempio ci sono ancora molti strumenti che non comprendono i tipi generici. O forse anche un mix di risposta e storia.

In alcuni casi è impossibile utilizzare tipi generici, ad esempio non è possibile fare riferimento a un tipo generico in XAML. In questi casi è possibile creare un tipo non generico che eredita dal tipo generico che si voleva usare originariamente.

Se possibile, lo eviterei.

A differenza di un typedef, crei un nuovo tipo. Se si utilizza StringList come parametro di input per un metodo, i chiamanti non possono passare a List<string>.

Inoltre, dovresti copiare esplicitamente tutti i costruttori che desideri utilizzare, nell'esempio StringList che non potresti dire new StringList(new[]{"a", "b", "c"}), anche se List<T>definisce un tale costruttore.

Modificare:

La risposta accettata si concentra sui pro quando si utilizzano i tipi derivati ​​all'interno del modello di dominio. Concordo sul fatto che possano essere potenzialmente utili in questo caso, tuttavia, personalmente li eviterei anche lì.

Ma non dovresti (secondo me) non usarli mai in un'API pubblica perché rendi la vita del tuo chiamante più dura o sprechi le prestazioni (anche a me non piacciono molto le conversioni implicite in generale).

Per quello che vale, ecco un esempio di come l'ereditarietà da una classe generica viene utilizzata nel compilatore Roslyn di Microsoft e senza nemmeno cambiare il nome della classe. (Ero così confuso da questo che sono finito qui nella mia ricerca per vedere se questo era davvero possibile.)

Nel progetto CodeAnalysis puoi trovare questa definizione:

/// <summary>
/// Common base class for C# and VB PE module builder.
/// </summary>
internal abstract class PEModuleBuilder<TCompilation, TSourceModuleSymbol, TAssemblySymbol, TTypeSymbol, TNamedTypeSymbol, TMethodSymbol, TSyntaxNode, TEmbeddedTypesManager, TModuleCompilationState> : CommonPEModuleBuilder, ITokenDeferral
    where TCompilation : Compilation
    where TSourceModuleSymbol : class, IModuleSymbol
    where TAssemblySymbol : class, IAssemblySymbol
    where TTypeSymbol : class
    where TNamedTypeSymbol : class, TTypeSymbol, Cci.INamespaceTypeDefinition
    where TMethodSymbol : class, Cci.IMethodDefinition
    where TSyntaxNode : SyntaxNode
    where TEmbeddedTypesManager : CommonEmbeddedTypesManager
    where TModuleCompilationState : ModuleCompilationState<TNamedTypeSymbol, TMethodSymbol>
{
  ...
}

Quindi nel progetto CSharpCodeanalysis c'è questa definizione:

internal abstract class PEModuleBuilder : PEModuleBuilder<CSharpCompilation, SourceModuleSymbol, AssemblySymbol, TypeSymbol, NamedTypeSymbol, MethodSymbol, SyntaxNode, NoPia.EmbeddedTypesManager, ModuleCompilationState>
{
  ...
}

Questa classe PEModuleBuilder non generica è ampiamente utilizzata nel progetto CSharpCodeanalysis e diverse classi in quel progetto ereditano da esso, direttamente o indirettamente.

E poi nel progetto BasicCodeanalysis c'è questa definizione:

Partial Friend MustInherit Class PEModuleBuilder
    Inherits PEModuleBuilder(Of VisualBasicCompilation, SourceModuleSymbol, AssemblySymbol, TypeSymbol, NamedTypeSymbol, MethodSymbol, SyntaxNode, NoPia.EmbeddedTypesManager, ModuleCompilationState)

Dal momento che possiamo (si spera) presumere che Roslyn sia stato scritto da persone con una vasta conoscenza di C # e come dovrebbe essere usato, sto pensando che questa è una raccomandazione della tecnica.

Ci sono tre possibili ragioni per cui qualcuno dovrebbe provare a farlo dalla cima della mia testa:

1) Per semplificare le dichiarazioni:

Sicuro StringListe ListStringhanno circa la stessa lunghezza, ma immagina invece che stai lavorando con un esempio in UserCollectionrealtà Dictionary<Tuple<string,Type>, IUserData<Dictionary,MySerializer>>o qualche altro grande esempio generico.

2) Per aiutare AOT:

A volte è necessario utilizzare la compilazione Ahead Of Time e non la compilazione Just In Time, ad esempio lo sviluppo per iOS. A volte il compilatore AOT ha difficoltà a capire tutti i tipi generici in anticipo, e questo potrebbe essere un tentativo di fornire un suggerimento.

3) Per aggiungere funzionalità o rimuovere la dipendenza:

Forse hanno funzionalità specifiche che vogliono implementare per StringList(potrebbe essere nascosto in un metodo di estensione, non ancora aggiunto, o storica) che o non possono ampliare List<string>senza ereditare da essa, o che non vogliono inquinare List<string>con .

In alternativa, potrebbero voler cambiare l'implementazione di StringListdown the track, quindi per il momento hanno appena usato la classe come marker (di solito per questo faresti / useresti interfacce IList).

Vorrei anche notare che hai trovato questo codice in Irony, che è un parser di lingua - un tipo di applicazione abbastanza insolito. Potrebbe esserci qualche altro motivo specifico per cui è stato utilizzato.

Questi esempi dimostrano che ci possono essere motivi legittimi per scrivere una simile dichiarazione, anche se non è troppo comune. Come per qualsiasi cosa, considera diverse opzioni e scegli quella che è meglio per te al momento.

Se dai un'occhiata al codice sorgente , sembra che l'opzione 3 sia la ragione: usano questa tecnica per aggiungere funzionalità / specializzare le raccolte:

public class StringList : List<string> {
    public StringList() { }
    public StringList(params string[] args) {
      AddRange(args);
    }
    public override string ToString() {
      return ToString(" ");
    }
    public string ToString(string separator) {
      return Strings.JoinStrings(separator, this);
    }
    //Used in sorting suffixes and prefixes; longer strings must come first in sort order
    public static int LongerFirst(string x, string y) {
      try {//in case any of them is null
        if (x.Length > y.Length) return -1;
      } catch { }
      if (x == y) return 0;
      return 1; 
    }

Direi che non è una buona pratica.

List<string>comunica "un elenco generico di stringhe". Si List<string> applicano chiaramente metodi di estensione. È necessaria meno complessità per capire; è necessaria solo la lista.

StringListcomunica "la necessità di una classe separata". Forse si List<string> applicano i metodi di estensione (controllare l'implementazione del tipo effettivo per questo). È necessaria una maggiore complessità per comprendere il codice; Sono richiesti l'elenco e la conoscenza dell'implementazione della classe derivata.