tags:

views:

425

answers:

5

I would inheritance for a particular object to be dynamic and set via an extra setting of some type like the app.config file.

Here is an example:

//PROGRAM A
public class MySuperClass : OldIneritanceObjectVersion
{
       ........Stuff Goes Here
}


//PROGRAM B
public class MySuperClass : OldIneritanceObjectVersion
{
       ........Stuff Goes Here
}

//PROGRAM B .....a Few Years Later.....
public class MySuperClass : NewIneritanceObjectVersion
{
       ........Stuff Goes Here
}

As you can guess, I want my old stuff to keep using the OldIneritanceObjectVersion while I want new stuff I create as well as updating old stuff to use the more updated NewIneritanceObjectVersion. Is there some way to do this dynamically?

+4  A: 

No. C# is statically typed. The type hierarchy for each class must be known at compile time.

John Saunders
+1  A: 

You could potentially do this via T4. You'd be able to setup a template for your class, and easily change this behavior.

This becomes a compile time construct, not a runtime construct, though. There is no way to do this (easily) at runtime, short of generating the type dynamically every time you run, and having some type of in memory assembly.


Another thought here -

You could accomplish the same effect or work towards this goal via using Inversion of Control and Dependency Injection. Just make your classes rely on the base class or an interface. This would make it very easy to change the implementation later, at runtime, via configuration or many other techniques.

Reed Copsey
+1  A: 

You could export your "base classes" in a separate DLL and reference it in your project. Then, when you have a new version of this DLL, you simply replace the old one.

But by doing this, you would have to keep the same name for the base class, and it would be replaced EVERYWHERE to the new version. It should not be a problem, I guess.

Bruno Reis
A: 

You could try something like this...don't change the inhertiance structure all over the place of the subclasses of OldInheritanceObjectVersion. Instead, change OldInhertianceObjectVersion's inhertance structure in one place!

//NewInheritanceObjectVersion
public class NewInheritanceObjectVersion
{  /*
      ...Move original stuff from OldInheritanceObjectVersion to this class here
      ...with any new stuff/changes here.  Should probably maintain backwards
      ...compatibility with OldInheritanceObjectVersion if we can
      ...(or OldInhertianceObjectVersion can be an adapter that maintains backwards
      ... compatibility and adapts/delegates to this class)
   */
}

//OldInheritanceObjectVersion
public class OldInheritanceObjectVersion : NewInheritanceObjectVersion
{ /*
      ...Since old and new stuff is implemented in NewInheritanceObjectVersion
      ...this is simply a "pass-through" class so that all classes that inherit
      ...from this class get old and new behavior without changing their inheritance

      ...worst case, this class can expose the old interface/class definition and
      ...delegate/adapt  the methods/properties to the new 
      ...features in NewInheritanceObjectVersion
      ...if NewInheritanceObjectVersion does not implement them directly
  */
}

//PROGRAM B .....a Few Years Later.....
public class MySuperClass : OldInheritanceObjectVersion
{  /*
       ........Without changing this at all, we get all old behavior
       ........and we can update it to take advantage of new features as well 
   */
}
Tony Heupel
What is the difference between this and simply changing OldInheritanceObjectVersion?
dionadar
Actually not a bad point. As I re-look at the question it really doesn't seem to make much sense and the top answer really says it all.
Tony Heupel
A: 

You're essentially changing the inheritance chain to depend on a new concrete implementation. This is smelly and while it may be possible through some sort of code Emit -- I've never tried this and am inclined to agree with John S.-- I would strongly advise against it.

If you're worried about needing to inject new items into the inheritance chain, I'd do some encapsulation at "OldInheritenceObjectVersion" and inject the actual implementation into it through Dependency Injection.

I'm still not comfortable with this, but it's probably the path of least resistance if you're bound and determined to do this through inheritance.

andymeadows