views:

198

answers:

3

I feel like I skipped a C# class or two, but here's my dilemma:

I have an abstract class from which I derive multiple child classes.

I know for sure that for each of the child classes I will have a constructor that needs a certain static object as a model and this object will be different for each of the child classes.

My first approach was to make a public static object in the abstract parent class and then, before I start creating any instances of the child classes, I would modify it for each of them, but it turns out that this way I actually make only ONE static object, for the abstract class, and each of it's child classes uses it.

How could I solve the problem?

To be more exact, here is the pseudocode:

The parent abstract class:

 abstract class AbstractClass
{
   static public ModelObject Model;
   ...
}

One of the child classes:

class Child : AbstractClass
{
    ...
    public Child()
    {
        this.someField = Model.someField;
    }
}

EDIT:

The Model needs to be a member of the "ModelObject" class, it should NOT be a singleton or anything else.

EDIT2:

To be even more exact, i chose this implementation for a game of chess: I have an abstract class for the chess pieces and the child classes represent the concrete pieces of the game: pawns, knights, et cetera.

The abstract class inherits from MeshMatObject, a class that represents generic 3d objects with the basic functionality, like rotations, meshes, materials, textures and so on and it defines abstract methods for chess game pieces, like GetPossibleMoves().

The Model object I was talking about above is a member of the MeshMatObject and, in my opinion, should be defined outside the class just once and then used for all the pieces. I mean: for example all the pawns have the same mesh and texture, so I don't see the point of giving a model as a parameter every time you want to make a pawn.

+4  A: 

You can get around the shared static field by making your Abstract class generic. Each generic class will get it's own copy of the static fields.

abstract class AbstractClass<T>
{
   static public ModelObject Model;
   ...
}

Then each child class will use a different instance of the static field.

class Child : AbstractClass<Child>
{
    ...
    public Child()
    {
        this.someField = Model.someField;
    }
}

It doesn't matter that AbstractClass doesn't reference the generic parameter. You are only using it to give each child class a unique instance of the base class.

shf301
Thanks for the input, it's halfway there. The other half comes from Justin R. If I would have used just your solution, I would have had no way of operating with just AbstractClass objects. For example, I would have had a hard time laying out a 2D array of abstract chess pieces.Anyway, it's very good to know that with generic classes every child receives a copy of the static field.
cantrem
+1  A: 

How about a factory to decouple your classes from an inherited Model:

public static class ModelObjectFactory
{
    public static ModelObject GetModel<T>(T obj)
    {
        // return ModelObject according to type of parameter
    }
}

class Child
{
    public Child()
    {
        ModelObject mo = ModelObjectFactory(this);
        this.someField = mo.someField;
    }
}
devio
A factory would have worked better in other cases. In this particular one I think I would have over-complicated (if that's a word) the situation; but thanks for the idea!
cantrem
+1  A: 

I tend to use something similar to @shf301's solution. Depending on your needs it may useful to setup the base class as:

abstract class AbstractClass
{
}

abstract class AbstractClass<TModel> : AbstractClass
    where TModel : ModelObject 
{
   static public TModel Model;
   ...
}

This allows me a common base class that I can work with in non-generic functions. This also allows derived types to choose the exact model type and can cut down on casting.

Justin R
It works perfect! Just that the "..." are on "AbstractClass". A nice and simple implementation, thanks. One more thing: is there any performance penalty or such with this implementation? I don't see any reason why it should be, especially with the "optimize code" feature of VS, but just making sure.
cantrem
EDIT: In my case the type constrain should be AbstractClass; then the child classes would be declared as shf301 points out. This is because I need the implementation just for AbstractClass's children.something like: AbstractClass<T> : AbstractClass where T : AbstractClassand the child:ChildClass : AbstractClass<ChildClass>
cantrem