How Can I Accept a Generic Class and Use Its Properties / Methods

I want to create a class that could hold any of a number of same type of classes. For example lets says I have a base class like follows:

public class BaseClass
{
    public string MyBaseString
    {
         get;
         set;
     }
}

And then I have a few derived classes like this:

public class DerivedClass : BaseClass
{
     public MyDerivedClassString
     {
         get;
         set;
     }
}

public class DerivedClass2 : BaseClass
{
     public MyDerivedClass2String
     {
         get;
         set;
     }
}

Now I would like a class that accepts one of these implementations and does stuff with it. Here is the only thing I can think of, but there must be a better way:

public class ClassA
{
    public object MyClass
    {
        get;
        set;
    }

    public ClassA (object myClass)
    {
        MyClass = myClass;
        if (object is BaseClass)
        {
              //do something
        }
        else if (object is DerivedClass)
        {
             //do something specific to derived class
        }
        else if (object is DerivedClass2)
        { 
             //do something specific to derived class 2  
        }
    }
}

CLARIFICATION: The specific goal I am trying to accomplish is to use ClassA as a container class for various implementations of the BaseClass. The business goal I am trying to accomplis开发者_开发知识库h is to create a Legend object which might use multiple color schemes (i.e. a Mono Color Ramp, Multi Color Ramp, etc). So I would like the Legend class to contain the ColorScheme that is being used, but still have access to that color scheme's unique properties for modification later on.

CLARIFICATION 2 Based on the wide array of responses I got, I thought I'd provide an exact replication of what I'm trying to do:

   public class BaseColorScheme
    {
        List<Color> _colors = new List<Color>();                
        public List<Color> Colors
        {
            get
            {
                return _colors;
            }
            set
            {
                _colors = value;
            }
        }
 }

 public class SingleColorScheme : BaseColorScheme
 {

        public Color MidColor
        {
            get;
            set;
        }

        public SingleColorScheme( Color midColor, int numberOfClassifications )
        {
            Colors = CreateMonoColorRamp( midColor, numberOfClassifications );
        }
}

public class MultiColorScheme : BaseColorScheme
{
    public Color StartColor
    {
        get;
        set;
    }
    public Color EndColor
    {
        get;
        set;
    }
    public Color MidColor
    {
        get;
        set;
    }

    public MultiColorScheme( Color startColor, Color endColor, Color midColor )
    {
        StartColor = startColor;
        EndColor = endColor;
        MidColor = midColor;

        Colors = //do something to define multi color scheme
    }
}

Then I would have a Legend Class that would be something like

public class Legend
{
     public object ColorScheme
     {  get; set; }

     public Guid LegendId 
     { get; set; }

     public Legend(object colorScheme)
     {
          ColorScheme = colorScheme;
     }
}

Finally I might have a form that sits on top of the legend that displays the properties of the various color schemes based on which type of color scheme it is. Hopefully that helps clarify a bit.

public class ClassA<T> where T : BaseClass
{
   public T MyClass { get; set; }

   public ClassA(T myClass) { MyClass = myClass; }
}

Beyond that, define the common interface of the class hierarchy either as an interface or as methods (concrete, abstract, or virtual) within the base class. Then you can be assured all derived classes have such method / properties and can use them within your generic wrapper.

Instead of letting ClassA perform whatever needs to be done, you can use polymorphism and let the classes do it to themselves.

Simply declare a virtual method in the base class, have it do whatever you need it do so, and then override this method in the subclasses. In the method in ClassA, you just need to call that method on the object you receive as a parameter - without having to care about the specific type.

If you need to access different properties based on which derived class is passed something like this should help:

public class ClassA<T> where T : BaseClass 
{ 
    public T MyClass { get; set; } 

    public ClassA(T myClass) { MyClass = myClass; } 

    public void DoStuffToMyClass()
    {
        if(MyClass is BaseClass) 
        { // do base class stuff }
        else if(Myclass is DerivedClass)
        { // do DerivedClass stuff }
        else if(MyClass is DerivedClass2)
        { // do DerivedClass2 stuff }
    }
}

This gives you the type saftey to ensure you at least have the BaseClass object, and possibly a derived class.

The answer is polymorphism, let the object do it themselves.

public class BaseClass
{
  public string MyString  { get; set; }

  public virtual string DoIt()
  {
    return "I'm Base Class";
  }
}

public class DerivedClassA
{
  public override string DoIt()
  {
    return "I'm Derived Class A";
  }
}

public class DerivedClassB
{
  public override string DoIt()
  {
    return "I'm Derived Class B";
  }
}
....
public ClassA (BaseClass myClass)
{
    MyClass = myClass;
    MyClass.DoIt(); 
}
.....
ClassA x1 = ClassA(new BaseClass()) // calls BaseClass.DoIt()
ClassA x2 = ClassA(new DerivedClassA()) // calls DerivedClassA.DoIt()
ClassA x3 = ClassA(new DerivedClassB()) // calls DerivedClassB.DoIt()

whenever you catch yourself acting differently based on the run-time type of the object, you are dealing with code that breaks OO principles, i.e. a class that does not respect the base class contract.

Can you use virtual methods?

public abstract class BaseClass
{
  public abstract void DoStuff();
}
public class DerivedClass1 : BaseClass
{
   public override void DoStuff()
   {
      ...
   }
}
public class DerivedClass2 : BaseClass
{
   public override void DoStuff()
   {
      ...
   }
}

Without generics:

public class ClassA  
{  
    public BaseClass MyClass  
    {  
        get;  
        set;  
    }  

    public ClassA (BaseClass myClass)  
    {  
        MyClass = myClass;  
        myClass.DoStuff(); 
    }
}

or with generics:

public class ClassA<T> where T : BaseClass      
{      
    public T MyClass { get; set; }      

    public ClassA (T myClass)  
    {  
        MyClass = myClass;  
        myClass.DoStuff(); 
    }
} 

Keep it simple: polymorphism

Hopefully your objects have a common interface, something like:

class Base {
    public virtual void DoSomething() { /* Default implementation */ }
}

class Derived1 : Base {
    public override void DoSomething() { /* Implementation specific to this type */ }
}

class Derived2 : Base {
    public override void DoSomething() { /* Another implementation specific to this type */ }
}

Or maybe they implement a common interface. So hopefully your consuming class can hold the most general representation of your inputs as possible and invoke code as such:

class Dependent {
    public Dependent(Base instance) {
        instance.DoSomething();
    }
}

So your Dependent class doesn't really are whether it has a derived type or a base type.

Not quite as simple: visitor pattern

Sometimes polymorphism doesn't really work, which is particularly the case if you need to access the specific members of your derived classes, and those members aren't in the base class. Visitor pattern works well in this case, especially if you have a fixed, well-defined graph of objects.

public interface IVisitor<T> {
    T Visit(Base x);
    T Visit(Derived1 x);
    T Visit(Derived2 x);
}

class Base {
    public virtual T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
    public string BaseString { get; set; }
}

class Derived1 : Base {
    public override T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
    public string Derived1String { get; set; }
}

class Derived2 : Base {
    public override T Accept<T>(IVisitor<T> visitor) { visitor.Visit(this); }
    public string Derived2String { get; set; }
}

So Derived1 and Derived2 have a different set of properties, and if you need to get to those properties without a runtime type-checking, implement a visitor:

class DefaultStringVisitor : IBaseVisitor<string> {
    public string Visit(Base x) { return x.BaseString; }
    public string Visit(Derived1 x) { return x.Derived1String; }
    public string Visit(Derived2 x) { return x.Derived2String; }
}

class Dependent {
    public Dependent(Base x) {
        string whatever = x.Accept<string>(new DefaultStringVisitor());
    }
}

So the visitor pattern gives you access to your derived object's members without a type-check. Its a somewhat inflexible pattern (i.e. need to know which objects to visit up front), but it might work for your needs.