Question

Here is something that I find myself using from time to time and I just wanted to get some feedback on the merits of the practice.

Lets say that I have a base class:

abstract class RealBase {     protected RealBase(object arg) {         Arg = arg;     }      public object Arg { get; private set; }      public abstract void DoThatThingYouDo(); } 

I often create a second base class that is generic that handles the cast from the ‘object’ type in the base class to the ‘T’ type, like this:

abstract class GenericBase<T> : RealBase {     protected GenericBase(T arg)         : base( arg ) {     }      new public T Arg { get { return (T) base.Arg; } } } 

This allows me to access ‘Arg’ as its explicit type without a cast operation:

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 );         // [...]     }  } 

All the while being able to also work with it via the ‘RealBase’:

class Usage {     public void UseIt() {         RealBase rb = new Concrete( 'The String Arg' );         DoTheThing(rb);     }      private void DoTheThing(RealBase thingDoer) {         rb.DoThatThingYouDo();     } } 

It is assumed that there are many other ‘Concrete’ types… not just the one.

Here are my questions/concerns:

1. Am I ‘off my rocker’ for using an approach like this?
2. Are there any obvious drawbacks/caveats to using this approach?
3. What about that ‘new public T…’ in GenericBase? Good/bad idea? Awkward?

Any feedback or advice would be greatly appreciated.

Answer 1

I don’t have any objection to that explicitly as long as you’re disciplined enough to only use the generic base class as a helper only and never downcast to it. If you start referencing RealBase and GenericBase and ConcreteClass all over the place things tend to get real tightly coupled really quickly.

As a matter of fact, I would recommend kicking it up a notch and introducing an interface

interface IReal {   void DoThatThingYouDo(); } 

And leaving the base class out of it entirely (basically never reference it except when declaring a derived class). Just a tip that helps me increase the flexibility of my code.

Oh, and if you do use an interface, don’t just declare it in the base classes, declare it on the concrete ones:

class MyConcrete: BaseClass<MyConcrete>, IReal {   ... } 

as a reminder, the base class is not important only what it does is important!