泛型,继承和新的运算符

以下是我发现自己不时使用的内容,我只是希望得到一些关于实践优点的反馈.

让我们说我有一个基类:

abstract class RealBase {
    protected RealBase(object arg) {
        Arg = arg;
    }

    public object Arg { get; private set; }

    public abstract void DoThatThingYouDo();
}

我经常创建一个通用的第二个基类,它处理从基类中的"object"类型到"T"类型的转换,如下所示:

abstract class GenericBase : RealBase {
    protected GenericBase(T arg)
        : base( arg ) {
    }

    new public T Arg { get { return (T) base.Arg; } }
}

这允许我在没有强制转换操作的情况下访问"Arg"作为其显式类型:

class Concrete : GenericBase {
    public Concrete( string arg )
        : base( arg ) {
    }

    public override void DoThatThingYouDo() {
        // NOTE: Arg is type string. No cast necessary.
        char[] chars = Arg.ToLowerInvariant().ToCharArray();  
        // Blah( blah, blah );
        // [...]
    }

}

一直能够通过"RealBase"使用它:

class Usage {
    public void UseIt() {
        RealBase rb = new Concrete( "The String Arg" );
        DoTheThing(rb);
    }

    private void DoTheThing(RealBase thingDoer) {
        rb.DoThatThingYouDo();
    }
}

假设还有许多其他"混凝土"类型......而不仅仅是那个类型.

以下是我的问题/疑虑:

使用这样的方法我是否"脱离摇滚乐"？

使用这种方法有任何明显的缺点/警告吗？

GenericBase中的那个"新公共T ......"怎么样？好/坏主意？尴尬？

任何反馈或建议将不胜感激.

只要您足够严格,只使用通用基类作为帮助程序并且从不向下使用它,我就没有任何明确的反对意见.如果你开始在所有地方开始引用RealBase和GenericBase以及ConcreteClass,那么事情就会很快得到真正的紧密耦合.

事实上,我建议将其提升一个档次并引入界面

interface IReal {
  void DoThatThingYouDo();
}

并且完全不使用基类(基本上从不引用它,除非在声明派生类时).只是一个提示,可以帮助我提高代码的灵活性.

哦,如果你确实使用了一个接口,不要只在基类中声明它,在具体的声明它:

class MyConcrete: BaseClass, IReal {
  ...
}

作为提醒,基类并不重要,只有它的重要性!

好吧,我们现在已经有了三层深度的继承树,但是你没有给出任何特别的理由.

就个人而言,我很少使用继承(或者更确切地说,很少设计我自己的继承层次结构,而不是实现接口并直接从对象派生).继承是一种强大的工具,但却很难有效地使用.

如果这给你一些明显优于其他方法的优势,那很好 - 但我会考虑你为阅读代码的人添加的复杂性.他们真的想要考虑三个层次结构,两个同名属性？(我会将GenericBase.Arg重命名为GenericBase.GenericArg或类似的东西.)