继承最派生类型的抽象类

Pol*_*ity 5 c# inheritance c#-4.0

不幸的是,我找不到导致我这个问题的原始项目.这可能会给这个问题带来更多背景.

编辑:我发现原始项目我已经看到了这个:http://mews.codeplex.com/SourceControl/changeset/view/63120#1054567,具体实现在:http://mews.codeplex.com/SourceControl /变更/视图/ 63120#1054606

让我们说我有一个抽象类,具体实现了一些有用的东西:

abstract class AbstractClass
{
    public virtual int ConvertNumber(string number)
    {
        string preparedNumber = Prepare(number);
        int result = StringToInt32(number);
        return result;
    }

    protected abstract string Prepare(string number);

    protected virtual int StringToInt32(string number)
    {
        return Convert.ToInt32(number);
    }
}

sealed class ConcreteClass : AbstractClass
{
    protected override string Prepare(string number)
    {
        return number.Trim();
    }

    public override int ConvertNumber(string number)
    {
        return base.ConvertNumber(number);
    }
}
Run Code Online (Sandbox Code Playgroud)

这是基本的.现在在我在网上看到的代码中,作者通过从最派生类型继承Abstract类来实现继承,例如:

abstract class AbstractGenericClass<TGenericClass>
    where TGenericClass : AbstractGenericClass<TGenericClass>
{
    public virtual int ConvertNumber(string number)
    {
        string preparedNumber = Prepare(number);
        int result = StringToInt32(number);
        return result;
    }

    protected abstract string Prepare(string number);

    protected int StringToInt32(string number)
    {
        return Convert.ToInt32(number);
    }
}

sealed class ConcreteGenericClass : AbstractGenericClass<ConcreteGenericClass>
{
    protected override string Prepare(string number)
    {
        return number.Trim();
    }

    public override int ConvertNumber(string number)
    {
        return base.ConvertNumber(number);
    }
}
Run Code Online (Sandbox Code Playgroud)

现在为什么要做这样的事情呢?我非常清楚地记得这是ATL出于性能原因大量使用的一种技术(某种方式调用具体的成员实现而不使用vtable?)我不太确定这一部分.

我已经检查了两种情况下生成的IL,它们完全相同.

谁能向我解释一下?

Eri*_*ert 4

这是 C++ 中所谓的奇怪重复模板模式的 C# 版本。这有点奇怪,就我个人而言,我尽量避免它。它很有用,但我发现它比有用更令人困惑。

详细请看我的文章:

http://blogs.msdn.com/b/ericlippert/archive/2011/02/03/curiouser-and-curiouser.aspx