我发现自己有时会用到一些东西,我只是想从实践中获得一些反馈。
可以说我有一个基类:
abstract class RealBase {
protected RealBase(object arg) {
Arg = arg;
}
public object Arg { get; private set; }
public abstract void DoThatThingYouDo();
}
我经常创建第二个通用的基类,该基类处理从基类中的“对象”类型到“ T”类型的转换,如下所示:
abstract class GenericBase<T> : RealBase {
protected GenericBase(T arg)
: base( arg ) {
}
new public T Arg { get { return (T) base.Arg; } }
}
这使我无需进行强制转换操作即可访问“ Arg”作为其显式类型:
class Concrete : GenericBase<string> {
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();
}
}
假定还有许多其他“具体”类型...而不仅仅是一种。
这是我的问题/疑虑:
我是否“摇摇欲坠”以使用
这样的方法?
在那儿
任何明显的缺点/缺点
使用这种方法?
关于什么
那个“新公众T ...”
GenericBase?好主意?尴尬?
任何反馈或建议,将不胜感激。
最佳答案
只要您受过足够的纪律以仅将通用基类仅用作帮助程序并且从不贬低它,我就不会明确反对。如果到处都引用RealBase,GenericBase和ConcreteClass,那么事情往往很快就会变得紧密紧密。
实际上,我建议您提高一个档次并引入一个界面
interface IReal {
void DoThatThingYouDo();
}
并且将基类完全排除在外(除声明派生类时,基本上从不引用它)。只是一个技巧,可以帮助我增加代码的灵活性。
哦,如果您确实使用接口,请不要仅在基类中声明它,而应在具体的类上声明它:
class MyConcrete: BaseClass<MyConcrete>, IReal {
...
}
提醒一下,基类并不重要,重要的是它的作用!