Czy dobrą praktyką jest dziedziczenie po typach ogólnych?

Czy lepiej jest używać List<string>adnotacji typu lub StringListgdzie?StringList

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

Natknąłem się na kilka z nich w Irony .

Jest jeszcze jeden powód, dla którego możesz chcieć dziedziczyć po typie ogólnym.

Microsoft zaleca unikanie zagnieżdżania typów ogólnych w podpisach metod .

Dlatego dobrym pomysłem jest utworzenie nazwanych nazw domen biznesowych dla niektórych ogólnych. Zamiast mieć IEnumerable<IDictionary<string, MyClass>>, utwórz typ, MyDictionary : IDictionary<string, MyClass>a wtedy członek stanie się IEnumerable<MyDictionary>, co jest o wiele bardziej czytelne. Pozwala także korzystać z MyDictionary w wielu miejscach, zwiększając jawność kodu.

Może to nie brzmieć jak ogromna korzyść, ale w prawdziwym kodzie biznesowym widziałem leki generyczne, które sprawią, że twoje włosy staną się koniec. Rzeczy lubią List<Tuple<string, Dictionary<int, List<Dictionary<string, List<double>>>>>. Znaczenie tego ogólnego nie jest w żaden sposób oczywiste. Jednak gdyby został skonstruowany z serii wyraźnie utworzonych typów, intencja oryginalnego programisty byłaby prawdopodobnie o wiele bardziej wyraźna. Co więcej, jeśli ten rodzaj ogólny musiałby się z jakiegoś powodu zmienić, znalezienie i zastąpienie wszystkich wystąpień tego typu ogólnego może być prawdziwym problemem, w porównaniu do zmiany go w klasie pochodnej.

Wreszcie istnieje jeszcze jeden powód, dla którego ktoś może chcieć stworzyć własne typy na podstawie generycznych. Rozważ następujące klasy:

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
    }
}

Skąd wiemy, który ICollection<MyItems> przekazać do konstruktora MyConsumerClass? Jeśli tworzymy klas pochodnych class MyItems : ICollection<MyItems>i class MyItemCache : ICollection<MyItems>, MyConsumerClass może być wtedy bardzo wyraźnie powiedzieć, który z dwóch zbiorów faktycznie chce. To działa bardzo dobrze z kontenerem IoC, który może bardzo łatwo rozwiązać dwie kolekcje. Pozwala także programistom na dokładność - jeśli ma sens MyConsumerClasspraca z dowolnym ICollection, mogą wziąć ogólny konstruktor. Jeśli jednak użycie jednego z dwóch typów pochodnych nigdy nie ma sensu, deweloper może ograniczyć parametr konstruktora do określonego typu.

Podsumowując, często warto wyprowadzać typy z typów ogólnych - pozwala to na bardziej wyraźny kod tam, gdzie jest to stosowne i pomaga w czytelności i konserwacji.

Zasadniczo nie ma różnicy między dziedziczeniem po typach ogólnych a dziedziczeniem po czymkolwiek innym.

Dlaczego, u licha, miałbyś czerpać z jakiejkolwiek klasy i nie dodawać nic więcej?

Nie znam dobrze C #, ale uważam, że jest to jedyny sposób na implementację typedef, z którego programiści C ++ zwykle korzystają z kilku powodów:

• Dzięki temu kod nie wygląda jak morze nawiasów kątowych.
• Umożliwia wymianę różnych pojemników, jeśli potrzeby zmienią się później, i daje do zrozumienia, że ​​zastrzegasz sobie do tego prawo.
• Pozwala nadać typowi nazwę, która jest bardziej odpowiednia w kontekście.

Zasadniczo porzucili ostatnią przewagę, wybierając nudne, ogólne nazwy, ale pozostałe dwa powody pozostają.

Mogę wymyślić co najmniej jeden praktyczny powód.

Deklarowanie typów nieogólnych, które dziedziczą z typów ogólnych (nawet bez dodawania czegokolwiek), pozwala na odwoływanie się do tych typów z miejsc, w których inaczej byłyby niedostępne lub dostępne w bardziej skomplikowany sposób niż powinny.

Jednym z takich przypadków jest dodanie ustawień za pomocą edytora ustawień w programie Visual Studio, gdzie wydaje się, że dostępne są tylko typy inne niż ogólne. Jeśli tam pojedziesz, zauważysz, że wszystkie System.Collectionsklasy są dostępne, ale żadne zbiory z nie System.Collections.Genericwydają się odpowiednie.

Innym przypadkiem jest tworzenie instancji przez XAML w WPF. Nie ma obsługi przekazywania argumentów typu w składni XML podczas korzystania ze schematu sprzed 2009 roku. Sytuację pogarsza fakt, że schemat z 2006 r. Wydaje się być domyślny dla nowych projektów WPF.

Myślę, że musisz zajrzeć do historii .

• C # był używany znacznie dłużej niż miał ogólne typy.
• Oczekuję, że dane oprogramowanie miało kiedyś StringList.
• Mogło to zostać zaimplementowane przez zawinięcie ArrayList.
• Potem ktoś do refaktoryzacji, aby przesunąć bazę kodu do przodu.
• Ale nie chciałem dotykać 1001 różnych plików, więc dokończ zadanie.

W przeciwnym razie Theodoros Chatzigiannakis miał najlepsze odpowiedzi, np. Wciąż istnieje wiele narzędzi, które nie rozumieją rodzajów ogólnych. A może nawet połączenie jego odpowiedzi i historii.

W niektórych przypadkach nie można używać typów ogólnych, na przykład nie można odwoływać się do typu ogólnego w XAML. W takich przypadkach możesz utworzyć rodzaj ogólny, który dziedziczy z typu ogólnego, którego pierwotnie chciałeś użyć.

Jeśli to możliwe, unikałbym tego.

W przeciwieństwie do typedef, tworzysz nowy typ. Jeśli użyjesz StringList jako parametru wejściowego do metody, twoi rozmówcy nie będą mogli przekazać List<string>.

Ponadto musisz jawnie skopiować wszystkie konstruktory, których chcesz użyć, w przykładzie StringList nie możesz powiedzieć new StringList(new[]{"a", "b", "c"}), nawet jeśli List<T>definiuje takiego konstruktora.

Edytować:

Akceptowana odpowiedź skupia się na profesjonalistach, gdy używasz typów pochodnych w modelu domeny. Zgadzam się, że mogą być potencjalnie przydatne w tym przypadku, ale osobiście unikałbym ich nawet tam.

Ale nie należy (moim zdaniem) nigdy używać ich w publicznym interfejsie API, ponieważ albo utrudniasz życie dzwoniącemu, albo marnujesz wydajność (ja też tak naprawdę nie lubię niejawnych konwersji).

Dla tego, co jest warte, oto przykład, w jaki sposób dziedziczenie po klasie ogólnej jest używane w kompilatorze Roslyn Microsoftu, nawet bez zmiany nazwy klasy. (Byłem tak oszołomiony, że znalazłem się tutaj, szukając, czy to naprawdę możliwe).

W projekcie CodeAnalysis można znaleźć tę definicję:

/// <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>
{
  ...
}

Następnie w projekcie CSharpCodeanalysis istnieje następująca definicja:

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

Ta nietypowa klasa PEModuleBuilder jest szeroko stosowana w projekcie CSharpCodeanalysis, a kilka klas w tym projekcie dziedziczy po niej, bezpośrednio lub pośrednio.

A następnie w projekcie BasicCodeanalysis jest następująca definicja:

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

Ponieważ możemy (mam nadzieję) założyć, że Roslyn został napisany przez ludzi z rozległą wiedzą na temat języka C # i tego, jak należy go używać, myślę, że jest to zalecenie tej techniki.

Istnieją trzy możliwe powody, dla których ktoś próbowałby to zrobić z mojej głowy:

1) Aby uprościć deklaracje:

Jasne StringListi ListStringmają taką samą długość, ale wyobraź sobie, że pracujesz z UserCollectiontak naprawdę Dictionary<Tuple<string,Type>, IUserData<Dictionary,MySerializer>>lub z innym dużym, ogólnym przykładem.

2) Aby pomóc AOT:

Czasami musisz używać kompilacji Ahead Of Time, a nie tylko kompilacji In Time - np. Programując dla iOS. Czasami kompilator AOT ma trudności z ustaleniem z wyprzedzeniem wszystkich rodzajów ogólnych, a może to być próba dostarczenia podpowiedzi.

3) Aby dodać funkcjonalność lub usunąć zależność:

Może mają określoną funkcjonalność, dla której chcą zaimplementować StringList(mogą być ukryte w metodzie rozszerzenia, jeszcze nie dodanej lub historycznej), do której albo nie mogą dodać List<string>bez dziedziczenia po niej, albo której nie chcą zanieczyszczaćList<string> z .

Alternatywnie mogą chcieć zmienić implementację w StringListdół ścieżki, więc na razie użyłem klasy jako znacznika (zwykle tworzysz / używasz do tego np IList. Interfejsów ).

Chciałbym również zauważyć, że ten kod został znaleziony w Irony, który jest parserem językowym - dość nietypowym rodzajem aplikacji. Może być jakiś inny konkretny powód, dla którego został użyty.

Te przykłady pokazują, że mogą istnieć uzasadnione powody, aby napisać takie oświadczenie - nawet jeśli nie jest to zbyt powszechne. Podobnie jak w przypadku innych elementów, zastanów się nad kilkoma opcjami i wybierz najlepszą dla siebie.

Jeśli spojrzysz na kod źródłowy , wydaje się, że powodem jest opcja 3 - używają tej techniki, aby dodać funkcjonalność / specjalizować kolekcje:

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; 
    }

Powiedziałbym, że to nie jest dobra praktyka.

List<string>przekazuje „ogólną listę ciągów”. Oczywiście List<string> obowiązują metody rozszerzenia. Do zrozumienia potrzebna jest mniejsza złożoność; potrzebna jest tylko lista.

StringListkomunikuje „potrzebę odrębnej klasy”. Być może List<string> zastosowanie mają metody rozszerzenia (sprawdź faktyczną implementację typu). Potrzebna jest większa złożoność, aby zrozumieć kod; Wymagana jest znajomość implementacji listy i pochodnych klas.