Héritage d'un attribut de classe [C#]

Bonjour,

Dans le cadre du développement d'un moteur de jeu d'échec qui doit vérifier certaines règles, j'ai une classe abstraite Rule qui représente une règle et j'ai dans cette classe un attribut (ou propriété) de type liste qui doit contenir la liste des pièces sur les quelles la règle s'applique. L'idée est donc de définir un attribut Static mais aussi abstract dans la classe Rule, ainsi toute les règles concrètes devront redéfinir cet attribut et donc spécifier sur quelles pièces elles s'appliquent.

Malheureusement pour une raison que j'ignore (une question de design) C# n'autorise pas un attribut ou propriété :

1

public abstract static List<Piece.Type> Types { get; set; } // Nooooon

Ma question est donc : Quelle est la manière la plus propre pour réaliser ceci ?

Merci d'avance pour vos réponses !

Un attribut ne peut pas être abstrait, et encore moins s'il est static.

Le principe de l'attribut et la méthode static c'est que justement comme ça n'est pas lié à une instance, ça n'a pas à être hérité puisqu'il n'y a aucun polymorphisme à tirer de cette méthode/attribut.

Donc en fait ce n'est pas un attribut static que tu veux mais un attribut normal, que tu peux à la limite overrider si tu le désires vraiment.

Une nouvelle fois l'attribut n'est pas abstrait, ça n'aurait aucun sens d'avoir un attribut abstrait.

Merci pour la réponse, Mais du coup si je veux pouvoir définir dans la classe abstraite Rule que toutes ces filles auront une propriété static, comment faire ?

Le but final étant de pouvoir faire :

1
2

// On a ConcreteRule qui hérite de Rule
List<Piece.Type> types = ConcreteRule.Types; // On récupère la liste des pièces sur les quelles la règle s'applique.

Merci pour la réponse, Mais du coup si je veux pouvoir définir dans la classe abstraite Rule que toutes ces filles auront une propriété static, comment faire ?

bah en fait je ne comprends pas pourquoi tu veux un truc qui s'hérite ET qui est static. Quel est ton besoin réel? Qu'est-ce qui t'empêche de ne pas rendre cet attribut static?

En fait l'idée c'est qu'on puisse demander au règles concrètes, sans les instancier, quelles sont les types de pièce sur les quelles elles s'appliquent. Donc toutes les règles concrètes auront un attribut static, je cherche à le factoriser dans la classe Rule.

En fait l'idée c'est qu'on puisse demander au règles concrètes, sans les instancier, quelles sont les types de pièce sur les quelles elles s'appliquent.

Bah si chaque classe a ses propres types, je dirais que c'est au mieux lié à l'instance au pire il va falloir jouer avec l'introspection. Mais pour le coup je dirais vraiment que Type est un attribut d'instance et qu'il te faudra instancier les classes. Après il faut voir quel sens tu mets derrière les classes ConcreteRule1 et ConcreteRule2 si c'est juste un moyen de distinguer les types, tu n'as pas besoin de deux classes concrètes.

Alors en fait les classes ConcreteRule1 et 2 représente des règles qui vont s'appliquer sur des types de pièces du jeu d'échec comme le roi par exemple donc chaque règle peut s'appliquer sur une ou plusieurs type de pièce. Le moteur reçoit un déplacement, avec une chaîne de responsabilité on va dans la classe qui sait traiter le type de pièce qui veut effectuer le déplacement (par exemple le roi). Ensuite cette classe va instancier toutes les règles qui ont le type Roi dans la liste des types sur les quels elles s'appliquent. Mais on doit pourvoir demander à une classe représentant une règle quelles sont les types de pièces sur les quels elle porte sans instance à mon sens.

Sinon dans ce topic http://stackoverflow.com/questions/823665/c-implement-static-abstract-like-methods La réponse de Ryan Barrett explique l'idée (mais appliquer ailleurs)

Mais si ça se trouve mon design est bizarre…

Je dirais effectivement que ton design est bizarre. Car autant je veux bien qu'en première approximation une pièce connaisse ses règles (même si pour le coup je dirais que c'est plutôt le Jeu qui connait les règles associées aux pièces), mais dire que les règles connaissent les pièces, je dirais que ça va à l'envers.

Ah non par contre les pièces ne connaissent pas les règles. Le moteur à lui toutes les règles et les appliquent sur les pièces quand il reçoit un déplacement. Mais la pièce n'a pas visibilité de cela. Par contre je ne voit pas pourquoi une règle ne devrait pas connaitre le type de la pièce ? Car une règle dépend du type de pièce que l'on essaye de déplacer ?

Ah yes c'est plus simple et plus jolie aussi ! Merci !