C# classe abstraite champ statique de l'héritage

Je me sens comme j'ai sauté une classe C# ou deux, mais voici mon dilemme:

J'ai une classe abstraite à partir de laquelle je tire plusieurs classes enfant.

Je sais pour sûr que, pour chacun des enfants des classes, je vais avoir un constructeur qui a besoin d'un certain objet statique comme un modèle et cet objet sera différente pour chacune des classes enfant.

Ma première approche a été de rendre publique une statique de l'objet dans l'abstrait classe parent et puis, avant de commencer à créer toutes les instances de l'enfant des classes, je voudrais le modifier pour chacun d'eux, mais il s'avère que, de cette façon, en fait je n'en font qu'UN objet statique, pour la classe abstraite, et chacun de ses classes enfant l'utilise.

Comment pourrais-je résoudre le problème?

Pour être plus précis, voici le pseudo-code:

Le parent classe abstraite:

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

L'une des classes enfant:

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

EDIT:

Le Modèle doit être un membre de la "ModelObject" de la classe, il ne devrait PAS être un singleton ou quoi que ce soit d'autre.

EDIT2:

Pour être encore plus exact, j'ai choisi cette mise en œuvre pour un jeu d'échecs: j'ai une classe abstraite pour les pièces d'échecs et de l'enfant les classes représentent les pièces en béton du jeu: les pions, les cavaliers, et cetera.

La classe abstraite hérite de MeshMatObject, une classe qui représente générique des objets en 3d avec les fonctionnalités de base, comme les rotations, des mailles, des matériaux, des textures et ainsi de suite et il définit des méthodes abstraites pour jeu d'échecs morceaux, comme GetPossibleMoves().

Le Modèle objet dont je parlais ci-dessus est un membre de la MeshMatObject et, à mon avis, devrait être définie en dehors de la classe, juste une fois, et ensuite utilisé pour toutes les pièces. Je veux dire: par exemple tous les pions ont le même maillage et de la texture, donc je ne vois pas l'intérêt d'en donner un modèle en tant que paramètre à chaque fois que vous voulez faire un pion.

En quoi AbstractClass besoin pour accéder au Modèle?
Vous devriez envisager l'adoption d'une instance du Modèle de votre sous-classes " constructeurs au lieu d'utiliser un tel champ statique.
Je suis d'accord avec Trillian. Avoir un modèle statique est vraiment violation de l'esprit de l'encapsulation ici.
La classe abstraite n'a pas réellement besoin pour accéder au modèle. L'enfant les classes ont besoin pour accéder à leurs constructeurs @Trillian: oui, ce serait une solution et en fait c'était ma première mise en œuvre, mais puisque tous les objets de la classe sont construits d'après le même modèle exact, je pense qu'il conviendrait de mieux définir le modèle, seulement une fois à l'intérieur de la classe et de l'utilisation du champ statique de construire de nouvelles instances.
Pourquoi a-t-il besoin d'être statique? Partagez-vous l'état entre toutes les classes?

OriginalL'auteur cantrem | 2010-08-22

  1. 6

    J'ai tendance à utiliser quelque chose de similaire à @shf301 de la solution. Selon vos besoins, il peut être utile pour l'installation de la classe de base comme:

    abstract class AbstractClass
{
}

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

    Cela me permet d'une classe de base commune que je peux travailler avec des non-fonctions génériques. Cela permet également de types dérivés de choisir le type de modèle exact et peut couper vers le bas sur le casting.

    Il fonctionne parfaitement! Juste que les "..." sont sur "AbstractClass". Une belle et simple de mise en oeuvre, merci. Encore une chose: est-il des performances de la pénalité ou de tel avec cette mise en œuvre? Je ne vois pas pourquoi il devrait être, en particulier avec le "optimiser le code" fonction de VS, mais juste pour s'assurer.
    EDIT: Dans mon cas, le type de contraindre devrait être AbstractClass; ensuite, l'enfant des classes devrait être déclaré comme shf301 points. C'est parce que j'ai besoin de la mise en œuvre juste pour AbstractClass enfants. quelque chose comme: AbstractClass<T> : AbstractClass où T : AbstractClass et de l'enfant: ChildClass : AbstractClass<ChildClass>

    OriginalL'auteur

  2. 17

    Vous pouvez obtenir autour de la partagé champ statique en faisant de votre classe Abstraite générique. Chaque classe générique obtiendrez son propre exemplaire de la les champs statiques.

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

    Puis chaque enfant de la classe va utiliser une instance à l'autre du champ statique.

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

    Il n'a pas d'importance qui AbstractClass ne fait pas référence au paramètre générique. Vous êtes seul à l'utiliser pour donner à chaque enfant de la classe d'une instance unique de la classe de base.

    Merci pour l'entrée, c'est à mi-chemin. L'autre moitié vient de Justin R. Si je l'aurais utilisé seulement votre solution, je n'aurais eu aucun moyen de fonctionnement avec juste AbstractClass objets. Par exemple, j'aurais eu du mal à la pose d'un tableau 2D de résumé des pièces d'échecs. De toute façon, il est très bon de savoir qu'avec les classes génériques chaque enfant reçoit une copie du champ statique.

    OriginalL'auteur

  3. 3

    Comment sur une usine à dissocier vos classes à partir d'un Modèle hérité:

    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;
    }
}
    Une usine aurait donné de meilleurs résultats dans les autres cas. Dans celui-ci en particulier, je pense que j'aurais plus compliqué (si c'est un mot) la situation; mais merci pour l'idée!
    Les objets avec une seule et unique responsabilité de ne jamais complique les choses. Vérifier principes SOLIDES. -1 pour le commentaire, si cela était possible 🙂

    OriginalL'auteur