Thread: Cast a parent class to child

If any class that you're going to pass to Test.LinkMe() is guaranteed to have a myVar1 field or property, then you should be using a parent class or interface that has that field/property in it:

Code:

interface iMyVar
{
  int myVar1;
}

class Test
{
  ...

  public void LinkMe(iMyVar obj)
  {
    Debug.Log(obj.myVar1);
  }
}

And then just have your Class1 and Class2 implement that iMyVar interface.

Differentiate runtime actions and compile time actions.

The solution proposed above is a compile time action, you simply design better your classes to do what you want.

For a run-time solution, you can use Reflection, haven't really bothered with it.

In .NET 4.0 there is a "dynamic" keyword which makes things simple:

Code:

dynamic myClass = obj;
myClass.myVar = 2;

no idea if this works as it is, but you can do something between these lines. Basically the type will be resolved at run-time as well as the variable/method/property called (maybe it doesn't work with variables only with properties/methods).

Originally Posted by C_ntua

The solution proposed above is a compile time action, you simply design better your classes to do what you want.

For a run-time solution, you can use Reflection, haven't really bothered with it.

In .NET 4.0 there is a "dynamic" keyword which makes things simple:

Code:

dynamic myClass = obj;
myClass.myVar = 2;

no idea if this works as it is, but you can do something between these lines. Basically the type will be resolved at run-time as well as the variable/method/property called (maybe it doesn't work with variables only with properties/methods).

You are correct that reflection and dynamic typing would work. However, I'd recommend against that in this case -- the original poster's issues are arising from badly designed classes. There are very good uses of both reflection and dynamic typing, but neither should be used as a bandaid to cover up poor design.

In general, if you're trying to cast a base class to one of a group of derived classes, more likely than not it's your design that is wrong. That's certainly not an absolute rule, but if you find yourself thinking you need to do it, that should be a red flag to reconsider your design before moving forward.

Originally Posted by snowcore

Even if I make Class1, Class2... extend another class which I would then send to LinkMe in Manager, I would face the same problem when trying to use Class1 from Class2. I need a pointer array in Manager that points to the actual class

What if you used generics?

Code:

class ClassBase
{
  public int var1;
}

class Class1: ClassBase
{
  void DoSomethingWithClass2()
  {
    Class2 obj = Manager.Get<Class2>(...);
  }
}

class Class2: ClassBase
{
}

class Manager
{
  private static List<ClassBase> _List;

  public static void LinkMe(ClassBase obj)
  {
    _List.Add(obj);
  }

  public static T Get<T>(string className)
  {
      // Return the object from the _List that matches
  }
}

Maybe I'm still confused about what you're trying to do.

I would do something like this...

Master.cs:

Code:

    public class Master
    {
        private static Master _Instance;
        public static Master Instance { get { if (_Instance == null) _Instance = new Master(); return _Instance; } }

        private List<BaseClass> _ObjectList = new List<BaseClass>();

        public void LinkIn(BaseClass obj)
        {
            for(int i = 0;i < _ObjectList.Count;++i)
            {
                if (_ObjectList[i].GetType() == obj.GetType())
                {
                    _ObjectList.RemoveAt(i);
                    break;
                }
            }

            _ObjectList.Add(obj);
        }

        public T GetObject<T>() where T: BaseClass
        {
            foreach (BaseClass o in _ObjectList)
                if (o is T)
                    return o as T;
            return null;
        }
    }

BaseClass.cs:

Code:

    public class BaseClass
    {
    }

Class1:

Code:

    public class Class1: BaseClass
    {
        public Class1()
        {
            Master.Instance.LinkIn(this);
        }

        public void DoSomethingInClass2()
        {
            Class2 obj = Master.Instance.GetObject<Class2>();
            // Do stuff with the Class2 obj
        }
    }

Class2:

Code:

    public class Class2: BaseClass
    {
        public Class2()
        {
            Master.Instance.LinkIn(this);
        }

        public void DoSomethingInClass1()
        {
            Class1 obj = Master.Instance.GetObject<Class1>();
            // Do stuff with the Class1 obj
        }
    }

I did this in VS 2010 and it worked great. I don't know much about the Mono feature set, but generics have been around since C# 2.0, so I'm guessing Mono supports them by now.

NOTE: If your classes already need to be derived from another base class, then the BaseClass that I made can simply be turned into an interface instead.

Originally Posted by snowcore

I wonder, the stuff i commented out, that is just a check so that i don't link a class twice yes? If so I don't really need it in my case.

Thanks a lot!

Yup, that's all it was doing. If you don't need to check that then you can leave it out. Glad it worked out for you.

Originally Posted by snowcore

Even if I make Class1, Class2... extend another class which I would then send to LinkMe in Manager, I would face the same problem when trying to use Class1 from Class2. I need a pointer array in Manager that points to the actual class!

First, you're talking about arrays of objects, not classes. A class is a blueprint; an object is a particular constructed instance from that blueprint. The difference between a class and an object is the difference between a recipe and a cake.

Second, you can accomplish this with a base class and any type of collection. That's not unusual. You can cast base pointers to derived pointers all the time. What threw up flags in your initial post was that you indicated that you didn't know the type you wanted at compile time. This in particular was a major flag:

without having to use manually the names of Class1, Class2, etc.

You should either know the name of the class OR (better) the name of an interface it implements at compile time. Then you cast to the interface and call methods on that.

For example, in a game, if I had objects that could take damage, I might implement an IDamageable interface for every such class. Then I could take my base class pointer and cast it to that interface.





Edit: I also have to wonder - you have a game where you have only one instance of each class??? I can't fathom how such a design would work. You basically just made your classes all singletons via a very convoluted process.

I think rather than post code, you should post your design documentation (what classes do you have, how do they interact, what methods and properties do they have) and go from there. I'm still smelling a lot of smoke on this project of yours, and I think it's the underlying design that is the problem. This really ISN'T a common scenario, and that alone should be enough pause to consider if there should be design changes.

Yes, this is a common scheme and I like it myself.
But I think you are then generalizing you code without a reason.
Think: do you need to know the exact type of an object?

For example you want to save a scene which can have various objects. Lets say you have a "Mall", "Shop", "Mountain" as a scene. You can save them all in a List<object> which will be a member of the Master Class. Then since you know what classes are available you can simply have a code like

Code:

class Master {
   List<object> AllObjects;
   ....
   int CountPeopleInPrevScene()
   {
          int sum = 0;
          foreach(object o in AllObjects) {
                if (o is Mall)
                {
                     Mall m = (Mall)o;
                     sum += m.CountPeople();
                }
                else if (o is Shop)
               {
                     Shop p = (Shop )o;
                     sum += p.CountPeople();
                }
          }
   }
   ...
}

not that the "is" oeprator checks the class. So in this case, do you need to know what the type of the object is? No, you just care if it is a "Shop" or "Mall". If you later on add another object "Clown", you won't have to worry about it in this method.

Of course, if you had this method you can use a "Building" as a base class and have only

Code:

if (o is Building)
{
    ...
}

and whatever new class you add you can handle without changing the code.

If you want to optimize you can have separate lits, one for each class or one for each class.

NOTE: even if you could use "dynamic", which I think you cannot on this version, you would just get the type of class. What good does that do you if you cannot use it? If you can use it that means you know its methods, thus the class.
There are some uses for it, but if this is what you are trying to do, this is not the case.
A use would be if you had

Code:

Class A
{
    void Do(Building b) {}
    void Do(Human c) {}
}

and then you wanted to pass an object to Do where you don't know what the available classes are or what Do actually does or you simply don't want to lose time researching for this things. So in order to call the correct Do() function you would need to resolve its type.