从泛型类型继承是一种好习惯吗？

最好List<string>在类型注释中使用还是StringList在StringList

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

我碰到了几个的这些中的反讽。

还有一个原因可能导致您要从泛型类型继承。

Microsoft建议避免在方法签名中嵌套通用类型。

那么，为某些泛型创建业务域命名类型是一个好主意。而不是IEnumerable<IDictionary<string, MyClass>>创建一个类型MyDictionary : IDictionary<string, MyClass>，然后使您的成员成为一个IEnumerable<MyDictionary>，而不是让它更具可读性。它还允许您在许多地方使用MyDictionary，从而增加代码的显式性。

这听起来似乎不是一个巨大的好处，但是在现实世界的业务代码中，我已经看到了使您的头发站得住脚的类属。之类的事情List<Tuple<string, Dictionary<int, List<Dictionary<string, List<double>>>>>。该泛型的含义绝非显而易见。但是，如果使用一系列显式创建的类型来构造它，则原始开发人员的意图可能会更加清晰。更进一步，如果由于某种原因需要更改该泛型类型，则与在派生类中进行更改相比，找到并替换该泛型类型的所有实例可能是一个真正的痛苦。

最后，还有另一个原因导致人们可能希望创建自己的派生自泛型的类型。考虑以下类别：

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

现在我们如何知道ICollection<MyItems>要传递给MyConsumerClass的构造函数？如果我们创建派生类class MyItems : ICollection<MyItems>和class MyItemCache : ICollection<MyItems>，则MyConsumerClass可以非常明确地确定其实际需要两个集合中的哪个集合。然后，这对于IoC容器非常有效，它可以非常轻松地解析两个集合。它还允许程序员更加准确-如果可以MyConsumerClass与任何ICollection一起使用，则可以采用通用构造函数。但是，如果使用两种派生类型之一从商业上讲没有意义，则开发人员可以将构造函数参数限制为特定类型。

总之，从泛型类型派生类型通常是值得的-它允许在适当的情况下使用更明确的代码，并有助于提高可读性和可维护性。

原则上，从泛型类型继承与从任何其他类型继承之间没有区别。

但是，为什么在地球上您会从任何类别派生而又不添加任何东西呢？

我不太了解C＃，但是我相信这是实现的唯一方法typedef，C ++程序员通常出于以下原因使用它：

• 它可以防止代码看起来像尖括号。
• 如果以后需要更改，它可以让您换出不同的基础容器，并明确表示您保留这样做的权利。
• 它使您可以为类型指定与上下文更相关的名称。

他们基本上通过选择无聊的通用名称而放弃了最后一个优势，但其他两个原因仍然存在。

我可以想到至少一个实际的原因。

声明从泛型类型继承的非泛型类型（即使不添加任何内容），都可以从原本不可用的地方引用这些类型，或者以比应有的方式更复杂的方式来引用这些类型。

一种这样的情况是通过Visual Studio中的“设置”编辑器添加设置时，其中似乎只有非通用类型可用。如果您去那里，您会注意到所有System.Collections类都可用，但是没有任何System.Collections.Generic适用的集合出现。

另一种情况是在WPF中通过XAML实例化类型。使用2009之前的架构时，不支持在XML语法中传递类型参数。由于2006模式似乎是新的WPF项目的默认模式，因此情况变得更糟。

我认为您需要研究一些历史。

• C＃的使用时间比其通用类型的使用时间长得多。
• 我希望给定的软件在历史上可以拥有自己的StringList。
• 这很可能通过包装ArrayList来实现。
• 然后有人要重构以向前移动代码库。
• 但是不希望碰到1001个不同的文件，所以完成工作。

否则，Theodoros Chatzigiannakis会有最好的答案，例如，仍然有许多不了解泛型类型的工具。或者甚至是他的回答和历史的混合。

在某些情况下，不可能使用通用类型，例如，您不能在XAML中引用通用类型。在这些情况下，您可以创建一个非泛型类型，该非泛型类型继承自最初要使用的泛型类型。

如果可能的话，我会避免的。

与typedef不同，您可以创建一个新类型。如果将StringList用作方法的输入参数，则调用者无法传递List<string>。

同样，您将需要显式复制希望使用的所有构造函数，在StringList示例中new StringList(new[]{"a", "b", "c"})，即使List<T>定义了这样的构造函数，您也不会说。

编辑：

在域模型内使用派生类型时，可接受的答案侧重于专业人士。我同意它们在这种情况下可能很有用，不过，即使在那儿，我个人也避免使用它们。

但是（我认为）永远不要在公共API中使用它们，因为这会使调用者的生活更加困难或浪费性能（总体上我也不太喜欢隐式转换）。

值得一提的是，这是一个示例，说明了如何在Microsoft的Roslyn编译器中使用从通用类继承而无需更改类名的情况。（对此我感到迷惑不解，以至于最终在这里进行搜索以查看是否确实可行。）

在项目CodeAnalysis中，您可以找到以下定义：

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

然后在项目CSharpCodeanalysis中有以下定义：

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

这个非泛型的PEModuleBuilder类在CSharpCodeanalysis项目中得到了广泛的使用，该项目中的几个类直接或间接地继承自该类。

然后在项目BasicCodeanalysis中有以下定义：

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

由于我们可以（希望地）假设Roslyn是由具有丰富C＃知识的人编写的，以及如何使用它，所以我认为这是该技术的推荐。

某人试图做到这一点的三个可能原因是：

1）为了简化声明：

当然StringList，ListString它们的长度大约相同，但可以想象一下，您正在使用的UserCollection是实际的Dictionary<Tuple<string,Type>, IUserData<Dictionary,MySerializer>>或其他大型通用示例。

2）要帮助AOT：

有时您需要使用Ahead of Time编译而不是Just In Time Compilation-例如针对iOS开发。有时AOT编译器很难提前弄清所有泛型类型，这可能是尝试为它提供提示。

3）要添加功能或删除依赖性：

也许他们具有要实现的特定功能StringList（可能隐藏在扩展方法中，尚未添加，或者是历史功能），或者无法List<string>继承而不能添加到这些功能，或者他们不想污染List<string>带。

或者，他们可能希望改变现有的实现方式StringList，因此，现在仅使用该类作为标记（通常，例如，您将为此使用/创建接口IList）。

我还要指出，您已经在Irony中找到了此代码，它是一种语言解析器-一种相当不常见的应用程序。使用此消息可能还有其他一些特定原因。

这些示例表明，编写这样的声明可能有正当的理由-即使它不太常见。与任何事物一样，请考虑几个选项，然后选择最适合您的时间。

如果您查看源代码，那么选项3就是原因-他们使用此技术来帮助添加功能/专业化集合：

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

我会说这不是好习惯。

List<string>传达“字符串的通用列表”。显然， List<string>扩展方法适用。需要了解的复杂程度较低；只需要列表。

StringList传达“需要一个单独的班级”。也许 List<string>扩展方法适用（为此检查实际的类型实现）。理解代码需要更多的复杂性。列表和派生的类实现知识是必需的。